検出のカテゴリは去年と変更がない模様です。
https://attackevals.mitre-engenuity.org/enterprise/turla/
「Detection Categories」の項目でざっくり説明されています・・・が、2024年2月時点では、前回のような詳しい解説へのリンクが無いようです。
カテゴリの画像から見て、前回とカテゴリの変更は無いようなので、カテゴリの詳しい内容を知りたい方は以下のリンクを参考にしてください。
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は×とする。
- 検出の修飾子は、今回の評価対象では特にスコアには影響しない。
以前は、一つの項目に複数の検知が記載されている場合がありましたが、今回の Evaluation では、一つの項目には一つの検知だけが記録されるようになっていました。また、今回はベンダー毎の各シナリオでの検知数が表示される仕様になっています。
やっぱりこの記事いらな・・・げふんげふん
まあ、検知項目を分類しているから、その傾向の確認や集計しているところに利点がある・・・のかな？（何に使うかはべつとして・・・）
なお、Result>Enterpriseの「Participant(s)」では3つまで複数のベンダーが選択できるようになっており、比較しやすいようになっています。検知時の画面も表示されるので、そういった面も含めて気になる製品を比較するのも良いでしょう。