DeTT&CT入門 MITRE ATT&CK を「防御視点」で活用するアプローチ
はじめに
MITRE ATT&CK は、攻撃者の行動を体系化したフレームワークですが、実務での活用は「攻撃者の視点」に偏りがちです。
しかし、セキュリティ体制の強化には「攻撃をどこまで検知できるのか」という防御視点での整理が不可欠です。
この記事では、防御視点から「可視性」や「検出能力」を評価し防御ギャップを可視化できるDeTT&CTフレームワークについて紹介します。
ATT&CKの活用が攻撃視点に偏る理由
ATT&CKの活用を考える際、攻撃視点に偏る理由として以下が考えられます。
-
フレームワークの構造的な理由
ATT&CKは攻撃者の行動(テクニック)を体系化したナレッジベースであり、「攻撃者が何をしたか」を起点に整理されているため、そのまま使うと攻撃視点に寄り安い点が挙げられます。 -
利用のしやすさ
どのテクニックを使われたかを書きやすいインシデント分析や、シナリオを組みやすいレッドチーム活動など、攻撃を並べる用途はすぐに成果が見えるため採用されやすいです。 -
防御視点は難しい
どのデータソースから、どのテクニックが検知可能かを正確に整理するのは手間がかかります。
加えて、ログの可視性や保持期間は組織ごとにことなります。
攻撃視点のマッピングと比べ、防御視点でのマッピングは難しく後回しにされがちです。 -
組織内の役割分担の影響
レッドチームやインシデント対応チームは、「攻撃行動」に着目するのが仕事でるため、ATT&CKとの相性が良いです。
ATT&CKの情報をそのまま「攻撃のカタログとして参照する」という使い方で対応できることが多いためです。
防御や可視性を整理するのはブルーチームの領域ですが、体制が弱いと十分に実施されず後回しになってしまいます。
ATT&CKには「攻撃者の行動」が組み込まれているので、「攻撃視点」のユースケースとは相性が良いです。
一方、「テクニックを検知できるか」といった防御側の整理には、ATT&CKに閉じておらず防御側の観測体制に依存します。
そのため防御側の整理には追加の労力と体制が必要となります。
例:
- MITRE ATT&CKのProcess Creationテクニックを検知するには、OSログが必要
- Command and Scripting Interpreterを検知するには、コマンドライン引数の取得が必要
防御ギャップ
防御視点では、具体的な攻撃に対して自身のシステムが防御できる状態になっているかを評価し、問題がある場合は攻撃と防御の間のギャップを埋める対処を考える必要があります。
攻撃と防御の間のギャップのことを防御ギャップと言います。
防御ギャップとしては、以下のような種類が考えられます。
防御ギャップ:
- 監視/検出ギャップ: 攻撃を監視できるか、検出できるか
- 防御(阻止)ギャップ: 攻撃を防御(阻止)できるか
- 対応/回復ギャップ: 攻撃への対応、攻撃からの回復ができるか
- 運用/管理ギャップ: 攻撃に対して適切に運用/管理ができるか
本記事では、防御ギャップのうち監視/検出ギャップについて考えます。
監視/検出ギャップとは
システムに対する攻撃ついて防御側が実現したいのは、その攻撃を検出することです。
その攻撃を十分に検出できない場合、攻撃と防御の間に検出ギャップが存在します。
検出を行うためには、その攻撃が発生していないかを監視する必要があります。
その攻撃に対して十分に監視できていない場合、攻撃と防御の間に監視ギャップが存在します。
単純に「できている/できてない」というだけではなく、どの程度できていて、どの程度できていないのかという評価値を用意する必要があります。
ATT&CKには、あるテクニックに対する監視手法や検出手法についての情報が含まれていますが、監視や検出についての評価値をどのように算出すべきかという防御側の情報は含まれていません。
このことは、監視/検出ギャップを評価値として定量的に算出するためには、別途仕組みや決まりを導入する必要があることを意味します。
DeTT&CTとは?
DeTT&CT(Detect Tactics, Techniques & Combat Threats)は、Rabobankが開発したATT&CKを防御視点で使うために独自拡張したフレームワークです。OSSとして公開されており、ATT&CKベースの防御(監視/検出)カバレッジ評価を支援します。
DeTT&CTは、ATT&CKに組み込まれていない以下の機能を、フレームワークとして提供します。
DeTT&CTの機能:
- ATT&CKの攻撃による脅威マップを、検出能力マップに変換する
- 防御カバレッジのギャップ分析を可能にし、優先的に強化すべき領域を明確化できる
- YAMLベースで継続的に更新・共有・自動化できる
ATT&CKのみを使う場合は、ATT&CKフレームワーク外の部分を自前で1つずつ検討/実装して行く必要があります。
DeTT&CTを利用することにより、組織のセキュリティ可視性/検出能力の整理/評価を、フレームワークを利用して実施することができます。
監視/検出
DeTT&CTでは、監視/検出を次のように考えます。
監視:
あるATT&CKテクニックに対して、攻撃を特定するための情報をどの程度見ることができるか(可視性スコア)という観点で考えます。
攻撃を特定するための情報は、DeTT&CT上「データソース」という用語で呼ばれます。
DeTT&CT上のデータソースは、ATT&CKのデータコンポーネント(データソースの細分類)に対応します。
加えて、DeTT&CT独自で定義するデータソースもあります。詳細は後述します。
検出:
あるATT&CKテクニックが、実際にアラートとしてどの程度の品質で検出されるか(検出スコア)という観点で考えます。
DeTT&CTにおけるデータソース
DeTT&CTにおけるデータソースとは、攻撃を特定するための情報を指す用語です。
ATT&CKにおけるデータコンポーネントを、DeTT&ACTのデータソースとして採用しています。
また、DeTT&CT独自のデータソースもいくつか定義されています。
例として、T1059.006(Command and Scripting Interpreter: Python)について考えます。
T1059.006に紐付くデータソース、データコンポーネントは次の通りです。
- DS0017(Command - Command Execution)
- DS0009(Process - Process Creation)
このテクニックを特定するためには、Command ExecutionあるいはProcess Creationの情報が必要であることがわかります。
可視性(Visibility)
可視性とは、あるATT&CKテクニックに対して、攻撃を特定するための情報の見えやすさを示す指標です。
T1059.006(Command and Scripting Interpreter: Python)の場合、Command ExecutionとProcess CreationがDeTT&CTのデータソースであり、この攻撃を特定するための情報となります。
DeTT&CTデータソースの両方の情報が利用可能である場合、T1059.006の攻撃をより特定しやすい(見やすい)状態と言えます。
仮に、Command Executionは利用可能であるが、Process Creationは情報を採取していないなど利用不可の場合、T1059.006の攻撃を見逃す可能性が高まります。
また、利用可能なデータソースであっても、テクニックを特定するための情報の内容(品質)に問題がある場合は、攻撃を見逃す可能性が高まります。
このような攻撃の見やすさ(可視性)に対して割り振るスコアを、可視性スコアと呼びます。
可視性スコア:
| スコア | スコア名 | 説明 |
|---|---|---|
| 0 | None | 完全に可視性がない状態。攻撃が発生しても痕跡をまったく確認できない |
| 1 | Minimal | 攻撃が発生した場合、その攻撃は部分的にしか見えない。攻撃を特定するために十分なデータ品質を持つデータソースがいくつか存在するが、複数のデータソースのうちほんの一部にすぎない状態 |
| 2 | Medium | 攻撃が発生した場合、その攻撃を複数のデータソースから特定できる。Minimalよりも多くのデータソースに対応している。データの品質についてもまだ十分ではないところがある |
| 3 | Good | 大部分のデータソースが利用可能であり、データ品質も十分 |
| 4 | Excellent | 完全に網羅している。攻撃を特定する全てのデータソースが利用でき、データ品質も十分 |
判断例:
- PowerShellのみプロセス生成イベント(4688)が収集されているが、コマンドライン引数は記録されていない
- 実行事実はわかるが詳細が不明
- スコア1(Minimal)
- 4688イベントに加え、コマンドライン引数とスクリプトブロックログが収集されている
- 攻撃の痕跡を多面的に把握可能
- スコア3(Good)
可視性を可視化すると、次のように見えます。
データ品質(Data Quality)
データ品質は、次の5つの観点で評価します。
データ品質に対する5つの観点
| 観点 | 説明 | スコア付けの際の確認事項 | 例 |
|---|---|---|---|
| デバイスの完全性 | 必要なデータがすべてのデバイスで利用可能かどうか | ハンティング調査を行う際に必要な全てのデバイス/ユーザをカバーできているか | 古いバージョンのWindowsを実行しているエンドポイントについて、イベントデータが見つからない |
| データフィールドの完全性 | データに、必要な情報/フィールドがどの程度含まれているか、またそれらのフィールドにデータがどの程度含まれているか | イベントの必須データフィールドがすべて存在し、調査を時刻するためのデータが含まれているか | プロキシログはあるが、イベントには「Host」ヘッダが含まれていない |
| 適時性 | データがいつ利用可能な状態になるか、イベントが発生した実際の時間に対するタイムスタンプの正確さ | データが必要なときにすぐ利用できるか。データ内のタイムスタンプは、レコードが作成または取り込まれた時刻を表しているか | すべてのエンドポイントから必要なデータをセキュリティデータレイクに取り込むまで、1日から2日の遅延が発生している。タイムスタンプはイベントの発生時刻ではなく、セキュリティデータレイクへの取り込み時刻を表している |
| 一貫性 | データフィールドの名前とタイプについての標準化状態 | イベントを他のデータソースと相関させることができるか。特定のフィールドに標準の命名規則を使用して、すべてのデータソースに対してクエリを実行できるか | このデータソース内のフィールド名は、他のデータソースのフィールド名と一致していない |
| 保持 | 希望するデータ保持期間と比較して、データが保存される期間を示す | データはどのくらいの期間利用できるか。データをどの高麗の期間保存するか | データは30日間保存されるが、理想的には1年間保存したいと考えている |
データ品質の5つの観点ごとに以下の観点でデータ品質スコアを割り振ります。
データ品質スコア:
| スコア | デバイスの完全性 | データフィールドの完全性 | 適時性 | 一貫性 | 保持 |
|---|---|---|---|---|---|
| 0 - None | 不明/文書化されていない/該当しない | 不明/文書化されていない/該当しない | 不明/文書化されていない/該当しない | 不明/文書化されていない/該当しない | 不明/文書化されていない/該当しない |
| 1 - Poor | データソースはデバイスの1~25%から利用可能 | 必須フィールドは1~25%の範囲で使用可能 | データが利用可能になるまでに長い時間がかかる。データ内のタイムスタンプが、実際のイベント発生時刻と大きく異なる | フィールドの1~50%の名前とタイプが標準化されている | データの保持期間は希望時間の1~25%以内 |
| 2 - Fair | データソースはデバイスの26~50%で利用可能 | 必須フィールドは26~50%で利用可能 | データの保存期間は希望時間の26~50%以内 | ||
| 3 - Good | データソースはデバイスの51~75%から利用可能 | 必須フィールドは51~75%で利用可能 | データが利用可能になるまでには少し時間がかかるが許容範囲内。データのタイムスタンプは実際のイベント発生時刻と若干ずれがある | フィールドの51%~99%の名前とタイプが標準化されている | データの保持期間は希望時間の51~75%以内 |
| 4 - Very good | データソースはデバイスの76~99%で利用可能 | 必須フィールドは76~99%利用可能 | データの保持期間は希望時間の76~99%以内 | ||
| 5 - Excellent | データソースは100%のデバイスで利用可能 | 必須フィールドは100%利用可能 | データはすぐに利用可能。データ内のタイムスタンプは100%正確 | フィールドの名前とタイプは100%標準化されている | データは、希望する保存期間の100%保存される |
データ品質スコアは、可視性スコアを算出する際の根拠として使います。
検出(Detection)
DeTT&CTでは、検出のための7つのスコアが示されています。
検出スコアは総合点と考えれば良いです。経営層や全体像を俯瞰する場面で利用します。
検出力を総合的に「高い/中程度/低い」と一目で判断したいようなケースで使います。
検出スコア:
| スコア | スコア名 | 説明 |
|---|---|---|
| -1 | None | 検出が全く行われていない状態 |
| 0 | Forensics/context | 検出はないが、フォレンジック用途やコンテキスト把握のためにログが記録されている状態 |
| 1 | Basic | 基本的なシグネチャでテクニックの一部のみを検出。検出の対象範囲が狭く、見逃し(False Negative)が覆い可能性。誤検知(False Positive)が多い場合もある。リアルタイム性は保証されないことがある。 |
| 2 | Fair | 単純なシグネチャに加え、相関ルールを用いて検出範囲を広げている状態。「Basic」よりは見逃しが減るが、依然として誤検知や見逃しが存在。リアルタイムとは限らない |
| 3 | Good | より高度な分析を用いてテクニックの多くを検出可能。回避や難読化には部分的弱いが、リアルタイムでの検知が可能。誤検知はあっても識別しやすく、除外可能な場合が多い |
| 4 | Very good | ほとんどの側面をリアルタイムで検出可能であり、非常に高い検出力。回避手法にも強い。誤検知は少なく、あっても認識除去が可能。見逃しも少ない |
| 5 | Excellent | 「Very good」と同等の検出力に加え、全ての既知の側面をカバーしている状態。見逃しの可能性はさらに低い |
また、検出スコアをさらに細分化した側面別検出スコアもあります。
側面別検出スコアは、セキュリティ運用や検知ルール改善の現場で利用します。
誤検知は少ないけれど検知の網羅性が低いため追加ルールを作ろう、といった改善点の洗い出しに使うことができます。
側面別検出スコア(Detection Scores by Aspects):
| スコア | スコア名 | 検出の度合い | タイミング | テクニック全体のカバー度 | 回避の可能性 | False Negative | False Positive |
|---|---|---|---|---|---|---|---|
| -1 | None | 全くなし | - | 全くなし | - | - | - |
| 0 | Forensic/context | 全くなし | 即時とは限らない | 検出対象無し | - | - | - |
| 1 | Basic(Signature based) | 基本的なシグネチャ | 即時とは限らない | ごく一部の側面のみ | 回避・難読化の可能性あり | 多い | 多い可能性 |
| 2 | Fair(Correlation rules) | 相関ルールなどを利用 | 即時とは限らない | Basicより多くの側面をカバー | 回避可能性あり | 多い可能性 | 存在する可能性 |
| 3 | Good | 複雑な分析を活用 | リアルタイム | 既知の多くの側面をカバー | 回避可能性あり | 存在 | 識別しやすく、除去可能な誤検知あり |
| 4 | Very good | 複雑な分析を活用 | リアルタイム | ほぼすべての側面をカバー | 回避は難しい | 少ない | 識別しやすく、除去可能な誤検知あり |
| 5 | Excellent | 複雑な分析を活用 | リアルタイム | 全ての既知の側面をカバー | 回避は難しい | 非常に少ない | 識別しやすく、除去可能な誤検知あり |
検出スコアを可視化すると次のように見えます。
DeTT&CTが管理するもの
DeTT&CTは、大きく2つの情報、データソースとテクニックをを管理します。
データソース管理ファイルにデータソース群を、テクニック管理ファイルにテクニック群を、YAML形式で格納します。
各管理ファイルは、YAMLファイルを自身やツールなどで生成/操作するか、DeTT&CTに付いているDeTT&CT エディターというWebアプリを使って生成/操作します.
データソース管理ファイル
データソース管理ファイルでは、複数のデータソース情報を格納します。データソース情報には以下の内容が含まれます。
データソース情報:
- DeTT&CTにエントリを登録した日付
- データソースをセキュリティデータレイクに接続したときのデータ
- データがどの製品に保存されているか
- データソースが適用されるシステムの種類
- データソースをデータ分析に使用できるかを示すフラグ
- コメント
- データ品質
- 任意のキーと値のペア
テクニック管理ファイル
テクニック管理ファイルでは、複数のテクニックに関する情報を格納します。
テクニック管理ファイルには、テクニックごとに可視性と検出スコアを含めた以下の内容を記録します。
- 可視性が適用されるシステムのタイプ(Windowsエンドポイント、Linuxサーバなど)
- コメント
- 可視性スコア
- 検出スコア
- 独自のキーと値のペア
DeTT&CTにおけるアウトプット
DeTT&CTを使うと、データソース管理ファイル、テクニック管理ファイルを使って以下のアウトプットを出すことができます。
データソース網羅率の可視化
データソース管理ファイルを可視化すると、データソース網羅率を表現した、Navigator用のレイヤーファイルを生成することができます。
データソース網羅率とはATT&CKの各テクニックごとに攻撃を特定するための情報として定義されているデータソース(データコンポーネント)のうち、DeTT&CT上いくつのデータソースを利用可能な状態として登録しているかという割合を、ATT&CKマトリクスに表現したアウトプットになります。
例として、T1059.006(Command and Scripting Interpreter: Python)を考えます。
T1059.006(Command and Scripting Interpreter: Python
ATT&CK上、T1059.006は、Command ExecutionとProcess Creationがデータソースとして登録されています。
T1059.006を特定する全データソースは、ATT&CKのデータコンポーネントであるCommand Executionと、Process Creationの2つが挙げられています。
防御ギャップを評価する環境(Domain: Enterprise、Platoform: Windows)において、Command ExecutionとProcess Creationのうち利用可能なデータソースの割合がどの程度あるのかというのが、ある攻撃に対する(DeTT&CTにおける)データソース網羅率を表します。
DeTT&CTでは、データソース管理情報を基にデータソース網羅率を可視化することできます。
データソース網羅率
データソース網羅率が高いと、特定の攻撃をより的確に検出できる可能性が高まります。
データソース網羅率が低いと、特定の攻撃が発生した場合に、検出の取りこぼしが発生したり必要な情報が十分得られないといった可能性が高まります。
データソース網羅率は、可視化用のNavigator用ファイルの生成時に、0~100%の間で算出されます。
データソース管理ファイル内の各データソースについて、利用可能なフラグがついているかを算出の情報源としています。
算出のロジックは、ソースコードの以下の箇所が該当します。
データソース管理ファイルのxlsx出力
データソース管理ファイルの内容をxlsxとして出力することができます。
データソース管理ファイルのxlsx出力1
データソース管理ファイルのxlsx出力2
テクニック管理ファイルの生成
テクニック管理ファイルには、ATT&CKテクニックが1つずつ登録されています。
それぞれのテクニックごとに、可視性および検出についてスコアを設定していくことになります。
DeTT&CTではデータソース管理ファイルを基にして、テクニック管理ファイルを生成することができます。
登録されるテクニックは以下の2パターンになります。
- データソース管理ファイルに書かれている内容に基づき、データソース網羅率が0より大きくなるテクニックだけを登録する (
--yamlオプション指定時) - 全テクニックを登録対象とする(
--yaml-all-techniquesオプション指定時)
テクニック管理ファイル内の、各テクニックに対する可視性スコアは、データソース網羅率により算出される大まかな値が入ります。
:message
大まかな可視性スコアは、以下の箇所で付けられています。
my_dsには、データソース管理ファイル内で利用できると判断されているデータソース一覧が入っています。
あるテクニック(t)に関連付いたデータソースを、attack-stix-dataから収集し、my_dsと比較し満たしている割合を算出します。(データソース網羅率と同じロジック)
その結果に基づいて、以下の判定で可視性スコアを1から4の値で割り振っています。
result = (float(ds_count) / float(total_ds_count)) * 100
ds_score = 1 if result <= 49 else 2 if result <= 74 else 3 if result <= 99 else 4
あるテクニックに関連付いたデータソースが1つも有効ではない場合は、ds_count が0になるため前段で ds_score が0のまま処理が進みます。結果として、可視性スコア0になります。
:::
用語について
データソース
データソースとは、システム、セキュリティアプライアンス、ネットワークデバイスなどによって生成される生のログまたはイベントのことを指します。ATT&CKには30種類以上のデータソースがあり、それらはさらに90種類以上のデータコンポーネントに分割されています。
これらのデータソースは、データソース管理ファイル内で管理され、各データソースについてデータ品質のスコアリングが可能です。
可視性
DeTT&CTでは、可視性はATT&CKテクニックの痕跡を確認するのに十分は品質のデータソースが十分にあるかどうかを示すために使用されます。
可視性はインシデント対応、ハンティング調査の実行、検知の構築に不可欠です。
DeTT&CTでは、ATT&CKテクニックごとに可視性の範囲をスコアリングできます。
可視性スコアはテクニック管理ファイルで管理されます。
検出
適切なデータソースと十分な品質を備え、データ分析に利用できる状態であれば、その可視性を活用してATT&CKテクニックに対する新たな検出を作成できます。
検出は多くの場合アラートをトリガーするためブルーチームがフォローアップします。
検出のスコアリングと管理は、テクニック管理ファイルで行われます。
まとめ
監視/検出カバレッジ評価を支援する、DeTT&CTフレームワークについて紹介しました。
次回の記事では、DeTT&CTエディタおよび、データソース/テクニック管理ファイルについて紹介します。
- DeTT&CT入門2: https://zenn.dev/sesamum/articles/c5c4f5fbb25751
参考情報
- DeTT&CTの公式GitHub: https://github.com/rabobank-cdc/DeTTECT
関連記事
MITRE ATT&CK関連記事一覧
Discussion