Elastic Securityを使い始めた人のためのMITRE ATT&CK入門

Elastic Securityで検知ルールを有効にしたあと、こんな不安を感じたことはないでしょうか。

ルールはたくさん動いている。でも、これで本当に守れているのだろうか。

ルール一覧では、それぞれのルールを個別に確認できます。しかし、ルール全体が攻撃者のどのような行動を対象にしているのかを、ひと目で把握するのは簡単ではありません。

ここで使う道具が、MITRE ATT&CKです。Elastic Securityには、検知ルールをATT&CKという地図の上に並べて見せる「MITRE ATT&CK coverage」という画面があります。

この記事で扱うのは、次の内容です。

MITRE ATT&CKとは何か
Tactic、Technique、Sub-techniqueの違い
ATT&CK Matrixは攻撃の順番表ではないこと
Elastic Securityの検知ルールとATT&CKの関係
coverage画面の読み方
画面の色が意味すること、意味しないこと

MITRE ATT&CKとは何か
1. ATT&CKが並べているのは「行動」
Tactic、Technique、Sub-technique
ATT&CK Matrixは順番表ではない
なぜElastic SecurityでATT&CKを使うのか
Elastic SecurityのルールとATT&CKの関係
coverage画面の読み方
1. 表示されないルールもある
色が意味すること、意味しないこと
例：Valid Accountsのセルに色が付いていても
補足：AIシステムの脅威にはMITRE ATLASも使われる
まとめ
参考資料

MITRE ATT&CKとは何か

MITRE ATT&CKは、実際の攻撃で観測された攻撃者の行動を整理したナレッジベースです。一言でいうと、攻撃者が何を目的に、どのような方法を使うのかをまとめた共通の地図です。

なぜ共通の地図が必要なのでしょうか。製品や組織が違うと、同じ攻撃を別の言葉で説明してしまうからです。ある製品は「不正ログイン」と呼び、別の製品は「アカウント悪用」と呼びます。話しているうちに、同じ話をしているのか違う話をしているのか分からなくなります。

ATT&CKを使うと、製品に依存しない共通の言葉で話せます。

攻撃者は、盗んだクラウドアカウントを使って環境へ侵入した。これは T1078.004: Cloud Accounts に関係する。

この T1078.004 のような番号をATT&CK IDと呼びます。IDを使えば、チームや製品をまたいでも、同じ攻撃手法について正確に話せます。

なお、ATT&CKにはEnterprise、Mobile、ICS（Industrial Control Systems：工場などの産業制御システム）などの分野があります。この記事で扱うのは、企業のIT環境やクラウド環境を対象にしたEnterprise ATT&CKです。

ATT&CKが並べているのは「行動」

ATT&CKが整理している中心的な対象は、特定のハッシュ値やIPアドレスではなく、攻撃者が行った行動です。

補足として、攻撃者に行動そのものを変えさせるほうが、IPアドレスやハッシュ値を変更させるより難しい、という考え方があります。

Tactic、Technique、Sub-technique

ATT&CKには階層があります。最初は、次の3つだけ覚えれば十分です。

階層	階層	例
Tactic（タクティクス）	攻撃者が達成したい目的。「なぜ行うか」	Initial Access
Technique（テクニック）	目的を達成するための方法。「どうやるか」	T1078: Valid Accounts
Sub-technique（サブテクニック）	Techniqueをさらに具体化した方法	T1078.004: Cloud Accounts

具体例で見てみます。攻撃者が、盗んだクラウドアカウントを使って環境へ侵入したとします。

目的：環境へ侵入する → Initial Access
方法：正規のアカウントを悪用する → T1078: Valid Accounts
具体的な対象：クラウドアカウント → T1078.004: Cloud Accounts

TacticはWhy、TechniqueはHow、Sub-techniqueはもっと具体的なHowだと考えると、区別しやすくなります。

ATT&CK Matrixは順番表ではない

ATT&CK Matrixは、列がTacticになった表です。左から Reconnaissance、Resource Development、Initial Access と並ぶため、攻撃が左から右へ順番に進むように見えます。しかし、実際の攻撃はその順番では進みません。

一部の段階を飛ばす
前の段階へ戻る
同じTechniqueを別の目的で使う
1つのTechniqueが複数のTacticに関係する

例えば T1078: Valid Accounts は、侵入の入口としてのInitial Access、居座るためのPersistence、権限を上げるためのPrivilege Escalationなど、複数のTacticに関係します。同じ「正規アカウントの悪用」でも、攻撃者の目的が違えば置かれる列が変わるということです。

そのためMatrixは、攻撃の決まった手順書ではありません。攻撃者の行動を分類して並べた地図として読むのが適切です。

なぜElastic SecurityでATT&CKを使うのか

理由は、ルール一覧では見えにくいものが見えるようになるからです。ルール一覧はルールを1件ずつ確認する画面です。ATT&CKを使うと、同じルールを攻撃者の行動という軸で並べ替えられます。

セキュリティ運用では、次のような目的で使います。

現在の検知ルールが、どの攻撃手法を対象にしているか確認する
監視できていない領域を見つける
次に収集するログや、追加する検知を検討する

ここで大事なのは、ATT&CKが「すべてのマスを埋めるための表」ではないことです。自社に関係する攻撃手法を選び、そこに必要なログ、検知、予防策を考えます。ATT&CKは、そのために使う道具です。

Elastic SecurityのルールとATT&CKの関係

Elastic Securityの検知ルールには、Threatメタデータを設定できます。これは、そのルールがどのTactic、Technique、Sub-techniqueに関係するかを示す情報です。

prebuilt rule（Elasticが提供する既製ルール）には、あらかじめATT&CKマッピングが設定されている
Custom rule（自組織で作成したルール）には、作成・編集時にAdvanced settingsからマッピングを追加できる

例えば、次の行動を検知するルールがあるとします。

PowerShellを使って、Base64でエンコードされたコマンドを実行する。

このルールには、実際の検知条件（クエリ）だけでなく、関連するATT&CKのTacticやTechniqueも設定されています。Elastic Securityはこのマッピングを読み取り、各ルールをATT&CK Matrix上へ配置します。これが、coverage画面のしくみです。

coverage画面の読み方

Kibanaで次の画面を開きます。ナビゲーションメニューから探すほか、グローバル検索で「MITRE」と入力しても見つかります。

Security >> Detection rules (SIEM) >> MITRE ATT&CK coverage

画面は、大きく4つのパートに分かれています。

フィルター：どのルールを集計に含めるかを決める
検索バー：Tactic名、Technique名、Technique番号、ルール名で絞り込む
Legend：セルの色が何件のルールを表すかを示す凡例
グリッド：Tacticの列と、Techniqueのセルが並ぶ本体

Elastic rules（prebuilt rule）、Custom rules（自組織で作成したルール）、またはその両方

：Enabled rules（有効なルール）、Not enabled rules（未有効のルール）、またはその両方

基本的な読み方は次のとおりです。

列：Tactic
セル：Technique
セルの濃さ：現在のフィルター条件に一致し、そのTechniqueへマッピングされたルールの数

濃いセルには、条件に一致するルールが多くあります。白いセルには、条件に一致するルールがありません。色の基準は画面上部のLegendで確認できます。

セルには、Technique名と、有効なルールがカバーするSub-techniqueの数が表示されます。Expand cellsを選ぶと、有効なルール数と未有効（Not enabled）のルール数も表示されます。セルをクリックすると、関連するルールやTechniqueの詳細を確認できます。

表示されないルールもある

coverage画面に表示されるのは、次の条件を満たすルールだけです。

現在のKibana Space（Kibanaの中で設定を分離できる作業領域）にインストールされている
ATT&CKへマッピングされている
画面のフィルター条件に一致している

したがって、まだインストールしていないprebuilt ruleや、ATT&CKマッピングを設定していないCustom ruleは表示されません。

なお、coverage画面が参照するATT&CKのバージョンは、Elastic Securityのバージョンによって決まります。MITRE公式サイトとKibanaでTactic名が違って見える場合は、この差が原因です。表示不具合ではありません。

色が意味すること、意味しないこと

ここが、この記事でいちばん伝えたい点です。冒頭の不安に戻ります。「セルに色が付いていれば安全なのか」。答えは、いいえです。

coverage画面は、ルールのATT&CKメタデータを使った配置図です。色が付いていても、次のことは何も証明されません。

必要なログが実際に届いている
ルールが正常に動いている
その攻撃を確実に検知できる
誤検知が少ない
Technique全体を網羅している
自組織が安全である

例を挙げます。Windowsのログを必要とするルールをインストールして有効にすれば、対応するセルには色が付きます。しかし、その環境にWindowsログを取り込んでいなければ話は変わります。セルは色付きのままですが、必要なWindowsログが届いていないため、そのルールは期待したアラートを生成できません。

coverage画面から直接分かる中心的な情報は、次のとおりです。

「インストール済みのルールが、ATT&CK Matrixのどのセルに置かれているか。」

言い換えると、coverage画面が答えているのは「このルールは何を狙った検知か」という分類の問いです。「このルールは今ちゃんと動いているか」という実効性の問いには答えません。

反対側も同じです。白いセルは「現在の条件では、そのTechniqueへマッピングされた表示対象のルールがない」ことを示すだけです。ただちにセキュリティ上の欠陥を意味するものではありません。

例：Valid Accountsのセルに色が付いていても

Techniqueは大きな分類です。そのため、同じTechniqueへマッピングされた複数のルールが、同じ攻撃を監視しているとは限りません。

T1078: Valid Accounts は、攻撃者が正規のアカウントを悪用するTechniqueです。ただし、正規アカウントの悪用にはさまざまな形があります。

Windowsアカウントで端末へログインする
VPNアカウントで社内ネットワークへ接続する
AWS IAMユーザーでコンソールへログインする
Microsoft 365アカウントでメールへアクセスする

これらはすべてValid Accountsに関係します。ただし、必要なログも検知条件もまったく異なります。

自組織が心配している攻撃を、次のように想定します。

→ 海外の不審なIPアドレスから、Microsoft 365の管理者アカウントへログインされる。

一方、coverage画面で「Potential Account Takeover – Logon from New Source IP」というルールを見つけたとします。おおまかにいうと、このルールはWindows Security Event Logの成功ログオンを調べ、同じユーザーが普段とは別の送信元IPからログオンしたパターンを探します。

どちらもValid Accountsに関係します。しかし、監視している対象は違います。

確認項目	自組織が心配する攻撃	見つけたルール
対象	Microsoft 365の管理者アカウント	Windowsアカウント
必要なログ	Entra ID（旧Azure AD）などのサインインログ	Windows Security Event Log
結論	クラウド用の検知が必要	Microsoft 365へのクラウドサインインは監視できない

このルールをインストールして有効にすると、coverage画面のValid Accountsセルには色が付きます。

しかし、心配していたクラウドアカウントへの攻撃は監視できていません。このルールが見ているのは、Microsoft 365やEntra IDへのクラウドサインインではなく、Windows Security Event Logに記録されたログオンだからです。

そのためATT&CK IDは、関連するルールを探すための入口として使います。最終的な判断は、そのルールがどのログを読むか、どのプラットフォーム向けか、どの行動を怪しいと判断するかを見て行います。

補足：AIシステムの脅威にはMITRE ATLASも使われる

MITRE ATLASは、AIや機械学習システムを狙う攻撃者の行動を整理したナレッジベースです。ATT&CKと同じように、攻撃者の目的や手法をTacticとTechniqueで整理しています。扱うのは、モデルの窃取、プロンプトインジェクション、モデルへの不正な操作など、AIシステム特有の脅威です。

Elastic Securityのprebuilt ruleには、ATLASに関連付けられたルールもあります。例えば「Potential Azure OpenAI Model Theft」というルールには Mitre Atlas: T0044 というタグが設定されています。このルールは、Azure OpenAIのモデルが不正に取得・複製される可能性のある操作を監視します。

ATT&CKとATLASの両方に関係するルールもあります。外部ネットワークからOllama APIへ接続されたことを検知するルールには、次の情報が設定されています。