インシデント対応計画をどのように構築するか

ほとんどの組織がインシデント対応に失敗するのは、ツールが不足しているからではありません。誰が何をするかについて事前に合意していないため、最初の本当のインシデントが対応ではなく会議になるからです。

プレイブックではなく、フェーズから始める

NIST SP 800-61は4つのフェーズを説定しています：準備（preparation）、検出と分析（detection and analysis）、封じ込め・根絶・復旧（containment/eradication/recovery）、インシデント後の活動（post-incident activity）です。この順序が重要です。チームは生産的に感じられるため、すぐに封じ込めにジャンプしたくなりますが、準備作業をしていなければ、自分たちのネットワークを十分に理解していないため、何も適切に封じ込めることができません。

準備とは、実際に最新のアセットインベントリのことです。2022年のスプレッドシートではありません。ログ保持期間を知ることを意味します（7日であり、攻撃者が30日のdwell timeを持っていた場合、既にタイムラインを失っています）。事前ステージされたフォレンジックツール（Velociraptor、KAPE、あるいはディスクイメージ用のドキュメント化されたtar/ddプロシージャ）を意味します。これにより、アクティブなインシデント中に誰も侵害されたホストにツールをダウンロードしません。

必要になる前に重大度レベルを定義する

SEV1（アクティブなデータ流出、ランサムウェアの起動、ドメイン管理者の侵害）には、SEV3（単一の非特権ワークステーション上の隔離されたマルウェア）とは異なる対応が必要です。これを行列として記述します：影響度対スコープ対信頼度。各重大度に必要な対応時間とエスカレーションパスを割り当てます。SEV1のインシデント指揮官が500ドルごとの購買注文をすべて承認する必要がある同じ人物である場合、独自の緊急プロセスにボトルネックを構築しています。

インシデント指揮官の役割はオプションではない

1人がインシデントを実行します。デフォルトでは最も経験豊富なエンジニアではなく、圧力下で調整、委譲、および封じ込め判断を行うのに最適な人物です。この人物は対応中に必ずキーボードに触れるとは限りません。タイムラインを追跡し、法務とリーダーシップとの通信を管理し、セグメントの分離またはシステムのオフライン化のトリガーを引くタイミングを決定します。

この役割がなければ、5人が同じボックスにSSH接続し、誰も互いに話し合わず、「修正されるかどうか見る」ためにマシンを再起動する前に誰もvolatileメモリをキャプチャしません。

実際に重要な封じ込め判断

ほとんどのインシデントで最も難しい判断は、今すぐ隔離するか、スコープを理解するためにもう少し観察するかです。ネットワークアクセスを早すぎるタイミングで引くと、まだ横方向に移動している攻撃者を警告し、次の動きを見る可能性を破壊します。待ちすぎるとランサムウェアが共有の暗号化を完了させます。

合理的な中間案は、ネットワークセグメンテーションとEDR隔離（CrowdStrike、Defender for Endpoint、SentinelOneはすべてこれをサポート）を使用して、ホストを横方向の移動から遮断しながら、メモリキャプチャ用にホストの電源を入れたままにしておくことです。完全なシャットダウンは最後の手段です。volatileエビデンスを失い、ランサムウェアの場合、一部のペイロードに組み込まれたアンチフォレンジック動作をトリガーできます。

ログギャップを事前にではなく、その間に後悔するでしょう

Windows Event Logのデフォルトでは不十分です。適切な設定のSysmonをデプロイしていない場合（SwiftOnSecurityまたはOlaf Hartongのベースラインコンフィグは良い出発点です）、フラグメントからプロセスツリーを再構築しています。ネットワーク側では、NetFlowまたはZeekログは、ほとんどの組織が必要になるまで認識していないよりも重要です。