検出ルールの作成

適用対象: Microsoft Defender XDR, Microsoft Sentinel in the Microsoft Defender portal

重要

この記事の一部の情報は、市販される前に大幅に変更される可能性があるプレリリース製品に関するものです。 Microsoft は、ここで提供されるいかなる情報に関して、明示または黙示を問わず、いかなる保証も行いません。

カスタム検出ルールは、高度なハンティングクエリを使用して設計および調整するルールです。これらのルールを使用すると、侵害の疑いのあるアクティビティやエンドポイントの構成ミスなど、さまざまなイベントとシステムの状態を事前に監視できます。一定の間隔で実行し、アラートを生成しながら一致するたびに応答アクションを実行するように設定できます。

カスタム検出を管理するのに必要なアクセス許可

重要

Microsoft では、アクセス許可が可能な限りで少ないロールを使用することをお勧めします。これにより、組織のセキュリティが向上します。グローバル管理者は高い特権を持つロールであり、既存のロールを使用できない場合の緊急時に限定する必要があります。

カスタム検出を管理するには、これらの検出の対象となるデータを管理できるロールが必要です。たとえば、複数のデータソース (Microsoft Defender XDRとMicrosoft Sentinel、または複数の Defender ワークロード) でカスタム検出を管理するには、該当するすべてのDefender XDRとSentinelロールが必要です。詳細については、次のセクションを参照してください。

Microsoft Defender XDR

Microsoft Defender XDR データのカスタム検出を管理するには、次のいずれかのロールを割り当てる必要があります。

セキュリティ設定 (管理) - このMicrosoft Defender XDRアクセス許可を持つユーザーは、Microsoft Defender ポータルでセキュリティ設定を管理できます。
セキュリティ管理者 - このMicrosoft Entraロールを持つユーザーは、Microsoft Defender ポータルやその他のポータルやサービスでセキュリティ設定を管理できます。
セキュリティオペレーター - このMicrosoft Entraロールを持つユーザーは、アラートを管理し、Microsoft Defender ポータルのすべての情報を含む、セキュリティ関連の機能へのグローバルな読み取り専用アクセス権を持つことができます。このロールは、Microsoft Defender for Endpointでロールベースのアクセス制御 (RBAC) がオフになっている場合にのみ、カスタム検出を管理するのに十分です。 RBAC が構成されている場合は、Defender for Endpoint の [セキュリティ設定の管理] アクセス許可も必要です。

適切なアクセス許可がある場合は、特定のDefender XDR ソリューションのデータに適用されるカスタム検出を管理できます。たとえば、Office 365のMicrosoft Defenderに対する管理アクセス許可しかない場合は、Email* テーブルを使用してカスタム検出を作成できますが、テーブルIdentity*作成することはできません。

同様に、IdentityLogonEvents テーブルにはMicrosoft Defender for Cloud Appsと Defender for Identity の両方からの認証アクティビティ情報が保持されるため、両方のサービスの管理アクセス許可を持って、そのテーブルに対してクエリを実行するカスタム検出を管理する必要があります。

注:

カスタム検出を管理するには、RBAC が有効になっている場合、セキュリティオペレーターはMicrosoft Defender for Endpointの [セキュリティ設定の管理] アクセス許可を持っている必要があります。

Microsoft Sentinel

Microsoft Sentinel データのカスタム検出を管理するには、Microsoft Sentinel共同作成者ロールを割り当てる必要があります。このAzureロールを持つユーザーは、アラートや検出など、SIEM ワークスペースデータMicrosoft Sentinel管理できます。このロールは、特定のプライマリワークスペース、Azure リソースグループ、またはサブスクリプション全体に割り当てることができます。

必要なアクセス許可の管理

必要なアクセス許可を管理するには、グローバル管理者は次のことができます。

ロール>セキュリティ管理者の下のMicrosoft 365 管理センターでセキュリティ管理者またはセキュリティ オペレーター ロールを割り当てます。
[設定>Permissions>Roles] で、Microsoft Defender XDRのMicrosoft Defender for Endpointの RBAC 設定を確認します。対応するロールを選択して、 セキュリティ設定の管理 アクセス許可を割り当てます。

注:

また、ユーザーが作成または編集するカスタム検出ルールのデバイススコープ内のデバイスに対する適切なアクセス許可を、続行する前に持っている必要もあります。ユーザーがすべてのデバイスに対するアクセス許可を持っていない場合、すべてのデバイスで実行するようにスコープが設定されたカスタム検出ルールを編集することはできません。

カスタム検出ルールを作成する

1. クエリを準備する

Microsoft Defender ポータルで、[高度な検索] に移動し、既存のクエリを選択するか、新しいクエリを作成します。新しいクエリを使用する場合は、クエリを実行してエラーを特定し、考えられる結果を理解します。

重要

サービスから返されるアラートの数が多くなりすぎないように、各ルールは実行されるたびに 150 個のアラートのみを生成できます。ルールを作成する前に、クエリを調整して、通常の毎日のアクティビティに対してアラートが生成されないようにします。

クエリ結果に必要な列

Defender XDR データを使用してカスタム検出ルールを作成するには、クエリから次の列が返される必要があります。

Timestamp または TimeGenerated - この列は、生成されたアラートのタイムスタンプを設定します。クエリはこの列を操作する必要はありません。また、生イベントに表示されるとおりにクエリを返す必要があります。
XDR テーブル、列、またはこれらのテーブル内のイベントを一意に識別する列の組み合わせに基づく検出の場合:
- Microsoft Defender for Endpointテーブルの場合、Timestamp、DeviceId、およびReportId列が同じイベントに表示される必要があります
- Alert* テーブルの場合、イベントに Timestamp が表示される必要があります
- Observation* テーブルの場合、 Timestampと ObservationId は同じイベントに表示される必要があります
- それ以外の場合は、 Timestamp と ReportId が同じイベントに表示される必要があります
影響を受ける資産の厳密な識別子を含む列。影響を受ける資産をウィザードで自動的にマップするには、影響を受ける資産の強力な識別子を含む次のいずれかの列をプロジェクトします。
- DeviceId
- DeviceName
- RemoteDeviceName
- RecipientEmailAddress
- SenderFromAddress (封筒送信者または Return-Path アドレス)
- SenderMailFromAddress (メールクライアントによって表示される送信者アドレス)
- SenderObjectId
- RecipientObjectId
- AccountObjectId
- AccountSid
- AccountUpn
- InitiatingProcessAccountSid
- InitiatingProcessAccountUpn
- InitiatingProcessAccountObjectId

注:

高度なハンティングスキーマに新しいテーブルが追加されると、より多くのエンティティのサポートが追加されます。

project演算子や summarize 演算子を使用して結果をカスタマイズまたは集計しないクエリなどの単純なクエリは、通常、これらの一般的な列を返します。

より複雑なクエリがこれらの列を返すようにするには、さまざまな方法があります。たとえば、DeviceIdなどの列の下でエンティティを集計してカウントする場合でも、一意のDeviceIdを含む最新のイベントから取得することで、TimestampとReportIdを返すことができます。

重要

Timestamp列を使用してカスタム検出をフィルター処理しないようにします。カスタム検出に使用されるデータは、検出頻度に基づいて事前にフィルター処理されます。

次のサンプルクエリでは、ウイルス対策検出を使用して一意のデバイス (DeviceId) の数をカウントし、この数を使用して 5 つを超える検出を持つデバイスのみを検索します。最新のTimestampと対応するReportIdを返すには、arg_max 関数で summarize 演算子を使用します。

DeviceEvents
| where ingestion_time() > ago(1d)
| where ActionType == "AntivirusDetection"
| summarize (Timestamp, ReportId)=arg_max(Timestamp, ReportId), count() by DeviceId
| where count_ > 5

ヒント

クエリのパフォーマンスを向上させるには、ルールの目的の実行頻度に一致する時間フィルターを設定します。最も頻度の低い実行は 24 時間ごとに実行されるため、過去 1 日のフィルター処理はすべての新しいデータを対象としています。

2. 新しいルールを作成し、アラートの詳細を指定する

クエリエディターで [ 検出ルールの作成 ] を選択し、次のアラートの詳細を指定します。

検出名 - 検出規則の名前。は一意である必要があります。
Frequency - クエリを実行してアクションを実行するための間隔。ルールの頻度に関するセクションで、その他のガイダンスを参照してください
アラートタイトル - ルールによってトリガーされたアラートと共に表示されるタイトル。は、プレーンテキストで一意である必要があります。文字列はセキュリティ上の目的でサニタイズされるため、HTML、Markdown、およびその他のコードは機能しません。タイトルに含まれる URL は、正しく表示するためにパーセントエンコード形式に従う必要があります。
重大度 - ルールによって識別されるコンポーネントまたはアクティビティの潜在的なリスク。
カテゴリ - ルールによって識別される脅威コンポーネントまたはアクティビティ。
MITRE ATT&CK 手法 - MITRE ATT&CK フレームワークに記載されているように、ルールによって識別される 1 つ以上の攻撃手法。このセクションは、マルウェア、ランサムウェア、不審なアクティビティ、不要なソフトウェアなど、特定のアラートカテゴリでは非表示になります。
脅威分析レポート - 生成されたアラートを既存の脅威分析レポートにリンクして、脅威分析の [ 関連インシデント ] タブに表示されるようにします。
説明 - ルールによって識別されるコンポーネントまたはアクティビティの詳細。文字列はセキュリティ上の目的でサニタイズされるため、HTML、Markdown、およびその他のコードは機能しません。説明に含まれる URL は、正しく表示するためにパーセントエンコード形式に従う必要があります。
推奨されるアクション - アラートに応答してレスポンダーが実行する可能性があるその他のアクション。

ルールの頻度

新しいルールを保存すると、過去 30 日間のデータの一致が実行されてチェックされます。その後、ルールは一定の間隔で再び実行され、選択した頻度に基づいてルックバック期間が適用されます。

24 時間ごと - 過去 30 日間のデータを確認し、24 時間ごとに実行します。
12 時間ごと - 過去 48 時間のデータを確認して、12 時間ごとに実行します。
3 時間ごと - 過去 12 時間のデータを確認し、3 時間ごとに実行します。
[1 時間ごと ] - 過去 4 時間のデータを確認して、1 時間ごとに実行します。
継続的 (NRT) - 継続的に実行され、ほぼリアルタイム (NRT) で収集および処理されるイベントからのデータを確認します。「継続的 (NRT) 頻度」を参照してください。
[カスタム ] - 選択した頻度に従って実行されます。このオプションは、ルールがMicrosoft Sentinelに取り込まれたデータのみに基づいている場合に使用できます。「Microsoft Sentinel データのカスタム頻度 (プレビュー)」を参照してください。

ヒント

クエリ内の時間フィルターをルックバック期間と一致させます。ルックバック期間外の結果は無視されます。

ルールを編集すると、設定した頻度に従ってスケジュールされた次回の実行時に変更が適用されます。ルールの頻度は、インジェスト時間ではなく、イベントタイムスタンプに基づいています。また、特定の実行で小さな遅延が発生する可能性もあります。それにより、構成された頻度が 100% 正確ではありません。

連続 (NRT) 周波数

カスタム検出を継続的 (NRT) 頻度で実行するように設定すると、脅威をより迅速に識別するorganizationの能力が向上します。継続的 (NRT) 頻度の使用は、リソースの使用状況への影響を最小限に抑えるので、organization内の修飾されたカスタム検出ルールについて考慮する必要があります。

[カスタム検出ルール] ページでは、連続 (NRT) 頻度に合ったカスタム検出ルールを 1 つのボタンで移行できます。[今すぐ移行]

[移行] を選択すると、KQL クエリに従って互換性のあるすべてのルールの一覧が表示 されるようになりました 。すべてのルールまたは選択したルールは、設定に従ってのみ移行できます。

[保存] を選択すると、選択したルールの頻度が継続的 (NRT) 頻度に更新されます。

継続的に実行できるクエリ

クエリは、次の場合に限り継続的に実行できます。

クエリは 1 つのテーブルのみを参照します。
クエリでは、 サポートされている KQL 機能の一覧から演算子を使用します。 ( matches regexの場合、正規表現は文字列リテラルとしてエンコードし、文字列引用符で囲む規則に従う必要があります。たとえば、正規表現 \A は KQL で "\\A"として表されます。余分な円記号は、もう一方の円記号が正規表現 \Aの一部であることを示します)。
クエリでは、結合、共用体、または externaldata 演算子は使用されません。
クエリにはコメント行/情報は含まれません。

継続的 (NRT) 頻度をサポートするテーブル

次の表では、ほぼリアルタイムの検出がサポートされています。

AlertEvidence
CloudAppEvents
DeviceEvents
DeviceFileCertificateInfo
DeviceFileEvents
DeviceImageLoadEvents
DeviceLogonEvents
DeviceNetworkEvents
DeviceNetworkInfo
DeviceInfo
DeviceProcessEvents
DeviceRegistryEvents
EmailAttachmentInfo
EmailEvents ( LatestDeliveryLocation 列と LatestDeliveryAction 列を除く)
EmailPostDeliveryEvents
EmailUrlInfo
IdentityDirectoryEvents
IdentityLogonEvents
IdentityQueryEvents
UrlClickEvents

注:

一般公開されている列のみが 継続的 (NRT) 頻度を サポートします。

Microsoft Sentinel データのカスタム頻度 (プレビュー)

Microsoft DefenderにオンボードされているMicrosoft Sentinel顧客は、ルールがMicrosoft Sentinelに取り込まれたデータのみに基づいている場合は、[カスタム頻度] を選択できます。

この頻度オプションを選択すると、[ クエリの実行] すべての入力 コンポーネントが表示されます。ルールの目的の頻度を入力し、ドロップダウンを使用して単位 (分、時間、または日) を選択します。サポートされる範囲は、5 分から 14 日までの任意の値です。頻度を選択すると、ルックバック期間は次のロジックで自動的に決定されます。

検出が 1 日に 1 回よりも頻繁に実行されるように設定されている場合、ルックバックは頻度の 4 倍です。たとえば、頻度が 20 分の場合、ルックバックは 80 分です。
検出が 1 日に 1 回実行されるように設定されている場合、ルックバックは 30 日です。たとえば、3 日ごとに実行するように設定した場合、ルックバックは 30 日です

重要

カスタム頻度を選択すると、Microsoft Sentinelからデータがフェッチされます。これは、以下のことを意味します。

Microsoft Sentinelで使用できるデータが必要です。
Defender XDRデータはスコープをサポートしません。Microsoft Sentinelはスコープをサポートしていないためです。

3. アラートエンリッチメントの詳細を定義する

アラートを強化するには、詳細を指定して定義することで、次のことができます。

動的アラートのタイトルと説明を作成する
アラート側パネルに表示するカスタムの詳細を追加する
エンティティをリンクする

動的アラートのタイトルと説明を作成する (プレビュー)

クエリの結果を使用して、アラートのタイトルと説明を動的に作成し、正確で示すことができます。この機能は、アラートとインシデントをトリアージするとき、およびアラートの本質をすばやく理解しようとするときに、SOC アナリストの効率を高めることができます。

アラートのタイトルまたは説明を動的に構成するには、クエリ結果で使用できる列のフリーテキスト名を使用し、二重中かっこで囲んで、アラートのタイトルまたは説明を [ アラートの詳細 ] セクションに統合します。

例: User {{AccountName}} unexpectedly signed in from {{Location}}

注:

各フィールドで参照できる列の数は 3 つに制限されています。

参照する正確な列名を決定するために、[ クエリと結果の探索] を選択すると、ルール作成ウィザードの上部に [高度なハンティングコンテキスト] ウィンドウが開き、クエリロジックとその結果を確認できます。

カスタムの詳細を追加する (プレビュー)

アラート側パネルに重要な詳細を表示することで、SOC アナリストの生産性をさらに向上させることができます。これらのイベントから作成されたアラートでイベントのデータを表示できます。この機能により、SOC アナリストはインシデントのイベントコンテンツを即座に可視化し、より迅速に結論をトリアージ、調査、描画できます。

[ カスタムの詳細 ] セクションで、表示する詳細に対応するキーと値のペアを追加します。

[ キー ] フィールドに、アラートのフィールド名として表示される選択した名前を入力します。
[ パラメーター ] フィールドで、ドロップダウンリストからアラートに表示するイベントパラメーターを選択します。この一覧には、KQL クエリによって出力される列名に対応する値が設定されます。

次のスクリーンショットは、アラート側パネルでカスタムの詳細がどのように表示されるかを示しています。

重要

カスタムの詳細には、次の制限があります。

各ルールは、カスタム詳細の最大 20 個のキー/値ペアに制限されています
すべてのカスタムの詳細とその値を 1 つのアラートに組み合わせたサイズ制限は 4 KB です。カスタム詳細配列がこの制限を超えた場合、カスタム詳細配列全体がアラートから削除されます。

エンティティをリンクする

主な影響、影響を受けたエンティティを見つけるクエリ結果の列を特定します。たとえば、クエリは送信者 (SenderFromAddress または SenderMailFromAddress) アドレスと受信者 (RecipientEmailAddress) アドレスを返す場合があります。これらの列の中で影響を受ける主なエンティティがある列を特定すると、サービスで関連するアラートの集計、インシデントの関連付け、応答アクションのターゲットができるようになります。

エンティティの種類 (メールボックス、ユーザー、またはデバイス) ごとに 1 つの列のみを選択できます。クエリによって返されない列は選択できません。

拡張されたエンティティマッピング (プレビュー)

さまざまな種類のエンティティをアラートにリンクできます。より多くのエンティティをリンクすると、関連付けエンジンによってアラートが同じインシデントにグループ化され、インシデントが相互に関連付けられます。 Microsoft Sentinel顧客の場合、これは、Microsoft Sentinelに取り込まれるサードパーティのデータソースから任意のエンティティをマップできることを意味します。

Microsoft Defender XDRデータの場合、エンティティが自動的に選択されます。データがMicrosoft Sentinelの場合は、エンティティを手動で選択する必要があります。

注:

エンティティは、アラートをインシデントにグループ化する方法に影響するため、高いインシデントの品質を確保するためにエンティティを慎重に確認してください。インシデントの関連付けとアラートのグループ化について詳しくは、こちらをご覧ください。

展開された エンティティマッピング セクションの下には、エンティティを選択できる 2 つのセクションがあります。

影響を受けた資産 – 選択したイベントに表示される影響を受けた資産を追加します。次の種類の資産を追加できます。
- 取引
- デバイス
- Mailbox
- クラウドアプリケーション
- Azure リソース
- Amazon Web Services リソース
- Google Cloud Platform リソース
関連する証拠 – 選択したイベントに表示される非アセンブリを追加します。サポートされているエンティティ型は次のとおりです。
- プロセス
- File
- レジストリ値
- IP
- OAuth アプリケーション
- DNS
- セキュリティグループ
- URL
- メールクラスター
- メールメッセージ

注:

現時点では、資産を影響を受けたエンティティとしてのみマップできます。

エンティティ型を選択した後、選択したクエリ結果に存在する識別子の種類を選択して、このエンティティを識別するために使用できるようにします。各エンティティの種類には、関連するドロップダウンメニューに示すように、サポートされている識別子の一覧があります。各識別子にカーソルを合わせると表示される説明を読み、理解を深めます。

識別子を選択したら、選択した識別子を含むクエリ結果から列を選択します。 [ クエリと結果の探索] を選択して、高度なハンティングコンテキストパネルを開きます。このオプションを使用すると、クエリと結果を調べて、選択した識別子に適した列を選択できます。

4. アクションを指定する

カスタム検出ルールでDefender XDRデータが使用されている場合、クエリから返されるデバイス、ファイル、ユーザー、または電子メールに対して自動的にアクションを実行できます。

デバイスでのアクション

これらのアクションは、クエリ結果の列 DeviceId にあるデバイスに適用されます。

デバイスの分離 - Microsoft Defender for Endpointを使用して完全なネットワーク分離を適用し、デバイスがアプリケーションまたはサービスに接続できないようにします。詳しくは、Microsoft Defender for Endpointマシンの分離に関するページをご覧ください。
調査パッケージの収集 - ZIP ファイル内のデバイス情報を収集します。 Microsoft Defender for Endpoint調査パッケージの詳細については、こちらをご覧ください。
ウイルス対策スキャンの実行 - デバイスで完全なMicrosoft Defenderウイルス対策スキャンを実行します。
調査の開始 - デバイスの自動調査を開始します。
アプリの実行を制限 する - Microsoft が発行した証明書で署名されたファイルのみを実行できるように、デバイスに制限を設定します。 Microsoft Defender for Endpointでのアプリの制限について詳しくは、こちらをご覧ください。

ファイルへのアクション

選択すると、[ 許可/ブロック] アクションをファイルに適用できます。ファイルのブロックは、ファイルの修復アクセス許可があり、クエリ結果で SHA1 などのファイル ID が識別されている場合にのみ許可されます。ファイルがブロックされると、すべてのデバイス内の同じファイルの他のインスタンスもブロックされます。ブロックが適用されるデバイスグループは制御できますが、特定のデバイスには適用されません。
選択すると、クエリ結果のSHA1、InitiatingProcessSHA1、SHA256、またはInitiatingProcessSHA256列内のファイルに対して [ファイルの検疫] アクションを適用できます。このアクションでは、ファイルが現在ある場所から削除され、コピーが検疫に入ります。

ユーザーへのアクション

選択されると、ユーザーを侵害済みにする アクションをクエリ結果の AccountObjectId、InitiatingProcessAccountObjectId、または RecipientObjectId 列にあるユーザーに適用することができます。このアクションにより、ユーザーのリスクレベルがMicrosoft Entra IDで "高" に設定され、対応する ID 保護ポリシーがトリガーされます。
[ ユーザーを無効にする] を選択 すると、ユーザーが一時的にログインできなくなります。
[ パスワードのリセットを強制 する] を選択して、次のサインインセッションでパスワードを変更するようにユーザーに求めます。
Disable userとForce password resetの両方のオプションには、ユーザー SID が必要です。これは、AccountSid、InitiatingProcessAccountSid、RequestAccountSid、およびOnPremSidの列にあります。

ユーザーアクションの詳細については、「Microsoft Defender for Identityの修復アクション」を参照してください。

メールに対するアクション

カスタム検出によってメールメッセージが生成される場合は、[ メールボックスフォルダーに移動 ] を選択して、選択したフォルダー ( 迷惑メール、 受信トレイ、または 削除済みアイテム のフォルダー) にメールを移動できます。具体的には、[ 受信トレイ ] オプションを選択すると、検疫されたアイテム (たとえば、誤検知の場合) から電子メールの結果を移動できます。
または、[ メールの削除 ] を選択し、メールを削除済みアイテム (論理的な削除) に移動するか、選択したメールを完全に削除 (ハード削除) するかを選択できます。

電子メールメッセージにアクションを適用するには、クエリの出力結果に NetworkMessageId 列と RecipientEmailAddress 列が存在する必要があります。

5. ルールの範囲を設定する

ルールがカバーするデバイスを指定するスコープを設定します。この範囲で、デバイスをチェックするルールが影響されますが、メールボックスのみをチェックするルールやユーザーアカウントまたは ID のみをチェックするルールには影響はありません。

範囲を設定する場合は、次の項目を選択できます。

すべてのデバイス
特定のデバイスグループ

ルールは、スコープ内のデバイスからのみデータを照会します。これらのデバイスでのみアクションが実行されます。

注:

ユーザーは、ルールのスコープに含まれるデバイスに対応するアクセス許可を持っている場合にのみ、カスタム検出ルールを作成または編集できます。たとえば、管理者は、すべてのデバイスグループに対するアクセス許可がある場合にのみ、すべてのデバイスグループを対象とするルールを作成または編集できます。

6. ルールを確認して有効にする

ルールを確認した後、[作成] を選択して保存します。カスタム検出ルールが直ちに実行されます。一致をチェックし、アラートを生成し、応答アクションを実行するように構成された頻度に基づいて、もう一度実行されます。

重要

効率と有効性を確認するために、カスタム検出を定期的に確認します。クエリを最適化する方法のガイダンスについては、「 高度なハンティングクエリのベストプラクティス」を参照してください。真のアラートをトリガーする検出を作成していることを確認するには、「既存のカスタム検出ルールを管理する」の手順に従って、既存の カスタム検出を確認する時間がかかります。

カスタム検出の広さまたは特異性を制御します。カスタム検出によって生成された誤ったアラートは、ルールの特定のパラメーターを変更する必要があることを示している可能性があります。

カスタム検出で重複アラートを処理する方法

カスタム検出ルールを作成して確認する際の重要な考慮事項は、アラートのノイズと疲労です。カスタム検出は、イベントをグループ化し、1 つのアラートに重複除去します。同じエンティティ、カスタムの詳細、動的な詳細を含むイベントでカスタム検出が 2 回発生した場合、これらのイベントの両方に対して 1 つのアラートのみが作成されます。検出によってイベントが同一であることが認識された場合、作成されたアラートのイベントの 1 つだけがログに記録され、重複が処理されます。これは、ルックバック期間が頻度よりも長い場合に発生する可能性があります。イベントが異なる場合、カスタム検出では両方のイベントがアラートに記録されます。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-12-02