検知ギャップの解消とメトリクス

パープルチーミングでは豊富なデータが生成されますが、メトリクスがなければ単なる anecdotal な事例にすぎません。メトリクスによって、演習を経営層や予算責任者に説明できる改善のストーリーに変えられます。

• 防御が実際に改善しているかどうかを示す
• 限られたエンジニアリングリソースをどこに投じるかの優先順位を付ける
• 抽象的な「セキュリティ体制」を具体化し、追跡可能にする

目的は、それ自体を目的とした高得点ではなく、関連する脅威に対する測定可能で持続的な改善です。

主要なメトリクスは検知カバレッジです。これは、テストしたテクニックのうち、アラートが発生したものの割合です。

戦術ごと、および全体について計算します。

カバレッジの割合は誤解を招くことがあります。テストすることを選んだテクニックだけを数えると数値が水増しされ、「カバレッジあり」として脆弱なルールまで数えると、実際の防御力を過大評価してしまいます。

• カバレッジは、恣意的に選んだテクニックの集合ではなく、脅威に関連するテクニックの集合に対して測定する
• 「検知済み」という結果は、堅牢な振る舞いベースのルールによるものでなければならない
• ログのみの結果はカバレッジではありません。カバレッジの候補です

割合には必ず分母を併記してください。「FIN7 のテクニックの 80%」は、単なる「80%」よりもはるかに多くの情報を伝えます。

可視性と同じくらい、対応の速さも重要です。防御の応答性を捉える2つの時間メトリクスがあります。

• MTTD — Mean Time To Detect（平均検知時間）：アクションのタイムスタンプからアラートのタイムスタンプまで
• MTTR — Mean Time To Respond（平均対応時間）：アラートから封じ込めアクションまで

パープルチーミングでは各テクニックの実行時刻を正確に記録するため、複雑なインシデントデータから推定するのではなく、これらを正確に測定できます。

すべてのギャップに同じ緊急度があるわけではありません。テクニックが実行される可能性と、実行された場合の被害の大きさを組み合わせ、リスクに基づいてギャップの順位を付けます。

• 発生可能性が高い + 影響が大きい（例：LSASS ダンプ）= 最初に修正
• 発生可能性が低い + 影響が小さい = バックログへ
• 脅威インテリジェンスにそのテクニックが登場しているかどうかで重み付けする

発生可能性と影響度を掛け合わせた単純なスコアリングにより、現実のリスクを最も軽減できる領域に取り組みを集中させる、修正対応の優先リストを作成できます。

ルールを作成する前に、ギャップが存在する理由を診断してください。根本原因によって修正方法は異なります。

• テレメトリなし — 不足しているデータソースを有効にする（例：Sysmon の設定、スクリプトブロックのログ記録）
• テレメトリはあるがルールがない — 検知を作成する
• ルールはあるが発火しなかった — 抑制しているロジックまたはフィルターを修正する
• アラートは発生したが無視された — コンテンツのギャップではなく、プロセスまたはトリアージの問題

基になるログが収集されていなければ、ロジックのバグを修正しても無駄な作業になります。

最も根本的なギャップは、データが不足していることです。たとえば、PowerShell のスクリプトブロックログは、Group Policy またはレジストリを使って有効にすることで、Event ID 4104 を利用できるようになります。

テレメトリを用意したら、検知を作成し、シグナルが適切になるようチューニングします。チューニングされていないルールは、大量の誤検知でアナリストを疲弊させ、無視される原因になります。

• まずは広めの条件から始め、アーティファクトが現れることを確認する
• 正常なベースラインアクティビティに対する除外を追加する
• 通常のトラフィックを基準に誤検知率を測定する
• エミュレーションを再実行し、攻撃を引き続き検知できることを確認する

攻撃に対して確実に発火し、正常なアクティビティに対しては発火しない状態になって初めて、検知は「完了」です。

1回の演習の数値はある時点のスナップショットにすぎません。実際の状況を示すのは傾向です。四半期ごとにカバレッジと MTTD を追跡してください。

• 第1四半期：カバレッジ 45%、MTTD 22分
• 第2四半期：カバレッジ 62%、MTTD 14分
• 第3四半期：カバレッジ 71%、MTTD 9分

改善傾向は、パープルチーミングが成果を上げていることを示します。横ばいまたは低下傾向は、検知の劣化、あるいは修正が実施されていないことを示します。

環境の変化に伴い、検知は気付かないうちに壊れることがあります。検知をコードと同じように扱い、リグレッションをテストしてください。

• 各サイクルで、以前に成功したテクニックを再実行する
• 継続的な検証を自動化し、壊れた検知がアラートを発生させるようにする
• 検知コンテンツをバージョン管理し、変更をレビューする

ひそかに発火しなくなった検知は、検知が最初から存在しなかった場合よりも、ある意味で悪い状態です。チームが対応できていると信じているのに、実際には対応できていないからです。

報告内容は対象者に合わせてください。エンジニアにはテクニックレベルの詳細が必要ですが、経営層には成果とリスクが必要です。

• エンジニア向け：テクニックごとの結果、作成したルール、チューニングに関するメモ
• 経営層向け：カバレッジの傾向、MTTD の傾向、解消済みおよび残存している主なリスク
• 視覚資料：時間の経過に伴う進捗を示す ATT&CK Navigator のヒートマップ

結果を生の技術データではなくリスクの低減として説明することが、プログラムへの支援と予算を継続させます。

これで、検知カバレッジを厳密に測定し、改善できるようになりました。

• カバレッジ、MTTD、MTTRを中核メトリクスとして使用し、必ず分母も併記する
• 恣意的に選んだ検知や脆弱な検知によるカバレッジの錯覚を避ける
• 修正する前に、各ギャップの根本原因を特定する：テレメトリ、ルール、ロジック、トリアージのいずれか
• 不足しているデータを有効にし、誤検知を抑えるようルールをチューニングする
• 傾向を追跡し、気付かないうちに起きる検知のリグレッションを防ぐ
• プログラムを継続させるため、ATT&CK ヒートマップを使い、リスクの低減として報告する

これで Purple Teaming コースを修了しました。レッドチームとブルーチームを、継続的で測定可能なループとしてつなぎ、防御を実証可能な形で改善する方法を学びました。