MITRE ATT&CK Evaluations (2022)の個人的な結果検証 その４

Mitre Engenuity Att&ck Evaluations の検出カテゴリー

検出のカテゴリは去年と変更がない模様です。

https://attackevals.mitre-engenuity.org/enterprise/wizard-spider-sandworm/detection-categories

内容を要約したものは以下のとおりです（昨年の記事の再掲）。

検出のカテゴリ

• Not Applicable
  • ベンダーがセンサーを配布しなかった等により、評価対象外。
  • 今回のケースでは、主にLinux対応していない製品がLinuxを対象外とした。
• None
  • 今回のEvalietionのシナリオの中で利用可能なデータは得られなかった。
  • 要は未検知かつ情報未収集。
• Telemetry
  • 今回のEvalietionのシナリオの中でイベントが発生したことを示す最小処理データ。
  • データ出力につながる複雑なロジックや高度なルールの証拠はなく、単純なフィールドのラベル付けのみ。
  • 要は収集はされたがアラートとは判定されず、アラートとしては未検知。後で検証する際に証跡が残っている程度の模様。
• General
  • 今回のEvalietionのシナリオの中で、悪意がある、または異常と判定されたイベントが発生したことを示す。
  • 要は収集はされたデータで自動でアラート検知等ができた。
• Tactic
  • 今回のEvalietionのシナリオの中で、収集されたデータからATT&CK戦術または同等の判定ができたもの。
  • 単純なアラートだけではなく、収集はされたデータが詳細に分析され、アナリストに対し「なぜ」それが行われたかが分かる情報まで示す。
• Technique
  • 今回のEvalietionのシナリオの中で、収集されたデータからATT&CKテクニックまたは同等の判定ができたもの。
  • 単純なアラートだけではなく、収集はされたデータが詳細に分析され、アナリストに対し「何が」行われたかが分かる情報まで示す。

検出の修飾子

• Configuration Change
  • テスト開始後に機能の設定が変更された。テストでは追加のデータを収集や処理をするために機能の設定の変更は可能としている。
  • Data Source：センサーによって新しい情報を収集するために行われた変更の場合。
  • Detection Logic：データ処理ロジックに変更を行った場合。
  • UX：ユーザーエクスペリエンスの変更。収集されていてもユーザに表示されていない情報の表示に関する変更の場合。

• Delayed
  • 発見、分析結果の表示に時間が要するもの。
  • システムの処理に必要な最小限度の時間や通信の遅延が原因の場合はこのカテゴリに含まれない。

この記事での「検知」判定のルール

以降の記事では、MITRE ATT&CK Evaluations (2022)の個人的な結果検証 その３に記載したシナリオの項目毎に検知できたかどうかを集計していきます。

検知できたかどうかのルールについては、昨年と同様です。

• 検知したかどうかを重視するため、General、Tactic、Techniqueを〇とする。
• 検知はできなかったものの、後で検証するときに使えるエビデンスがあるということで、Telemetryは△とする。
• 検知も情報収集もできていなかったNoneは×とする。
• 評価は実施項目単位で、複数評価があった場合は一番いいものを評価対象とする。（例：一つの実施項目に「Technique」と「Telemetry」があった場合、「Technique」による検知があったと判断し、その実施項目は「〇」とする。）
• 検出の修飾子は、今回の評価対象では特にスコアには影響しない。

なお、公式でも昨年までと若干集計方法を変更していた模様です。

以前は、１項目に複数の検知が併記されることがあり、それらが全てカウントされていました。つまり、１つの項目にTechniqueが2つ以上あったり、TechniqueとTacticが同時にあった場合、それらが全てカウントされていました。

この合計を表示することの問題点は、項目数に対し実際に検知できた割合が分からなくなる、というものでした。

つまり、10項目あるうち、9項目はNoneでも、1項目にGeneral、Tactic、Techniqueが合計10個もあった場合、検知は「10」と表示されてしまっていました。

こうなると、数字を見ただけでは検知の網羅性が分からない、という問題がありました。

今回は、Resultの各ベンダーをクリックして表示されるサマリに「Analytic Coverage」という項目が追加されており、この値が「検知項目数/全項目数」となっており、記事のルールと全く同じでした。

この値を集計していけば、別にこの記事いらな・・・げふんげふん。

なお、「Telemetry Coverage 」はTelemetryと判定された項目の合計数、「Visibility」は「None」にならなかった項目数の合計（=全項目数 - Noneの数）となっています。

また、公式のResultには「Compare Participants」というボタンがあり、ここから２製品の比較などもできるお便利機能もあります。

この機能にはフィルタ機能もあり、２製品間の検知状況の違いやMitreのTactic観点での絞り込みなども可能です。

気になる製品があるのであれば、この機能を活用するといいでしょう。