インシデント対応（IR） — 「有事」における戦術的プロセス

「有事」を指揮する者の思考法

どれほど堅牢に多層防御を敷いたとしても、サイバーセキュリティにおいて「100%の防御」は存在しません。どんな城壁にも必ずどこかに綻びがあり、攻撃者は時間をかけてそこを突いてきます。

企業が生き残れるかどうかの分水嶺は、防御壁が突破された後に「いかに迅速に火災を察知し、延焼を防ぎ、通常業務へ復旧できるか」にかかっています。この一連の火消し作業を インシデントレスポンス（IR: Incident Response） と呼び、IRを専門に取り仕切る組織を CSIRT（Computer Security Incident Response Team） と呼びます。インシデント対応は「防御」の最後の砦であり、事前の準備なしには機能しません。

現場の聖典：NIST SP 800-61 の「6つのフェーズ」

米国国立標準技術研究所（NIST）が発行する「SP 800-61」は、世界中のセキュリティチームが採用しているインシデント対応フローの事実上の標準（デファクトスタンダード）です。インシデント対応は以下の6ステップの循環プロセスで進行します。「終わったら終わり」ではなく、最後のフェーズが次の「準備」に還元される点が重要です。

flowchart TD
  P["① 準備
Preparation"]
  DA["② 検知・分析
Detection & Analysis"]
  CO["③ 封じ込め
Containment"]
  ER["④ 根絶
Eradication"]
  RC["⑤ 復旧
Recovery"]
  PI["⑥ 事後分析
Post-Incident Activity"]

  P --> DA --> CO --> ER --> RC --> PI
  PI -.->|"サイクルとしての継続的改善"| P

  style P  fill:#001020,color:#74c0fc,stroke:#0a84ff
  style DA fill:#001a00,color:#69db7c,stroke:#30d158
  style CO fill:#1a1000,color:#ffe066,stroke:#ffd60a
  style ER fill:#1a0500,color:#ffa94d,stroke:#ff9f0a
  style RC fill:#1a0a0a,color:#ff8787,stroke:#ff453a
  style PI fill:#0a0a20,color:#a5b4fc,stroke:#5e5ce6

NIST SP 800-61が定義するインシデント・ライフサイクル

フェーズ 1: 準備（Preparation）

インシデント発生時の混乱の大半は、このフェーズでの準備不足に起因します。「誰が指揮官（インシデントコマンダー）になるのか」「広報・法務・経営層への連絡ルート」「警察やCERT/CCへの通報基準」などをまとめた IRP（インシデント対応計画書） を事前に策定します。計画書は「存在するだけ」では意味がなく、最低でも年1回、サイバー攻撃シナリオを想定した**机上演習（Tabletop Exercise: TTX）**を実施し、実際のパニック時に機能するかを検証します。

フェーズ 2: 検知と分析（Detection & Analysis）

SIEMのアラートや従業員からの「画面がおかしい」という報告でインシデントを検知するフェーズです。ここで最も重要なのは、パニックに駆られてシステムを即座にシャットダウンしないことです。

Order of Volatility（証拠保全の鉄則）

インシデントの疑いがあるPCの電源をいきなり切ってはいけません。「揮発性の高い証拠」から順に保全するのがフォレンジック（デジタル鑑識）の鉄則です。電源を落とした瞬間に、最も重要な証拠が永遠に失われます。

メモリ（RAM） — 電源を切ると完全に消失する。マルウェアのコード、進行中のプロセス、暗号化鍵がここに存在する
ネットワークの通信状態（netstatの出力など） — 誰と通信しているか
ディスク（SSD/HDD） — 揮発性は低いが、最後に保全する

フェーズ 3: 封じ込め（Containment）

感染が他のシステムへ広がる（ラテラルムーブメント）のを物理的・論理的に遮断するフェーズです。「止める」ことと「証拠を保全する」ことを両立させる難しい局面でもあります。

短期的な封じ込め: EDRを使って感染端末をネットワークから論理的に隔離（Isolate）する。不正に使われているVPNアカウントを凍結する。
長期的な封じ込め: サンドボックス等でマルウェアの挙動を解析し、C2サーバーへの通信先IPアドレスを全社ファイアウォールでブロックする。

フェーズ 4: 根絶（Eradication）

攻撃者の足場を組織から完全に除去するフェーズです。マルウェアの削除、バックドアの無効化、侵害されたすべてのアカウントのパスワードリセット、および侵入経路となった脆弱性への緊急パッチ適用を行います。「1つのバックドアを見逃す」だけで、攻撃者はまた戻ってきます。

フェーズ 5: 復旧（Recovery）

封じ込めと根絶が確認されたシステムから、通常業務へと段階的に戻すフェーズです。クリーンな環境からバックアップをリストアしますが、**「リストア対象のバックアップ自体が、数ヶ月前からすでにマルウェアに感染していないか」**を必ず検証します。感染済みのバックアップから復旧するという最悪のシナリオは、現実に繰り返し起きています。

フェーズ 6: 事後分析（Post-Incident Activity / Postmortem）

いわゆる「ポストモーテム（振り返り）」です。インシデント対応プロセスの中で、長期的に見て最も価値の高い活動です。なぜインシデントが発生したのか、対応にどれだけ時間がかかったのか、どのプロセスが機能しなかったのかを文書化し、次の「①準備」フェーズへフィードバックします。

近代的IRのカルチャー：「非難なきポストモーテム」

Googleなど先進的なテック企業が採用するIR文化が**「非難なきポストモーテム（Blameless Postmortem）」**です。

インシデント後の振り返りで「なぜエンジニアのAさんは不審なメールのリンクを踏んだのか？」「なぜBさんはアラートを見逃したのか？」と**「人（Who）」**を責めることは百害あって一利なしです。人を責める文化は、次のインシデント発生時の「隠蔽」と「報告遅延」を生み出します。担当者は叱られることを恐れて報告をためらい、被害がより深刻になってから発覚するというパターンが繰り返されます。

真のポストモーテムが問うべきは**「システムとプロセス（Why/How）」**の問題です。「なぜシステムは、Aさんがリンクを踏むことを許可してしまったのか？（メールフィルターの不備）」「なぜBさんが見逃すほどアラートが大量発生していたのか？（SIEMのチューニング不足）」——個人ではなく構造的な欠陥を特定し、それを修正することに全力を注ぎます。

理解度チェック

【確認問題】重大なセキュリティインシデント（例: ランサムウェア感染や不正アクセス）が発覚した瞬間、現場の管理者が「検知と分析（Detection & Analysis）」フェーズで絶対に行ってはいけない初動対応はどれですか？