Microsoft Sentinel の新機能

  • [アーティクル]

この記事では、Microsoft Sentinel 用に最近追加された機能と、Microsoft Sentinel のユーザー エクスペリエンスを向上させる関連サービスの新機能について説明します。

リストされた機能は、過去 3 か月間にリリースされました。 以前に提供された機能については、Tech Community のブログを参照してください。

機能とサービスの最近の変更に関する、重要なお知らせを参照してください。

Note

米国政府機関クラウドにおける機能使用可否の詳細については、「米国政府機関のお客様向けのクラウド機能の利用可能性」に記載されている Microsoft Sentinel テーブルを参照してください。

2023 年 5 月

Upload Indicators API を使って脅威インテリジェンスを接続する

脅威インテリジェンス プラットフォームまたはカスタム ソリューションを接続して Microsoft Sentinel にセキュリティ侵害のインジケーター (IOC) を追加するための、新しい API と機能強化された API があります。 データ コネクタとそれが依存する API は、次の点が強化されました。

  • 脅威インジケーター フィールドは、STIX 仕様の標準化された形式を使います。
  • Azure Active Directory (Azure AD) アプリケーションの登録には、Microsoft Sentinel 共同作成者ロールのみが必要です。
  • API 要求エンドポイントのスコープはワークスペース レベルであり、必要な Azure AD アプリケーションのアクセス許可により、ワークスペース レベルでのきめ細かい割り当てが可能になります。

詳細については、TI Upload Indicators API データ コネクタに関する記事を参照してください。 詳細については、基となる TI Upload Indicators API を参照してください。

脅威インテリジェンス プラットフォーム データ コネクタは非推奨になる予定です。 正確なタイムラインの詳細については、今後お知らせします。 新しい Microsoft Sentinel ソリューションには、Microsoft Graph 脅威インテリジェンス Indicator API ではなく、Upload Indicators API を使うようにしてください。

ハントを使用してエンドツーエンドのプロアクティブな脅威ハンティングを実施する

ハントを次のレベルに進めます。 整理された状態を維持し、新しいハント、アクティブなハント、クローズしたハントを追跡します。 反応を待つ必要はありません。特定の MITRE ATT&CK 手法または独自の仮説に関する検出ギャップを事前に追跡します。 証拠を収集し、エンティティを調査し、結果に注釈を付け、チームとすべてを 1 つの画面で共有します。

詳細については、ハント (プレビュー) に関するページを参照してください。

インシデント タスク アクティビティの監査と追跡

SecurityIncident テーブルで新たに利用可能になった情報により、閉じられたインシデントでも開いているタスクの履歴と状態を確認できるようになりました。 この情報を利用して、SOC が効率的かつ適切に機能していることを確認できます。

詳細については、インシデント タスクの監査と追跡に関するページを参照してください。

2023 年 4 月

ワークスペース マネージャーを使用して複数のワークスペースを管理する (プレビュー)

ワークスペース マネージャーを使用して Microsoft Sentinel を大規模に一元管理します。 ワークスペース間や Azure AD テナント間で作業している場合、ワークスペース マネージャーを使用すると複雑さが軽減されます。

詳細については、Microsoft Sentinel ワークスペース マネージャーに関する記事を参照してください。

2023 年 3 月

SAP® BTP 向け Microsoft Sentinel ソリューション (プレビュー)

SAP BTP 向け Microsoft Sentinel ソリューションは、BTP インフラストラクチャおよび BTP ベースのアプリから監査ログやアクティビティ ログを収集し、脅威、不審なアクティビティ、不正行為などを検出することにより、SAP Business Technology Platform (BTP) システムの監視と保護を行います。

このソリューションには、SAP BTP コネクタ、ID 管理およびローコード アプリケーション開発シナリオ用の組み込み分析ルール、サブアカウントのダッシュボード概要と ID 管理イベントのグリッドを提供する BTP アクティビティ ブックが含まれています。

ソリューションの詳細情報。

複数のワークスペースで SAP® アプリケーション向け Microsoft Sentinel ソリューションを使用する (プレビュー)

さまざまなシナリオにおいて、複数のワークスペースで SAP® アプリケーション向け Microsoft Sentinel ソリューションを使用できるようになりました。 この機能を使用すると、マネージド セキュリティ サービス プロバイダー (MSSP)、グローバルまたはフェデレーション SOC、データ所在地要件、組織階層または IT 設計、単一のワークスペースでの不十分なロールベースのアクセス制御 (RBAC) に対して柔軟性を向上できます。 一般的なユース ケースの 1 つは、組織内のセキュリティ オペレーション センター (SOC) と SAP チーム間のコラボレーションの必要性です。 このユース ケースに対処するシナリオについて確認してください。

静的 SAP セキュリティ パラメーター (プレビュー) 構成の監視

SAP システムをセキュリティで保護するために、SAP では、変更を監視する必要があるセキュリティ関連のパラメーターを特定しました。 "SAP - (プレビュー) 機密静的パラメーターが変更されました" 分析ルールを使用すると、SAP® アプリケーション用の Microsoft Sentinel ソリューションでは、SAP システム内の 52 を超えるセキュリティ関連パラメーターを追跡し、これらのパラメーターがポリシーに従わずに変更されるとアラートをトリガーします。

SAP 向け Microsoft Sentinel ソリューション® アプリケーションで SAP セキュリティ パラメーターを正常に監視するには、定期的にソリューションで SAP PAHI テーブルを正常に監視する必要があります。 ソリューションで PAHI テーブルを正常に監視できることを確認してください。

Google Cloud Platform から Microsoft Sentinel へのログ データのストリーミング (プレビュー)

コードレス コネクタ プラットフォーム (CCP) に基づいて、GCP Pub/Sub 監査ログ コネクタを使用して、Google Cloud Platform (GCP) から Microsoft Sentinel に監査ログ データをストリーミングできるようになりました。 新しいコネクタでは、GCP Pub/Sub 機能を使用して GCP 環境からログが取り込まれます。

Microsoft Defender 脅威インテリジェンス データ コネクタ (プレビュー)

、Microsoft Defender 脅威インテリジェンス データ コネクタを使用して、Microsoft Defender 脅威インテリジェンス (MDTI) によって生成された忠実度の高いセキュリティ侵害のインジケーター (IOC) を Microsoft Sentinel ワークスペースに取り込めるようになりました。

Microsoft Defender 脅威インテリジェンス ソリューション (プレビュー)

プレイブックのコレクションを、新しい Microsoft Defender 脅威インテリジェンス ソリューションで使用できます。 プレイブックを利用して、Microsoft Sentinel インシデントに関連付けられているエンティティ (ドメイン、ホスト、IP) をエンリッチします。 このエンリッチメントでは、包括的な脅威インテリジェンス (TI) データを使用して、リスク スコアリング、有用なタグ、アナリストの分析情報、公開された TI 記事へのリンクを追加します。 TI データを包括的で魅力的にさせるものは何でしょうか。 従来の TI データセット (DNS、逆引き DNS、WHOIS、SSL 証明書、サブドメイン) と共に、MDTI エンリッチメントは、トラッカー、Web コンポーネント、ホスト ペア、Cookie などの高度な TI データセットと連携します。

このソリューションを有効にすると、セキュリティ チームが次の目標を達成するために役立ちます。

  • 調査の高速化
  • 可視性の向上
  • 脅威へのより効率的な対応
  • 既存のセキュリティ インシデント対応の効果の最大化

Microsoft Secure からのお知らせの詳細については、技術コミュニティのブログを参照してください。

SAP データ コネクタ エージェントの自動更新

SAP データ コネクタ エージェントの自動更新を有効にできるようになりました。 すべての既存コンテナーや特定のコンテナーに対して、自動更新の適用を選択できます。

2023 年 2 月

AWS S3 コネクタの新しい CloudWatch データ型

Microsoft Sentinel AWS S3 コネクタでは、サポートしているCloudTrail、VPC Flow、Guard Duty のログに加えて、CloudWatch のログがサポートされるようになりました。 AWS CloudWatch からのログは、さまざまな AWS ソースからの運用情報を提供します。これにより、AWS フットプリントを持つ Microsoft Sentinel のお客様は、AWS システムとアプリケーションをより深く理解して運用できます。

CloudWatch データ型では、AWS S3 コネクタ内の他のデータ型と同じデータ変換機能を実行することができます。 CloudWatch のデータを変換する方法について確認してください。

分析ルールの正常性を監査および監視する (プレビュー)

Microsoft Sentinel の正常性監視機能は、自動化ルール、プレイブック、データ コネクタに加えて、分析ルールで使用できるようになりました。 また、初めて使用できるようになった、現在は分析ルールのみが対象なのが Microsoft Sentinel の監査機能です。 監査機能は、Sentinel リソース (分析ルール) に加えられた変更に関する情報を収集して、承認されていないアクションやサービスの改ざんを検出できるようにします。

Microsoft Sentinel での監査と稼働状況の監視の詳細を確認してください。

Microsoft 365 Defender データ コネクタの一般提供開始

Microsoft 365 Defender のインシデント、アラート、生イベント データは、このコネクタを使用して Microsoft Sentinel に取り込むことができます。 また、Microsoft 365 Defender と Microsoft Sentinel の間でインシデントを双方向に同期することもできます。 この統合により、Microsoft Sentinel ですべてのインシデントを管理しながら、Microsoft 365 Defender の特殊なツールと機能を利用して、Microsoft 365 で発生したインシデントを調査できます。

分析ルールの高度なスケジュール設定 (プレビュー)

分析ルールの実行時間をより柔軟にスケジュールし、潜在的な競合を回避するために、Microsoft Sentinel では、新しく作成された分析ルールが初めて実行されるタイミングを決定できるようになりました。 既定の動作ではこれまで同様、作成時にすぐに実行されます。

高度なスケジュール設定の詳細について学習します。

お知らせ

MDI アラート コネクタを切断および接続する場合 - UniqueExternalId フィールドが設定されていない (AlertName フィールドを使用)

Microsoft Defender for Identity アラートが Government Community Cloud (GCC) をサポートするようになりました。 このサポートを有効にするために、アラートを Microsoft Sentinel に送信する方法が変更されています。 

MDI アラート コネクタを接続および切断しているお客様の場合、UniqueExternalId フィールドは設定されなくなりました。 この UniqueExternalId はアラートを表し、以前は ExternalProperties フィールドに配置されていました。 ID は、アラート名を含む AlertName フィールドから取得できるようになりました。 

アラート名と一意の外部 ID の間の完全なマッピングを確認します。

MDI で実行されるインフラストラクチャの変更のため、Microsoft Defender for Identity アラートでは、アラート ExternalLinks プロパティ内で MDA ポリシーを参照しなくなります。 アラートには、ExtendedLinks の下に、Defender for Cloud Apps で始まるラベルの付いた MDA リンクが含まれなくなります。 この変更は 2023 年 4 月 30 日に有効になります。 この変更の詳細を確認してください。 

WindowsEvent テーブルの機能強化

WindowsEvent スキーマが拡張され、Keywords、Version、Opcode、Correlation、SystemProcessId、SystemThreadId、EventRecordId などの新しいフィールドが追加されました。

これらの追加により、より包括的な分析が可能になり、イベントからより詳細な情報を抽出および解析することができます。

新しいフィールドを取り込むことに関心がない場合は、AMA DCR で取り込み時変換を使用して、イベントを取り込みつつフィールドをフィルター処理および削除してください。 イベントを取り込むには、DCR に以下を追加します。

"transformKql": "source | project-away TimeCreated, SystemThreadId, EventRecordId, SystemProcessId, Correlation, Keywords, Opcode, SystemUserId, Version"

取り込み時変換について詳細を確認してください。

すぐに使えるコンテンツの一元化の変更

Microsoft Sentinel ギャラリー ページに新しいバナーが表示されます。 この情報バナーは、すぐに使える (OOTB) コンテンツに関する今後の変更点を説明するために、すべてのテナントを対象にロールアウトされています。 つまり、スタンドアロン コンテンツとパッケージ ソリューションのどちらを探しているかを問わず、コンテンツ ハブが中心的なソースになります。 ブック、ハンティング、オートメーション、分析、データ コネクタ ギャラリーのテンプレート セクションにバナーが表示されます。 ブック ギャラリーのバナーの例を次に示します。

**ブック** ギャラリーの情報バナーの例を示すスクリーンショット。

この一元化の変更の一環として、データ コネクタ ページの [次の手順] タブは非推奨になりました。

今後の変更による影響について詳しくは、「Microsoft Sentinel のすぐに使えるコンテンツの一元化の変更」を参照してください。

分析ルールでのアラート グループ化の新しい動作

2023 年 2 月 6 日から 2 月末にかけて、Microsoft Sentinel では、特定のイベントとアラートのグループ化設定を使用して分析ルールからインシデントが作成される方法と、そのようなインシデントを自動化ルールによって更新する方法の変更がロールアウトされます。 この変更は、より完全な情報を含むインシデントを生成し、インシデントの作成と更新によってトリガーされる自動化を簡略化することを目的としています。

影響を受ける分析ルールは、次の 2 つの設定の両方を持つルールです。

  • [イベントのグループ化] が、[各イベントに対するアラートをトリガーする] に設定されている ("行ごとのアラート" または "結果ごとのアラート" と呼ばれることもあります)。
  • [アラートのグループ化] が、考えられる 3 つの構成のいずれかで有効になっている。

問題

これら 2 つの設定を持つルールでは、クエリによって返されるイベント (結果) ごとに一意のアラートが生成されます。 これらのアラートはすべて 1 つのインシデントにグループ化されます (または、アラートのグループ化構成の選択によっては、少数のインシデント)。

問題は、最初のアラートが生成されるとすぐにインシデントが作成されるため、その時点でインシデントには最初のアラートのみが含まれているという点です。 残りのアラートは、生成されるたびに、インシデントに 1 つずつ追加されていきます。 そのため、最終的に "分析ルールの 1 回の実行" が、次のような結果にります。

  • 1 つのインシデント作成イベント "および"
  • 最大 149 件のインシデント更新イベント

このような状況では、自動化ルールで定義されている条件を評価したり、プレイブックにインシデント スキーマを設定したりする際に、予期しない動作が発生します。

  • 自動化ルールによるインシデントの条件の不適切な評価:

    このインシデントの自動化ルールは、アラートが 1 つだけ含まれている場合でも、その作成時に直ちに実行されます。 そのため、自動化ルールでは、(この分析ルールの同じ実行によって) 他のアラートがほぼ同時に作成され、自動化ルールの実行中に追加され続けるにもかかわらず、インシデントの状態は最初のアラートを含んだ状態で評価されます。 そのため、最終的には、自動化ルールによるインシデントの評価が不完全で、正しくない可能性が高い状況になります。

    インシデントの "更新" 時に実行する自動化ルールが定義されている場合は、後続の各アラートがインシデントに追加されるたびに繰り返し実行されます (これらのアラートがすべて分析ルールの同じ実行によって生成された場合でも)。 そのため、アラートが追加され、自動化ルールが実行されるたびに、インシデントの状態が誤って評価される可能性があります。

    自動化ルールの条件では、後でインシデントの一部になったが、インシデントの最初のアラート/作成には含まれていなかったエンティティが無視される場合があります。

    このような場合、インシデントの状態の誤った評価により、自動化ルールが、実行すべきでない場合に実行されたり、必要なときに実行されなかったりする可能性があります。 その結果、インシデントに対して間違ったアクションが実行されたり、適切なアクションが実行されなかったりすることになります。

  • 後続のアラートの情報がインシデントに対して実行されるプレイブックで利用できない:

    自動化ルールがプレイブックを呼び出すと、インシデントの詳細情報がプレイブックに渡されます。 上記の動作により、プレイブックはインシデントの最初のアラートの詳細 (エンティティ、カスタムの詳細など) のみを受け取り、後続のアラートからの詳細は受け取らない可能性があります。 これは、プレイブックのアクションがインシデント内のすべての情報にアクセスできるわけではないことを意味します。

解決策

今後は、最初のアラートが生成されるとすぐにインシデントを作成する代わりに、Microsoft Sentinel は分析ルールの 1 回の実行ですべてのアラートが生成されるまで待機し、その後にインシデントを作成し、すべてのアラートを一度に追加します。 そのため、インシデント作成イベントと大量のインシデント更新イベントの代わりに、インシデント作成イベントのみが発生します。

これで、インシデントの作成時に実行される自動化ルールでは、すべてのアラート (およびエンティティとカスタムの詳細) とその最新のプロパティを含む完全なインシデントを評価できます。また、実行されるすべてのプレイブックでもインシデントの完全な詳細を得られます。

次の表で、インシデントの作成と自動化の動作の変更について説明します。

複数のアラートでインシデントが作成または更新されたとき 変更前 変更後
自動化ルールの条件が評価される対象... 分析ルールの現在の実行によって生成された最初のアラート。 分析ルールの現在の実行により発生するすべてのアラートとエンティティ。
プレイブックの入力に含まれる内容... - インシデントの最初のアラートのみを含むアラートの一覧。
- インシデントの最初のアラートからのエンティティのみを含むエンティティの一覧。		 - このルールの実行によってトリガーされ、このインシデントにグループ化されたすべてのアラートを含むアラートの一覧。
- このルールの実行によってトリガーされ、このインシデントにグループ化されたすべてのアラートからのエンティティを含むエンティティの一覧。
Log Analytics の SecurityIncident テーブルの表示内容... - 1 つのアラートを含む "インシデント作成" に対して 1 つの行。
- "アラート追加" の複数のイベント。		 このルールの実行によってトリガーされたすべてのアラートが追加され、このインシデントにグループ化された後に "インシデント作成" に対して 1 つの行。

Microsoft 365 Defender は Azure Active Directory Identity Protection (AADIP) を統合するようになりました

2022 年 10 月 24 日から、Microsoft 365 Defender が、Azure Active Directory Identity Protection (AADIP) のアラートとインシデントを統合します。 お客様は、次の 3 つのレベルの統合を選択できます。

  • [Show high-impact alerts only] (影響の大きいアラートのみを表示する) (既定) には、注意が必要になる可能性がある既知の悪意があるか、非常に疑わしいアクティビティに関するアラートのみが含まれます。 これらのアラートは、Microsoft のセキュリティ研究者によって選出されたもので、主に重大度が中および高です。
  • [すべてのアラートを表示] には、不要でも、悪意があるわけでもないアクティビティを含め、すべての AADIP アラートが含まれます。
  • [Turn off all alerts] (すべてのアラートをオフにする) では、AADIP アラートが Microsoft 365 Defender インシデントに表示されなくなります。

Microsoft 365 Defender 統合が有効になっていて AADIP サブスクライバーでもある Microsoft Sentinel のお客様は、Microsoft Sentinel インシデント キューで AADIP のアラートとインシデントを自動的に受信します。 構成によっては、これにより次のような影響を受ける場合があります。

  • Microsoft Sentinel で AADIP コネクタを既に有効にしていて、インシデントの作成を有効にした場合は、重複するインシデントを受信する場合があります。 これを回避するには、いくつかの選択肢があり、以下に優先順位の高い順で示します。

    優先順位 Microsoft 365 Defender でのアクション Microsoft Sentinel でのアクション
    1 [Show high-impact alerts only] (影響の大きいアラートのみを表示する) の既定の AADIP 統合を維持します。 AADIP アラートからインシデントを作成する Microsoft セキュリティ分析ルールをすべて無効にします。
    2 [すべてのアラートを表示] AADIP 統合を選択します。 不要なアラートのインシデントを自動的に閉じる自動化ルールを作成します。

    AADIP アラートからインシデントを作成する Microsoft セキュリティ分析ルールをすべて無効にします。
    3 AADIP アラートには Microsoft 365 Defender を使用しないでください。
    AADIP 統合に対して [Turn off all alerts] (すべてのアラートをオフにする) オプションを選択します。    		 AADIP アラートからインシデントを作成する Microsoft セキュリティ分析ルールを有効なままにします。

    Microsoft 365 Defender で所定のアクションを実行する方法については、Microsoft 365 Defender のドキュメントを参照してください。

  • AADIP コネクタが有効になっていない場合は、有効にする必要があります。 コネクタ ページでインシデントの作成を有効にしないでください。 コネクタを有効にしないと、何もデータが含まれない AADIP インシデントを受信する場合があります。

  • 今から Microsoft 365 Defender コネクタを初めて有効にする場合、AADIP 接続はバックグラウンドで自動的に行われています。 他に何も実行する必要はありません。

Azure AD Identity Protection コネクタから削除されたアカウント エンリッチメント フィールド

2022 年 9 月 30 日の時点で、Azure Active Directory Identity Protection コネクタから送られるアラートには、以下のフィールドが含まれなくなりました。

  • CompromisedEntity
  • ExtendedProperties["ユーザー アカウント"]
  • ExtendedProperties["ユーザー名”]

この変更の影響を受ける Microsoft Sentinel の組み込みクエリやその他の操作を、他の方法 (IdentityInfo テーブルを使用) でこれらの値を検索できるようにするため、現在取り組んでいます。

一方、これらのフィールドを直接参照するカスタム クエリやルールを作成した場合、この情報を取得する別の方法が必要になります。 次の 2 段階のプロセスを使用して、クエリがこれらの値を IdentityInfo テーブルで検索するようにしてください。

  1. まだの場合は、UEBA ソリューションを有効にしてIdentityInfo テーブルを Azure AD ログと同期させます。 このドキュメントの手順に従ってください。
    (UEBA を一般的に使用するつもりがない場合は、エンティティの動作分析を有効にするデータ ソースの選択に関する最後の説明は無視して構いません)。

  2. 以下のクエリを既存のクエリやルールに組み込んで、SecurityAlert テーブルと IdentityInfo テーブルを結合して、このデータを検索することができます。

    SecurityAlert
| where TimeGenerated > ago(7d)
| where ProductName == "Azure Active Directory Identity Protection"
| mv-expand Entity = todynamic(Entities)
| where Entity.Type == "account"
| extend AadTenantId = tostring(Entity.AadTenantId)
| extend AadUserId = tostring(Entity.AadUserId)
| join kind=inner (
    IdentityInfo
    | where TimeGenerated > ago(14d)
    | distinct AccountTenantId, AccountObjectId, AccountUPN, AccountDisplayName
    | extend UserAccount = AccountUPN
    | extend UserName = AccountDisplayName
    | where isnotempty(AccountDisplayName) and isnotempty(UserAccount)
    | project AccountTenantId, AccountObjectId, UserAccount, UserName
    )
    on
    $left.AadTenantId == $right.AccountTenantId,
    $left.AadUserId == $right.AccountObjectId
| extend CompromisedEntity = iff(CompromisedEntity == "N/A" or isempty(CompromisedEntity), UserAccount, CompromisedEntity)
| project-away AadTenantId, AadUserId, AccountTenantId, AccountObjectId

UEBA UserPeerAnalytics テーブルから削除されたエンリッチメント フィールドを置き換えるデータを調べる方法については、「UEBA UserPeerAnalytics テーブルから名前フィールドが削除」のサンプル クエリを参照してください。

UEBA UserPeerAnalytics テーブルから名前フィールドが削除

2022 年 9 月 30 日から、UEBA エンジンはユーザー ID の自動検索と名前への解決を行わなくなります。 この変更により、UserPeerAnalytics テーブルから 4 つの名前フィールドが削除されました。

  • UserName
  • UserPrincipalName
  • PeerUserName
  • PeerUserPrincipalName

対応する ID フィールドはテーブルの一部であり、組み込みのクエリやその他の操作では、(IdentityInfo テーブルを使用して) 他の方法で適切な名前参照が実行されるため、ほぼすべての状況でこの変更の影響を受けることはありません。

これに対する唯一の例外は、これらの名前フィールドのいずれかを直接参照するカスタム クエリまたはルールを作成した場合です。 このシナリオでは、次の参照クエリを独自に組み込むことができるため、これらの名前フィールドにある値にアクセスできます。

次のクエリは、 ユーザー と ピアの識別子フィールドを解決します。

UserPeerAnalytics 
| where TimeGenerated > ago(24h) 
// join to resolve user identifier fields 
| join kind=inner ( 
    IdentityInfo  
    | where TimeGenerated > ago(14d) 
    | distinct AccountTenantId, AccountObjectId, AccountUPN, AccountDisplayName 
    | extend UserPrincipalNameIdentityInfo = AccountUPN 
    | extend UserNameIdentityInfo = AccountDisplayName 
    | project AccountTenantId, AccountObjectId, UserPrincipalNameIdentityInfo, UserNameIdentityInfo 
) on $left.AADTenantId == $right.AccountTenantId, $left.UserId == $right.AccountObjectId 
// join to resolve peer identifier fields 
| join kind=inner ( 
    IdentityInfo  
    | where TimeGenerated > ago(14d) 
    | distinct AccountTenantId, AccountObjectId, AccountUPN, AccountDisplayName 
    | extend PeerUserPrincipalNameIdentityInfo = AccountUPN 
    | extend PeerUserNameIdentityInfo = AccountDisplayName 
    | project AccountTenantId, AccountObjectId, PeerUserPrincipalNameIdentityInfo, PeerUserNameIdentityInfo 
) on $left.AADTenantId == $right.AccountTenantId, $left.PeerUserId == $right.AccountObjectId

元のクエリでユーザー名またはピア名 (ID だけでなく) が参照されている場合は、このクエリ全体を元のクエリのテーブル名 ("UserPeerAnalytics") に置き換えます。

次のステップ

Azure Sentinel をオンボードする

アラートの視覚化