Azureログモニタリングの課題：SOCのための洞察 by Dmitriy Beryoza

包括的でタイムリーな行動ログは、クラウドにおけるセキュリティ監視と インシデント対応を可能にする強力なツールです。しかし、マイクロソフトのログを調査している間に、私たちの研究者は、ユーザーの行動の理解を複雑にし、攻撃者をすり抜ける可能性さえある多くの欠陥に 気づきました。この投稿では、これらの問題とブルー・チームの作業への影響について説明します。

Azureモニターログを研究する理由

プロバイダー固有の詳細について説明する前に、クラウド環境とオンプレミス 環境ではログの重要性が異なることに注意する必要がある。

管理者は、オンプレミスのセットアップでいくつかの選択肢がある：ネットワーク・トラフィックをタップしてアクティビティを監視したり、ネットワーク・エッジや個々のマシンでログを収集したりすることができる。ロギングとモニタリングのソリューション（ハードウェアとソフトウェア）は交換可能であり、特定のベンダー製品がうまく機能しない場合は、別の製品をインストールすることができる。

クラウドでは、そのような選択肢はありません。利用可能な ログは プロバイダーが完全に管理しています。もしログが高品質であれば、素晴らしいことだ。しかし、もし問題があれば、あなたはプロバイダーの修正意欲に翻弄されることになる。ベンダーに問題を提起し、修正を期待するか、可能な限り回避しようとするかのどちらかだ。

クラウド環境でアクティビティを監視する際には、いくつかの期待がある：

ログの構造や内容を予告なしに変更しない
イベントのタイムリーな記録
完全で正確なログ記録（欠落や破損のない値）
ログに記録されたイベントの完全なドキュメント
異なるログ間でイベントとユーザーセッションを関連付ける簡単な方法
インシデント分析に使用する脅威指標のセット

アクティビティを分析する場合、すべてのログソースおよびすべてのイベントタイプで、以下のデータが一貫して利用可能である必要があります。

作戦名と内容
ユーザーIDとセッション情報
知的財産権
ジオロケーション
デバイス情報
脅威と評判の指標

基本的には、誰がいつ何をしたのか（そして彼らが他に何をしたのか）を知ることができるようにしたい。残念なことに、Azureのログではこのような期待が必ずしも満たされるとは限りません。

マイクロソフト環境におけるイベントの監視方法

Azureには、成熟したイベント分析とモニタリングの製品群がある：

MicrosoftSentinelは、様々なソースからログを取り込むネイティブのSIEM製品です。ビルトインの検出セットが あり、カスタム検出を定義することもできる。
AzureLog Analytics は、不審なイベントのアドホックな調査に最適なログ分析プラットフォームです。

どちらも強力なログ照会・分析言語であるKustoを サポートしている。さらに、サードパーティのソリューションを使用して、ログを監視および解釈することができます。

マイクロソフトの主なログソース

Microsoftのロギング・インフラは膨大で、数百とは言わないまでも数十のログ・ソースがある。そのすべてを論じることは不可能なので、ここではAzureの IAMソリューションである Azure AD（現在はEntra ID）、クラウドSaaSオフィススイートのMicrosoft 365、Azure Cloudから生成されるログに絞って説明しよう。

エントラIDログ

Entra ID ログカバー：

サインイン - インタラクティブ・ユーザー、非インタラクティブ・ユーザー、サービス・プリンシパル、管理されたアイデンティティのサインイン・アクティビティを網羅する複数のログ。
監査-重要なディレクトリ操作の記録
プロビジョニング - 第三者サービスによるユーザーのプロビジョニングに関するデータ

これらのログはグラフAPIを通じてアクセス可能で、現在、基本バージョン (1.0) とベータ版が存在し、それぞれ異なるスキーマを持ちます。

Microsoft 365のアクティビティログ

Microsoft 365 アクティビティログは、Management Activity API を通じて消費され、さまざまな種類のイベントに対していくつかのログが提供されます。

監査.AzureActiveDirectory- Entra ID サービスからのイベント (Graph API 経由で利用できるものと同様)。
監査.取引所- Exchangeイベント
監査.SharePoint- SharePointアクティビティ
監査.全般- 他のどのログにも当てはまらない、その他のほとんどの行動
DLP.All- データ損失防止イベント

アジュールログ

Azureリソースとアクティビティログは、エンタープライズアプリケーション経由で消費され、以下のようなものが含まれます。‍

‍AzureActivity - リソースの作成、削除、変更、ロールの割り当て、ポリシーの変更など、制御プレーンのサブスクリプションとリソースに対して実行されるアクティビティ。
リソースログ- Key Vault のアクセスや NSG フローのログなど、Azure リソース自体から出力される診断ログ。

マイクロソフトログに関する既知の問題

さて、Azure ログ監視の重要性を探ったところで、これらのログで遭遇したいくつかの問題を掘り下げてみよう。それらを認識することで、より良い分析クエリを構築し、なぜそのような動作をするのか疑問に思う時間を減らすことができるかもしれません。

すべてのセキュリティアナリストとアーキテクトが注目すべき具体的な課題には、次のようなものがあります。

ログ収集の課題

ログフロー
イベント遅延
Logging tax
ログに記録されないイベント

対数相関の課題

IDの不一致
IPの不一致
地理位置情報の不一致
デバイス情報の不一致

ログ・コンテンツの課題

流動的なスキーマ
見つからないイベント
不十分な文書
予告なしの変更
壊れた値

それぞれの詳細を見てみましょう。

ログ収集の課題

ログフロー

Azureでは時折ログが停止することがある。実際、私たちは過去数年間に何度か経験した。1つは数週間続き、偶然発見されたが、マイクロソフトは一般的に、このような状況で顧客に通知するのがうまい。

問題なのは、停電の間、環境の動きがまったく見えなくなって しまうことだ。また、たまたま障害アナウンスを見逃してしまった場合、問題があることを示すものは何もない。Azureのサービスの健全性を常に把握し、場合によってはログフローを追跡する監視ソリューションに投資することが不可欠だ。

停止は意図的に行われる場合もあります。ログ構成はインバンドで制御されており、管理者のアカウントが侵害されると、攻撃者が大規模に (例: Set-AdminAuditLogConfig 経由)、またはよりきめ細かくステルス的に (例: Set-Mailbox-AuditEnabled 経由) でログを無効にする可能性があります)。

ログの流れと設定の変更を監視することは、このような問題を軽減するために不可欠である。ログの設定を変更できるのは、少数の許可されたユーザーだけでなければならない。偶発的または意図的なログの無効化によって重大な悪影響が生じるため、Azureがロギング設定により多くの制御を追加することが望ましい。

イベント遅延

マイクロソフトは、ログイベントの可用性の予想時間を公表している。グラフAPIの取り込み 時間は 3分未満.私たちの経験では、これらのソースのイベントが表示されるまで最大30分かかることがあります。

管理アクティビティAPI イベントの一般的な可用性は、次のとおりです 。 60分から90分.現実には、私たちが観察した遅延はもっと重大です。max_delayカラムには、イベントが作成されてからログで利用可能になるまでの最大時間が表示されます：

このような遅延時間は持続不可能だ。攻撃者の中には非常に素早く動く者もいる。検知ツールによる処理、外部SIEMによる取り込み、SOC要員による反応に必要な時間を考慮すれば、多くの場合、ブルーチームが遅れることは明らかです。

攻撃者がツールを自動化すればするほど、状況は悪化する。Azureは迅速なログの可用性を優先する必要がある。そうでなければ、防御側はインシデントに対応するだけで、阻止することはできない。ログレコードが外部のSIEMに転送される場合、イベントの遅延に対処するのはさらに難しくなる。ログAPIコールはパラメータとして時間範囲を取るので、遅いイベントを見逃さないためには、レコードの損失を受け入れるか 、重複する時間範囲をクエリして重複レコードを削除しなければならない。

Logging tax

多くのロギング・イベント・タイプと詳細は、より高い料金のティア（E5やP2など）でしか利用できません。例えば、MailItemsAccessedイベント、サインインログのリスク詳細などです。これは多くのお客様にジレンマをもたらします -低コストか環境内のアクティビティに対するより良い可視性のどちらかを選択することを意味します。

これは強制される良い選択ではなく、基本的なセキュリティ機能 (ログなど) はすべてのクラウド顧客が利用できるべきであると私たちは考えています。米国上院議員ロン・ワイデンが最近述べたように、「ハッキングされないために必要なプレミアム機能のために人々に料金を請求することは、車を売ってからシートベルトやエアバッグに追加料金を請求するようなものです。」

この可視性の欠如は、私たちが調査しなければならなかった多くのVectra AIの顧客インシデントにおいて困難を引き起こしてきた。マイクロソフト自身が対処しなければならなかったAPT Storm-0558による最近の公開侵害は、この問題を公にした。このインシデントの結果、マイクロソフトはCISAと合意し、次のように拡大しました。 ロギングへのアクセス へのアクセスを拡大することに合意した。

すぐに改善されることを願っています。その間に、あなたがライセンスを通じてアクセスできるロギングが、あなたの組織のIRニーズにとって適切であることを確認する必要があります。そうでなければ、アップグレードの時期です。重要なデータが利用できない場合、その一部(IPレピュテーションやジオロケーション情報など）はサードパーティのソースから取得することができます。

記録されないイベントもある

Azureは "偵察天国"であり、設定やデータの読み込みに対応する"get "タイプのイベントは、稀な例外を除いてログに記録されない。2023年10月現在、 Graph APIコールを記録する新しいログが導入され、偵察操作の一部をカバーしている。しかし、他のAPIを介した列挙は、防御側からは見えないままである。

つまり、攻撃者がクラウド環境にアクセスした場合、防御者に見られることなく、ユーザー、サービス、コンフィギュレーションなど、ほとんどの情報を列挙することができる。私たちのテストでは、ほとんどのオープンソースのM365/AAD列挙ツールはログに痕跡を残さなかった。

スペースを節約するためかもしれませんが、このようなイベントをログに記録しないという決定がなされた理由は不明です。残念ながら、顧客がこの種のイベントを確認したい場合でも、そのようなログを有効にするオプションはありません。つまり、攻撃者が環境に変更を加え始めるまでは、暗闇の中にいるということになります。

対数相関の課題

ログを取得したとして、その意味を理解するのは並大抵のことではない。特に、サービス間の相関関係は破綻している。マイクロソフトのEntra ID、M365、Exchange-それぞれが異なるイベントを記録する。その結果、厄介な調査が行われることになる。防御者は、攻撃者のパンくずを追う代わりに、手作業でデータを正規化することに時間を費やすことになる。

攻撃者が最初のアクセスから48分以内に横方向に移動する場合（業界の研究が示しているように）、ログのつなぎ合わせが遅れれば、痕跡を失うのに十分である。

IDの不一致

ユーザー ID は常に「安定」しているわけではありません。コンテキストと操作の種類に応じて、同じユーザーが異なる「ユーザープリンシパル名」(UPN) でログに表示されることがあります。たとえば、ユーザーは次のようにログオンされる可能性があります。

john.smith@company.com
John.Smith@company.com (大文字と小文字の違いに注意)
AN045789@company.com

M365 Exchangeは、以下のようなレガシーな名前 (その他) を追加することで、仕事を台無しにしています。

"NAMPR07A006.PROD.OUTLOOK.COM/MicrosoftExchangeホスト組織/ company.onmicrosoft.com/0cf179f8-0fa4-478f-a4cc-b2ea0b18155e" を代表して

名前の可変性の場合、異なるイベントを同じユーザーに関連付けることは難しくなる。UPNによってイベントを関連付けることは最初の衝動かもしれませんが、一意の内部IDによってそれを行うことは、より強固な戦略かもしれません(しかし、まだ確実ではありません）。

困難は続きます。

異なるログの異なる名前は、異なる意味を持つフィールド名と重複する場合がある。例えば、user_idは、あるログではユーザーGUIDを意味し、別のログではUPNを意味する。
ユーザーIDは、ユーザーの姓名、アプリケーション名、アプリケーションGUID、その他の変わった名前や固有のIDを表す値を持つことがあります。
ユーザーIDが空であったり、"Not Available"、"Unknown"、"No UPN "などの無駄な名前が含まれている可能性があります。

防御側としては、ユーザー ID フィールドでこの (あまり役に立たない) 情報を確認し、それに応じてクエリ機能を構築する準備をしておく必要があります。

IPの不一致

すべてのログレコードには、有効な IPアドレスが基本的に期待されます。有効なIPv4およびIPv6アドレスはほとんどの場合ログエントリで利用できますが、理解するのが難しく、分析に使用するのが難しい IP が見つかることがあります。

ポート番号付きIP(v4とv6の両方）
空のIP
ローカル＆プライベートIP:127.0.0.1、192.168.*、10.*)
オールゼロIP：0.0.0.0
IPの代わりにIPマスク:255.255.255.255
操作を実行するユーザーではなく、Azure インフラストラクチャに対応する IP

IPとサインイン記録との関連付けができない業務もあるため、インシデント分析が複雑になる。IPリスクとレピュテーションの指標は時折利用できるかもしれないが、"ロギング税"の対象となる。

防御側としては、ハンティングクエリやアラートを作成する際にこれらの特殊なケースを想定し、ロジックにそれらを組み込む必要があります。

地理位置情報の不一致

現在、マイクロソフトは、サインイン記録のジオロケーションしか提供していない。アクティビティと特定のサインイン記録を常に結びつけることができないため、これは他のログソースにも役立つはずだ。

この機能は完璧ではありません。場合によっては、問題が発生することがあります。

同じIPが複数の場所に解決される (モバイル機器に関連している可能性が高い)
レコードの地理情報が誤っている。
地理情報が欠落している：

地理位置情報は、TOR、VPN、プロキシ、クラウドプロバイダーの IP にも簡単にだまされるため、割り引いて考える必要があります。

デバイス情報の不一致

デバイスの詳細は、Microsoft が判断するのが複雑です (登録済みのデバイスを扱っている場合を除く)。プラットフォームとブラウザの情報は通常、ユーザーエージェント (UA) から解析されます。

残念ながら、ここにも矛盾があります。

ログによっては、UAを解析して断片的に提供するものもあれば、UA全体の文字列を提供するものもある。
すべてのログでデバイス情報が 利用できるわけではない
解析された値は必ずしも一貫していない（例："Windows "と "Windows 10"）

攻撃者はユーザーエージェントを簡単に偽造できますが、目立たずに変更できるほど十分に訓練されている人ばかりではないため、調査には依然として価値があります。

ログ・コンテンツの課題

ログの収集と関連付けがうまくいっても、その内容が問題を引き起こすことがある。

流動的なスキーマ

一部のログ (管理アクティビティ API など) のスキーマは「流動的」です。これは、新しい操作の一意のパラメータが新しい列としてログに追加されることを意味します。

そのため、Log Analytics であっても管理が困難になります。(「最大 500 列の制限に達しました」というエラーが表示されることが確認されています)。外部 SIEM でイベントを使用することを検討している場合は、使用する列を選択する必要がある場合があります。また、Azureが追加する新しい列を予測することは不可能です。

より良い方法は、すべてのログに静的スキーマを使用し、変動性を処理するために構造フィールド (JSON など) を追加することです。

見つからないイベント

いくつかのイベントタイプは、複数のログで見つかるかもしれない。例えば、サインインの記録は、Graph API と Management Activity API の両方で利用可能です。両方のソースで同じイベントのレコードを比較すると、時折違いが明らかになります。

最近の事件調査から抜粋した次の例を考えてみましょう。これらはすべて攻撃者による同じアクションに対応していますが、ログに記録されたレコードは正確には一致しません。

Graph API (ベータ版 - Azure Portal内)：

グラフAPI(v1.0）：

管理アクティビティ API の AuditAzureActiveDirectory：

この種の不一致は再現したり説明したりするのが困難ですが、ログ分析を行う際には注意する必要があります。記録が失われる可能性があり、何が起こったのかをより完全に把握するには複数のログの分析が必要になる場合があります。

不十分な文書

Azure API は十分に文書化されていますが、ログイベントに関する文書は不足しています。多くのイベントでは、文書化されているのは操作名だけですが、個々のフィールドとその意味は謎であることがよくあります。何が起こっているのかを理解するには、ブログや掲示板をくまなく調べなければなりません。

フィールドの目的が不明確であることに加えて、個々のデータ値もまた文書化されていないことがある。具体的な認証タイプ、ステータスコード、操作のサブタイプ、その他のデータが記述されていないのを見たことがある。徹底的な調査を行っても、これらの値のいくつかは明確にならなかった。

いくつかのフィールドや値を理解していないため、インシデントの調査中やレスポンス、それらを監視したり解釈したりすることができない。

予告なしの変更

クラウドの機能が進化するにつれて (頻繁に行われますが)、新しいイベントタイプが予告なくログに表示されます。例えば、私たちが文書化したパスワードレスサインインの失敗について、新しいエラーコードが追加されました。Vectra AI セキュリティ研究チームは、原因を理解するまでに調査に時間を費やす必要があり、それまで、私たちの監視クエリはそれを認識できませんでした。

さらに厄介なのは、既存のイベントも消滅したり、形式が変わったりする可能性があることだ。最近の例には次のようなものがあります。

私たちが追跡していたMailboxLoginイベントが、Exchange ログから静かに消えてしまった。
偵察活動の初期段階をキャッチするために追跡していた、存在しないユーザー名のサインインエラーは、サインインログに書き込まれなくなった。

特定のイベントを検索する監視および分析クエリがある場合、これらの変更により警告なしに機能が停止します。これは最悪の種類の失敗です。問題があることにさえ気づいていないときです。ログの整合性を監視し、ログの内容とドキュメントの変更を注意深く監視するためのロジックに投資する必要がある場合があります。残念ながら、ほとんどのディフェンダーは忙しすぎて、そのことに時間を費やすことができません。

壊れた値

一部のログフィールドは複雑な構造 (JSON など) を持っており、ハンティングクエリやモニタリングクエリでは特定のサブフィールドを参照するためにそれらを解析する必要があります。

場合によっては、サイズ制限によりこれらの値が切り捨てられ、構造が壊れる場合があります。たとえば、Set-ConditionalAccessPolicy 操作に関してログに記録された次の値を考えてみましょう。その一部が切り取られ、3 つのピリオド (「...」) に置き換えられます。これにより、JSON パーサーが混乱します。

このようなレコードに遭遇した監視クエリは失敗し、盲点が生じる。

このような場合、正しく解析された値に依存することは最善の戦略ではない可能性があり、部分文字列検索の方がうまく機能する可能性があります。

レッドチームにとっての収穫

ここまでは、これらの問題がチームにもたらす困難についてだけ話してきた。しかし、防御者の損失は攻撃者の利益であることを忘れてはならない。有能なブラックハット、APT、およびレッドチーマーは、Azure ロギングの特殊性を利用して自分の行動を隠し、ブルーチームの取り組みを複雑にすることができます。

攻撃者が使う可能性のあるテクニックをいくつか紹介します。

あまり文書化されていない、あるいは理解されていない特殊な操作を使用する。
壊れた値や文書化されていない値をログに注入するアクションを実行し、分析を複雑にする。
IPまたはジオロケーション情報が正しく記録されていない場所からの接続
取り込みの遅れを利用したり、関連イベントの発見を複雑にするようなタイミングでの操作。

もちろん、ロギングの欠陥を強力な回避手法に変えるには、さらなる研究が必要になります。

ディフェンダーに何ができるか？

クラウドセキュリティチームは、懐疑的かつ戦略的にマイクロソフトのログにアプローチする必要がある。以下は3つの必須事項である：

表面的な見方を信用しない - ログの流れと完全性を定期的に検証する。ギャップを監視する。ロギングが無効または中断された場合のアラートを構築する。
よりスマートなクエリを作成し、信頼できるベンダーの支援を受ける- ID、IP、アクティビティデータがサービス間でどのように記録されるかを理解する。不整合を考慮する。可能であれば、表示名よりもGUIDを優先する。
マイクロソフトの顧客は、正確で、タイムリーで、十分に文書化されたログを得る資格がある。防御者がこれらのギャップに苦労すれば、攻撃者はそれを悪用するだろう。シグナルが改善されれば、セキュリティの成果は向上する。

Vectra AIでは、ログを正規化し、エントリーの重複を排除し、ログが壊れていても攻撃者の行動を検出するなど、これらの課題を克服するために深く投資してきた。しかし、業界のベースラインを引き上げるためには、クラウド・プロバイダーからのより良い遠隔測定基準も必要です。

ログの品質を向上させるには何が必要か

Azure のログ品質を批判しているのは私たちだけではありません (同様の問題は以前CrowdStrikeや EricWoodruffも指摘) 。なぜこれほど多くのログ品質が存在するのかについては推測することしかできません。

通常、ログはソフトウェア開発において優先的に他の機能より後回しにされます。開発チームが主要な製品機能をリリースする必要がある場合、バックエンドサービス機能が犠牲になる可能性があります。

Azure のような巨大な製品エコシステムでは、複数の独立した (場合によってはレガシーな) 製品がまとめられています。一般的なロギングアーキテクチャですべての機能に適切なシグナルを提供することは難しい場合があり、この機能は厳密には「顧客対応」ではないため、それに関する苦情は優先順位が低くなる可能性があります。

理由が何であれ、クラウド環境には代替手段がないため、ログの問題は従来のオンプレミス設定よりもはるかに深刻になります。防御側には、ログの欠陥を認識し、その一部を回避しようとする以外に他の選択肢はありません。この機能は Microsoft が所有しており、それを改善するかどうかは Microsoft の責任です。

私たちは、Azureチームによって、多くの非侵入的な変更が可能である（そして、そうすべきである）と考えています。

すべてのイベント、フィールド、および列挙値は、ログ解析の手間を省くために、完全に文書化されなければなりません
ログの構造と内容は、APIのように扱われるべきである。ログの照会機能を壊す可能性のある変更は、管理された方法で導入されるべきであり、顧客は変更に対応するための時間を与えられるべきである
伐採された作業の追加や特に撤去はすべて、明確に公表されなければなりません
記録は、現在よりもはるかにタイムリーに、数分や数時間ではなく数秒単位で配信されなければならず、イベントが遅れたり、順番通りに届かないことがあってはなりません
記録される値はすべて、有用で、正しく、曖昧であってはならない
ログには、インシデントレスポンス (例えばIPレピュテーション）に役立つ豊富な情報が含まれていなければならない

理想的には、ロギングアーキテクチャをリファクタリングして (AWS や Oktaで利用可能なものと同様に) より合理化すると有益です。

ディフェンダーの仕事は大変だ。攻撃を素早く検知修正することは大変な仕事であり、問題をマインドログして回避しなければならない場合は、さらに手間がかかる。

クラウドのセキュリティ向上という約束は決して夢物語ではなく、その実現に貢献する方法の1つは、高品質のロギングを提供することである。プロバイダーはこれを実現する力を持っていますが、最優先の目標にするインセンティブに欠けているかもしれません。そこで我々の出番となる。セキュリティ研究コミュニティが暴露すればするほど、そして私たちが圧力をかければかけるほど、私たちはログの質の向上に近づくことができるのです。

会話に参加したいですか？このブログ記事やその他のトピックについて 、 Redditで Vectra AIセキュリティ研究チームと直接会話してください。

Azureログモニタリングの課題：SOCのための洞察