Microsoft Security Exposure Management
Microsoft Ignite 2024 のコンテンツや、最近リリースされた機能を見ていると、Microsoft のサイバー セキュリティ関連の開発がますますポスチャー管理にフォーカスしてきていることを感じます。
その中でも特に Exposure Management（以降、露出管理と呼びます）については注力されているなーと感じており、これを使いこなせるかどうかで組織のセキュリティ強度が大きく変わってくるだろうと考えています。
Microsoft のセキュリティ機能を使っている組織であれば、特に追加作業や費用が不要で露出管理の機能を使うことができますので、ぜひ一度ダッシュボード (security.microsoft.com) にアクセスしてみてください。
露出管理は下記のように Microsoft Defender XDR のポータルのカテゴリになっています。
セキュリティ ポスチャーを管理する機能といえば以前はセキュア スコアでしたが、そのセキュア スコアも露出管理のカテゴリの一部に位置付けられていますね。
ポータルからぽちぽちクリックしているだけでもかなり有効な機能であることがすぐ分かりますが、本ブログでは KQL (クエリ) を使って露出管理の恩恵をどのように受けることが出来るかを探っていきたいと思います。
ExposureGraphNodes と ExposureGraphEdges
Defender ポータルの [追及] > [高度な追及] から KQL を実行するためのウィンドウを開き、既定で表示される「スキーマ」列の下の方を見てみると、下記のように「露出管理」セクションの下に 2 つのテーブルが作成されていることが確認できます。この 2 つのテーブルが露出管理の機能を支えています。
上記のテーブル名からも分かる通り、「ノード」と「エッジ」という考え方があり、まず最初にこの考え方に慣れておく必要があります。
ノードはエンティティ（ユーザーやグループ、デバイス、Azure や AWS 上のリソースなど）のことであり、様々なプロパティ情報（名前やバージョンなどに加え、機密性がある、脆弱性があるなどの情報）をもっています。
エッジはノード間の関係性（～を含む、～に認証する、～に影響する、など）を表しています。
この 2 つのテーブルを組み合わせることで、「インターネトに公開されていてクリティカルな脆弱性があるコンピューターからアクセスが可能な重要資産」のような特定の条件で攻撃パスを明らかにすることができ、「インターネットの公開を停止しよう」「セキュリティ更新プログラムを適用しよう」のような対策を攻撃者に先んじて実施することができるようになります。
クエリで出来ること
それでは、上記のテーブルを使って具体的にどのようなことができるのかを見ていきます。
ExposureGraphNodes
ノードは様々なプロパティをもっていますが、例えば criticalityLevel というプロパティがセットされているものがあり、そのエンティティがどの程度の重要性をもっているかを確認することができます。
下記はクエリの実行例ですが、criticalityLevel (0 から 2 までの数値) や、その根拠となるルール (Administrators や Domain Controllers など) が含まれていることが分かります。
※実際のクエリではノードの名前も出せますが省略しています
他にも vulnerableToRCE や vulnerableToPrivilegeEscalation のようなリスクが高い脆弱性をもっているかどうかや、IsInternetFacing や exposedToInternet のようなインターネットに公開されているかを示すプロパティもあります。
下記のクエリでは、RCE (リモート コード実行) の脆弱性がありインターネットに公開されているエンティティを取得しています。
ExposureGraphNodes テーブルだけでも、対策が必要なエンティティを簡単に特定でき、非常に有用であることが分かります。
ExposureGraphEdges
エッジはノードの関係性を表すと前述していましたが、具体的には下記画像の EdgeLabel 列に表示されているような言葉（affecting, has permission to, contains, can authenticate to、など）で表現されます。
例えば、一番上のレコードでは、ある CVE があるデバイスに「影響を及ぼしている」という関係であることが分かりますし、その下のレコードからは、あるユーザーがある Azure リソース (Automation アカウント) に「権限を持っている」という関係性であることが分かります。
クエリ結果からは省略していますが、SourceNode と TargetNode の固有情報（名前や ID）も取得できますので、ノードとエッジを次々に組み合わせていくとで、重要資産に対する攻撃パスを見つけることが出来るようになります。
2 つのテーブルの組合せ
エッジにはノードの細かなプロパティ情報はありませんので、二つのテーブルを組み合わせることにより、ノードの詳細なプロパティとエッジの関係性の情報の両方を使用したより柔軟な条件でクエリ出来るようになります。
例えば、下記のクエリでは「"criticalityLevel が設定されたユーザーが" "権限をもっている" "機密情報を含むストレージ"」を抽出しています。1 行目から 5 行目が変数になっていて、ここを入れ替えることで様々な条件でクエリできます。
Graph Semantic
ここまでは、新しく追加された 2 つのテーブルを KQL でクエリすると出来ることについて説明しましたが、実は最近 KQL に Graph Semantic という機能が追加されており、この機能を使うことでより高度な分析が出来るようになりました。
Graph Semantic の基本的な構文は下記のようになります。
最初に make-graph と実行することでノードとエッジの情報をメモリ上に読み込ませます。
次に graph-match を実行して、ソース ノード (Source) からエッジ [Edge1..3] を経由してターゲット ノード (Traget) に到達するパスを取得します。
ここ普通の KQL にはない書き方で慣れる必要があるのですが、() はノードで、[] はエッジを表していて、その中に記載している Source や Edge という文字列はエイリアスのようなもので適当に命名して OK です。
また、[Edge1..3] は 1 から 3 つまでのエッジを経由したパスを取得してください、という意味になります。
上から 2 つ目のレコードは、あるグループ (A) が何かのロールを持っていて、その何かは別のあるグループ (B) のメンバーで、そのグループはある VM に認証（アクセス）できることを表しています。
つまり、グループ (A) のメンバーであれば VM にアクセスできるということになります。
また、上から 3 つ目のレコードは、あるグループ (A) が何かのロールをもっていて、そのロールは何かのデバイスに認証（アクセス）できて、そのデバイスには Entra ユーザーの Cookie が存在していることが分かります。
最初のグループのユーザーを侵害できれば、VM を経由して Cookie を取得できるということになります。ノードのプロパティ情報を使ってフィルタすることで、"グローバル管理者の Cookie が存在する" "高リスクの脆弱性があるデバイス" のような条件で攻撃パスを見つけることも可能です。
例１
下記のクエリでは、リスクのある脆弱性がありかつインターネットに露出しているソースから Key Vault につながるパスを出力しています。
5 行目から 8 行目まででソース、ターゲット、エッジそれぞれの条件を指定しています。ここの条件として、前半で説明したノードやエッジのプロパティを使うことができます。
なお、上記では 8 行目の条件と同じ条件を 2 行目にも記載していてコメントアウトしていますが、make-graph するノードやエッジのテーブルを最初に where や project で絞り込んでおくことができます。というか、メモリに読み込む前にデータ サイズを小さくするという観点でたぶんそっちの方がいいんだろうなという気がします。
例２
下記のクエリでは、ある特定のノードから 2 パス以内で到達できるリスクのある脆弱性をもったエンティティを列挙しています。
侵害されたもしくはその疑いがあるサーバーがある場合に、そのサーバーからすぐに到達可能な高リスクのリソースを列挙したいなどのシーンが想定されます。
まとめ
露出管理を行うことで、攻撃者の視点で攻撃パスを特定し、インシデントが発生する前に対応することが可能になります。
Defender ポータルから UI で露出管理のダッシュボード情報を確認するだけでもかなり参考になる情報を取得できます。
しかし、クエリにすることで組織特有の条件を考慮した独自の攻撃パスを作成できたり、定期実行した結果を自動通知するなどの自動対応が出来たりするようになります。
上記で紹介したたった 2 つのテーブルですが、とてもたくさんの情報が含まれていますし、その組み合わせも無数にあるためシナリオを考えたり使い方を習得するのは結構大変そうです。しかし、一度習得すれば、これまでと一味違った角度で、非常に有効なセキュリティ対策を提案できるようになると思います。
参考 URL