ISACAカンファレンス登壇資料_akazawa

平時の対応が監査を強くする IRの観点から分析するシステム監査準備 監査とインシデントレスポンスの共通構造を読み解く 2025年12月6日 赤澤 大海 CISSP,CISA,CISM,情報処理安全確保支援士（第031151号） ISACA東京支部カンファレンス2025 1

導入：気づきの瞬間 とある日ふと、思いました。 IRの平時対応と監査準備は、実は似ているのではないか？ そんな着想から、本日のテーマ 「IRの観点から分析するシステム監査準備」 ISACA東京支部カンファレンス2025 2

IRの平時対応と監査準備のプロセス整理 ISACA東京支部カンファレンス2025 3

NIST SP800-61におけるプロセス 1.準備 インシデント対応の体制・計画を事前に整え 、必要なリソースや環境を準備する段階 4.根絶 インシデント原因を完全に除去し、同様の脅 威を排除するための対策を実施する段階 ISACA東京支部カンファレンス2025 2.検知・分析 インシデントの検知と特性を把握・分類し、 優先度や影響度を判断する段階 5.復旧 システムやサービスを安全に通常運用状態に 戻し、機能を回復させる段階 3.封じ込め インシデントの影響範囲を特定し、被害の拡 大を防止するための措置を講じる段階 6.教訓 発生したインシデントから教訓を得て、将来 の対応改善に活かすための振り返り段階 4

システム監査におけるプロセス 1.監査計画の策定 2.事前調査・予備調査 3.本調査 目的・範囲・対象を決定 事前情報の収集依頼 基本手順の策定 組織図、業務フロー、 システム構成の理解 重点項目・リスクの抽出 インタビュー、設定確認、 ログ分析、動作テスト 監査証拠の収集 4.監査報告書の作成 5.監査報告 6.フォローアップ 目的・範囲・方法、発見事項、 改善案の整理 経営・被監査部門への報告 ISACA東京支部カンファレンス2025 改善状況の確認・追加検証 5

IR平時対応×システム監査の共通項 共通項  唯一の事実を示す証跡はログである  IRの平時対応も監査準備も、最終的にはログを取得し、完全性を保ち、 分析可能な状態にしておくことで成立する IR（平時） 異常検知・原因分析 の根拠としてログが 必要 目的は違っても、 「証跡の設計・維持」 は同じ 監査準備 統制が有効に機能して いる事実を示す根拠と してログが必要 ログ設計プロセスを統合すると、IRも監査も同時に強化され、 組織のセキュリティガバナンスが一段階引きあがるのではないか？ ISACA東京支部カンファレンス2025 6

共感から始める − 現場のリアル 「証跡が足りない」「説明できない」− 聞き覚えありませんか？ 監査対応の現場 IR対応の現場 「証跡を揃える」ことに追われる 「証拠を残す」ことに追われる 「統制の有効性」を証明する書類探し 「被害範囲」を特定する情報不足 「指摘事項対応」の繰り返し 「初動対応」の混乱 結局、時間切れで妥協… 結局、証拠不足で説明不能… ISACA東京支部カンファレンス2025 7

共通課題：「証跡がない」 典型的な課題例 ログ欠損：必要なイベントが記録されていない 保存期間切れ：必要な期間、証跡が保持されていない 権限不備：証跡へのアクセス権が適切に設定されていない 時刻同期不良：複数システム間でのタイムスタンプ不一致 データ 欠損 時間 経過 アクセス 制限 根本原因 平時の設計不備：セキュリティ要件・監査要件が明確化されていない 運用のばらつき：標準化されたログ管理プロセスが欠如している キー・メッセージ IRも監査も、証拠の前提条件は日常運用にある 有事になってから証跡を確保することはできない ISACA東京支部カンファレンス2025 8

あるある① ログ・証跡がない 「なぜそのログを取っていなかったのか？」 IR視点 監査視点 被害経路・範囲を追えず封じ込め不能 証拠不足で原因特定ができない 対外説明の根拠を示せない 統制が機能した証跡がなく監査不成立 何を確認すべきかサンプリングできない 改善効果を測定できない 根本原因 証跡の"信頼性と保持性"を設計していない（取得・改ざん防止・保管・保全） 対策 フォレンジック・レディネス、WORM保存、MTTE（証跡入手までの平均時間）短縮 ISACA東京支部カンファレンス2025 9

あるある② 資産・構成が不明 「そのシステム、どこにあるんでしたっけ？」 IR視点 監査視点 影響範囲を特定できない 封じ込め境界を設定できない 復旧順序を決められない 同種システムの横断的対策が困難 対象範囲を特定できない 統制単位を明確にできない システム間の整合性を評価不能 変更管理の追跡性が確保できない 根本原因 CMDB/資産台帳の信頼性と更新プロセスが未整備 対策 構成管理自動化、定期棚卸、変更管理の実施 ISACA東京支部カンファレンス2025 10

あるある③ 権限の変更履歴が追えない 「誰がこの設定を変更したのか？」 IR視点 監査視点 横展開や権限悪用の判定不可 不正アクセスか正規業務か判別できない 誰が何を変更したか追跡不能 職務分掌・アクセスレビューの証跡がない 変更管理プロセスの検証ができない アクセス権の定期見直しが形骸化 根本原因 ID管理・変更管理の記録と承認ワークフローが不在 （特権ID・権限変更・申請承認の仕組み） 対策 特権ID管理、承認ログ — 「誰が何をしたか」の証跡連鎖を構築 ISACA東京支部カンファレンス2025 11

平時にできること − 3つの観点 監査対応 ≒ IR対応の準備 ① ② ③ Integrity Traceability Reproducibility 改ざん耐性と真正性の確保 因果のつながりの可視化 第三者が再現できること ログの信頼性を保証する基盤 行動と結果の関連付け 説明と検証の基本条件 電子署名・タイムスタンプ・ WORM保存 イベント間の相関性と 連続性の確保 同一条件下で同一結果が 得られる設計 完全性 追跡性 再現性 平時の証跡管理がもたらす「証拠の質」が、有事の「対応の質」を決める ISACA東京支部カンファレンス2025 12

別々のプロセスで設計・運用される「IR」と「監査」 ログ設計が二重化 IR担当者 インシデントレスポンス 運用負荷・コストの増大 保持期間の不整合 分析時のログ抜け漏れ 監査担当者 監査・コンプライアンス準備 攻撃の痕跡を追う 統制の証跡を残す 技術的・即応性 形式的・網羅性 詳細な行動ログ・秒単位 何が起きたか即座に知りたい 長期保存・改ざん防止 ルール通り運用されたか証明 本来はどちらも “事実をログから復元する” という共通の目的を持っているはずだが… ISACA東京支部カンファレンス2025 13

核となる主張 「IRの平時対応と監査準備のプロセスは統合できる」 01 02 03 構造が同じ ログ要求の重複 プロセス統合の効果 「証跡の確保」→「分析」→ 「改善」というサイクルは共通 事実を復元し、改善につなげるプ ロセス構造そのものに違いはない アクセスログ、管理者操作ログ、 設定変更ログなど70〜80%の ログ要件は重複しており、 二重管理は無駄を生む 共通ログ基盤・共通運用が 可能になる IR（セキュリティ）と監査 （ガバナンス）が同時に 強化される ログ設計を両方の観点から設定することで、 セキュリティもガバナンスも同時に強くなる ISACA東京支部カンファレンス2025 14

協力の重要性：目的の違い IRと監査では「見ている世界」が違うため、要求事項にズレが生じる IR (インシデントレスポンス) 目的 攻撃の解明・初動対応 ログ粒度 秒単位のタイムスタンプ 保持期間 状況に応じて柔軟 被害範囲の特定と法的リスク最小化 詳細なコマンド操作・パケット記録 調査中は無期限、平時は数ヶ月〜1年 監査 (内部統制) 統制の有効性評価 ルール通り運用されたことの証明 月次・四半期レベル 承認記録・変更申請との突合 法定・規定で固定 3年〜7年などの長期間保存が必須 この違いが埋まらないまま別々に設計すると、 「IR時に監査ログしかなく、何も追跡できない」 という破綻を生む。 ISACA東京支部カンファレンス2025 15

主管部署の違いでもログ要求の違いを生む IR主管 セキュリティ部門 ＋ 法務 監査主管 内部監査部 主な目的 主な目的 攻撃の解明・初動対応 法的リスクの最小化 統制の有効性評価 ガバナンス遵守の証明 求めるもの 求めるもの 攻撃者の行動を追える「細かいログ」 行動トレースが可能で、証拠能力を持つもの 承認や変更記録などの「正式証跡」 期間内の一貫性・改ざん耐性・ 権限管理記録 技術的に深く、即応性の高いログ ルールに適合した、形式的に正しいログ ISACA東京支部カンファレンス2025 16

価値観の衝突 それぞれの立場における「正義」は異なる SECURITY INTERNAL AUDIT LEGAL 「攻撃者を追えない ログなら 意味がない」 「統制証跡として 成立しないログなら 意味がない」 「裁判で通用しない 証拠は 価値がない」 全員正しいことを言っているが、 バラバラに設計すると 組織として破綻する ISACA東京支部カンファレンス2025 17

別プロセスでログ設計すると起きる問題 連携不足がもたらす5つの重大な欠陥 ログ設計・収集の 二重化 コストが倍増し、保持期間の不 整合が発生。 DLPやSIEMの運 用も重複し、リソースを浪費する 。 1 中途半端な 折衷案 妥協した結果、IRにも監査にも 不十分な設計に。 誰の要件も 満たしていない「使えないログ」が 完成する。 部門間の 責任押し付け合い 「それはあっちの部署の管轄」と 放置される。 重要な改善が年 単位で遅れる構造が固定化する 。 ISACA東京支部カンファレンス2025 2 4 インシデント時に 必要なログがない 3 攻撃者の細かい動きが追えない 。 タイムラインが復元できないた め、説明責任を果たせない。 歪んだ企業が でき上がる 5 内部監査は合格するが、攻撃 者の侵入には気づけない。 「形 式は完璧だが、実態は脆弱」な 状態。 18

プロセス統合のメリット IRと監査の壁を取り払うことで得られる、組織全体の4つの価値 共通ログポリシーで 抜け漏れゼロ NIST CSF 2.0 や J-SOX など、異なるフレームワーク の要件を横断的にカバー。 「IRでは必要だが監査で は不要」といった隙間を排除し、コンプライアンスリスク を極小化する。 インシデント分析の スピード向上 監査用に取得していた「正式な証跡」を、有事の際 はインシデントレスポンス（IR）で即座に再利用可 能。 ログ収集の手間を省き、初動対応を大幅に高 速化する。 システム変更時の 調整が一回で済む ログ設計が一本化されるため、システム更改やクラウ ド移行時の設定変更プロセスがシンプルに。 部門間 の調整コストを下げ、ビジネススピードを阻害しない俊 敏性を獲得できる。 コスト最適化 ログの保持・検索・転送・基盤を一本化。 重複してい たストレージコストやSIEMライセンス、運用工数を削 減し、セキュリティ投資の対効果（ROI）を最大化す る。 ガバナンス強化 セキュリティ強化 これらが「トレードオフ」ではなく「相乗効果」になる ISACA東京支部カンファレンス2025 19

まとめ：ログ設計プロセスを統合する価値 Core Value 適切なログ設計は、IRを強化し、監査を強化し、セキュリティガバナンスを底上げします ACTION 統合と連携のプロセス ログ設計プロセスの統合 全部署が協力し共通のルールとして運用し続ける IR 法務 内部監査 今日の話が、皆さまの組織でログ設計プロセスを見直し、 平時のIR対応と監査準備 プロセスを統合することで、 強い体制をつくる一歩となれば幸いです ご清聴ありがとうございました ISACA東京支部カンファレンス2025 20