カスタム検出ルールは、侵害の疑いのあるアクティビティや正しく構成されていないエンドポイントなど、さまざまなイベントやシステム状態を事前に監視するために設計および調整する 高度なハンティング クエリです。 一定の間隔で実行し、アラートを生成しながら一致するたびに応答アクションを実行するように設定できます。
カスタム検出を管理するのに必要なアクセス許可
カスタム検出を管理するには、これらの検出対象のデータに対するアクセス許可を持つロールが必要です。 たとえば、複数のデータ ソース (Microsoft DefenderとMicrosoft Sentinel、または複数のDefender ワークロード) でカスタム検出を管理するには、適用可能なすべてのDefenderロールと Sentinel ロールが必要です。 詳細については、次のセクションを参照してください。
Microsoft Defender XDR
Microsoft Defender データのカスタム検出を管理するには、次のいずれかのロールを割り当てる必要があります。
セキュリティ設定 (管理) - このMicrosoft Defenderアクセス許可を持つユーザーは、Microsoft Defender ポータルでセキュリティ設定を管理できます。
セキュリティ管理者 - このMicrosoft Entraロールを持つユーザーは、Microsoft Defender ポータルやその他のポータルやサービスでセキュリティ設定を管理できます。
セキュリティ オペレーター - このMicrosoft Entraロールを持つユーザーは、アラートを管理し、Microsoft Defender ポータルのすべての情報を含む、セキュリティ関連の機能へのグローバルな読み取り専用アクセス権を持つことができます。 このロールは、Microsoft Defender for Endpointでロールベースのアクセス制御 (RBAC) がオフになっている場合にのみ、カスタム検出を管理するのに十分です。 RBAC が構成されている場合は、Defender for Endpoint の [セキュリティ設定の管理] アクセス許可も必要です。
特定のDefender ソリューションのデータに適用されるカスタム検出は、適切なアクセス許可を持っている場合に管理できます。 たとえば、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 管理センターのロール>セキュリティ管理者で、セキュリティ管理者ロールまたはセキュリティ オペレーターロールを割り当てます。
- Microsoft Defender XDR の 設定>アクセス許可>ロール で、Microsoft Defender for Endpoint の RBAC 設定を確認します。 対応するロールを選択して、 セキュリティ設定の管理 アクセス許可を割り当てます。
重要
アクセス許可が最も少ないロールを使用して、organizationのセキュリティを強化します。 グローバル管理者は、高い特権を持つロールです。 既存のロールを使用できない場合は、その使用を緊急シナリオに制限します。
注:
ユーザーは、ユーザーが作成または編集しているカスタム検出ルールの デバイス スコープ 内のデバイスに対する適切なアクセス許可も必要です。 ユーザーがすべてのデバイスに対するアクセス許可を持っていない場合、すべてのデバイスで実行するようにスコープが設定されたカスタム検出ルールを編集することはできません。
カスタム検出ルールを作成する
次のいずれかのエントリ ポイントからカスタム検出ルールを作成できます。
- [高度なハンティング ] から [ 高度なハンティング] に移動し、クエリを準備して実行し、[ 検出ルールの作成] を選択します。 この方法では、ルールを作成する前にクエリ結果を検証できます。
- [カスタム検出] の一覧 から [ カスタム検出ルール ] に移動し、[ + 検出ルールの作成] を選択します。 この方法では、ルール ウィザードが直接開き、クエリを記述または貼り付け、すべてのルール設定を 1 か所で構成できます。
使用するエントリ ポイントに関係なく、次の手順に従ってルールを構成します。
1. クエリを準備する
Microsoft Defender ポータルで、[高度な検索] に移動し、既存のクエリを選択するか、新しいクエリを作成します。 新しいクエリを使用する場合は、クエリを実行してエラーを特定し、考えられる結果を理解します。 [+ 検出ルールの作成] を選択してカスタム検出リストから開始した場合は、ルール ウィザードでクエリを直接記述または貼り付けることができます。
重要
サービスから返されるアラートの数が多くなりすぎないように、各ルールは実行されるたびに 150 個のアラートのみを生成できます。 ルールを作成する前に、クエリを調整して、通常の毎日のアクティビティに対してアラートが生成されないようにします。
クエリ結果に必要な列
Defender データを使用してカスタム検出ルールを作成するには、クエリから次の列が返されることをお勧めします。
-
TimestampまたはTimeGenerated- この列は、生成されたアラートのタイムスタンプを設定します。 これらの列が KQL から投影されていない場合、生成されたアラートの最初と最後のイベント時刻は、検出のルックバック ウィンドウに従って設定されます。 -
Microsoft Defender for Endpointテーブルの場合は、
DeviceId列またはDeviceName列を含めて、次のことを確認します。- アラートには、適切なデバイス グループ スコープでタグ付けされます
- プロセス ツリー ビューが正常にビルドされました。
-
その他すべての Defender テーブルでは、Defender がアラートをトリガーした元のイベントを確実に識別できるように、同じイベントから
TimestampとReportIdを投影します。- アラートには、適切なエンティティ スコープがタグ付けされます (Defender XDR スコープを使用する組織にのみ関連します)
- アラート タイムライン ビューは、関連するデータで完全に強化されています。
- ウィザードで影響を受ける資産を自動的にマップするには、影響を受ける資産の厳密な識別子を含む次の列のいずれかを投影します。
- デバイス:
DeviceIdDeviceNameRemoteDeviceName
- メールボックス:
RecipientEmailAddress-
SenderFromAddress(封筒送信者または Return-Path アドレス) -
SenderMailFromAddress(メール クライアントによって表示される送信者アドレス) SenderObjectIdRecipientObjectId
- アカウント:
AccountObjectIdAccountSidAccountUpnInitiatingProcessAccountSidInitiatingProcessAccountUpn
- デバイス:
project演算子やsummarize演算子を使用して結果をカスタマイズまたは集計しない単純なクエリは、通常、これらの推奨列を返します。
より複雑なクエリがこれらの列を返すようにするには、さまざまな方法があります。 たとえば、AccountObjectIdなどの列の下でエンティティを集計してカウントする場合でも、一意のTimestampを含む最新のイベントから取得することで、ReportIdとAccountObjectIdを返すことができます。
重要
Timestamp列またはTimeGenerated列を使用してカスタム検出をフィルター処理しないようにします。 このサービスは、検出ルックバックに基づいてカスタム検出用のデータを事前フィルター処理します。 特定のルックバック ウィンドウのサンセットが評価されるように追加のフィルタリングを行う場合にのみ、結果を Timestamp 列または TimeGenerated 列でフィルタリングします。
次のサンプル クエリでは、ウイルス対策検出を使用して一意のデバイス (DeviceId) の数をカウントし、この数を使用して 5 つを超える検出を持つデバイスのみを検索します。 最新のTimestampと対応するReportIdを返すには、summarize 関数で arg_max 演算子を使用します。
DeviceEvents
| where ingestion_time() > ago(1d)
| where ActionType == "AntivirusDetection"
| summarize (Timestamp, ReportId)=arg_max(Timestamp, ReportId), count() by DeviceId
| where count_ > 5
ヒント
クエリのパフォーマンスを向上させるには、ルールの目的の実行頻度に一致する時間フィルターを設定します。 最も頻度の低い実行は 24 時間ごとに実行されるため、過去 1 日のフィルター処理はすべての新しいデータを対象としています。
Microsoft Sentinel のスコープ指定用カスタム列
Microsoft Sentinel のスコープ設定を構成した場合、SentinelScope_CF カスタム フィールドをクエリや検出ルールで使用して、分析でスコープを参照できます。
カスタム検出と分析ルールを作成する場合は、トリガーされたアラートをスコープ付きアナリストに表示するために、クエリに SentinelScope_CF 列を投影する必要があります。 この列を投影しない場合、アラートのスコープは解除され、スコープ付きユーザーには非表示になります。
2. 新しいルールを作成し、アラートの詳細を指定する
クエリ エディターで、[ 検出ルールの作成 ] を選択し、次のアラートの詳細を指定します。
- 検出名 - 検出規則の名前。一意にします。
- Frequency - クエリを実行してアクションを実行するための間隔。 詳細については、「ルールの 頻度」を参照してください。
- ルックバック - カスタム検出がMicrosoft Sentinelからのデータのみを対象とするクエリの対象となる期間。 詳細については、「 ルックバック」を参照してください。
- アラート タイトル - ルールによってトリガーされたアラートと共に表示されるタイトル。それを一意にし、プレーンテキストを使用します。 文字列はセキュリティ上の目的でサニタイズされるため、HTML、Markdown、およびその他のコードは機能しません。 タイトルに含まれる URL は、正しく表示するために パーセント エンコード形式 に従う必要があります。
- 重大度 - ルールによって識別されるコンポーネントまたはアクティビティの潜在的なリスク。
- カテゴリ - ルールによって識別される脅威コンポーネントまたはアクティビティ。
- 戦術 - MITRE ATT&CK フレームワークに記載されている規則によって識別される MITRE ATT&CK 戦術。
- 手法 - MITRE ATT&CK フレームワークに記載されている規則によって識別される 1 つ以上の攻撃手法。
- サブ手法 - MITRE ATT&CK フレームワークに記載されているように、ルールによって識別される 1 つ以上の攻撃サブ手法。
- 脅威分析レポート - 生成されたアラートを既存の脅威分析レポートにリンクして、脅威分析の [ 関連インシデント ] タブに表示されるようにします。
- 説明 - ルールによって識別されるコンポーネントまたはアクティビティの詳細。 文字列はセキュリティ上の目的でサニタイズされるため、HTML、Markdown、およびその他のコードは機能しません。 説明に含まれる URL は、正しく表示するためにパーセントエンコード形式に従う必要があります。
- 推奨されるアクション - アラートに応答してレスポンダーが実行する可能性があるその他のアクション。
ルールの頻度
新しいルールを保存すると、過去 30 日間のデータの一致が実行されてチェックされます。 その後、ルールは一定の間隔で再び実行され、選択した頻度に基づいて ルックバック期間 が適用されます。
- 24 時間ごと
- 12 時間ごと
- 3 時間ごと
- 1 時間ごとに
- 継続的 (NRT) - ほぼリアルタイム (NRT) で収集および処理されるイベントからのデータを確認して、継続的に実行します。 詳細については、「 継続的 (NRT) 頻度」を参照してください。
- [カスタム ] - 選択した頻度に従って実行されます。 このオプションは、ルールがMicrosoft Sentinelに取り込まれたデータのみに基づいている場合に使用できます。 詳細については、「Microsoft Sentinel データのカスタム頻度」を参照してください。
ヒント
クエリ内の時間フィルターをルックバック期間と一致させます。 ルックバック期間外の結果は無視されます。
ルールを編集すると、設定した頻度に従ってスケジュールされた次の実行時に変更が適用されます。 ルールの頻度は、インジェスト時間ではなく、イベント タイムスタンプに基づいています。 特定の実行で小さな遅延が発生する可能性があるため、構成された頻度は 100% 正確ではありません。
連続(NRT)周波数
カスタム検出を継続的 (NRT) 頻度で実行するように設定すると、脅威をより迅速に識別するorganizationの能力が向上します。 継続的 (NRT) の頻度を使用すると、リソースの使用状況に与える影響は最小限に抑えられます。 組織内の適格なカスタム検出ルールに使用することを検討してください。
[カスタム検出ルール] ページで、[ 今すぐ移行] を選択することで、継続的 (NRT) 頻度に合ったカスタム検出ルールを移行できます。
[ 今すぐ移行] を選択すると、KQL クエリに従って互換性のあるすべてのルールの一覧が表示されます。 すべてのルールまたは選択したルールのみを移行できます。
[保存] を選択すると、選択したルールの頻度が継続的 (NRT) 頻度に更新されます。
継続的に実行できるクエリ
クエリは、次の場合に限り継続的に実行できます。
- クエリは 1 つのテーブルのみを参照します。
- クエリでは、 サポートされている KQL 機能の一覧から演算子を使用します。
matches regex演算子の場合は、正規表現を文字列リテラルとしてエンコードし、文字列引用符で囲む規則に従う必要があります。 たとえば、正規表現\Aは KQL で"\\A"として表されます。 余分な円記号は、もう一方の円記号が正規表現\Aの一部であることを示します。 - クエリでは、結合、共用体、または
externaldata演算子は使用されません。 - クエリにはコメント行や情報は含まれません。
継続的 (NRT) 頻度をサポートするテーブル
ほぼリアルタイム検出では、次の表がサポートされています。
| Microsoft Defender XDR | Microsoft Sentinel |
|---|---|
|
|
注:
一般公開されている列のみが 継続的 (NRT) 頻度を サポートします。
Microsoft Sentinel データのカスタム頻度
Microsoft Defender を導入する Microsoft Sentinel のお客様は、ルールが Microsoft Sentinel で取り込まれるデータのみに基づいている場合、頻度として カスタム を選択できます。
この頻度オプションを選択すると、入力のたびにクエリを実行コンポーネントが表示されます。 ルールの目的の頻度を入力し、ドロップダウンを使用して単位 (分、時間、または日) を選択します。 サポートされる範囲は、5 分から 14 日までの任意の値です。
重要
カスタム頻度を選択すると、Defender はMicrosoft Sentinelからデータをフェッチします。 この条件は、次のことを意味します。
- Microsoft Sentinelで使用できるデータが必要です。
- Microsoft Sentinelではスコープがサポートされていないため、Defenderデータはスコープをサポートしていません。
ルックバック
カスタム検出のルックバック期間は、ターゲット データとクエリの頻度に応じて、5 分から 30 日の範囲で行うことができます。
カスタム検出にDefender XDRデータが含まれている場合、選択したルールの頻度に応じて、一定のルックバック期間が適用されます。
- 検出が 24 時間ごとに実行されるように設定されている場合、ルックバック期間は 30 日です。
- 検出が 12 時間ごとに実行されるように設定されている場合、ルックバック期間は 48 時間です。
- 検出が 3 時間ごとに実行されるように設定されている場合、ルックバック期間は 12 時間です。
- 検出が 時間単位で実行されるように設定されている場合、ルックバック期間は 4 時間です。
カスタム検出が Microsoft Sentinel のデータのみを対象としている場合は、設定したルールの頻度に応じてルックバック期間をカスタマイズできます。
- 検出が 1 時間より高い頻度 (より頻繁) に実行されるように設定されている場合、ルックバック期間は 48 時間未満に制限されます。
- 検出が 1 日を超える頻度で実行されるように設定されている場合、ルックバックは 最大 14 日に設定できます。
- 検出が 1 日以下の頻度で実行されるように設定されている場合、ルックバックは 最大 30 日に設定できます。
重要
カスタム検出は、インジェストの遅延を考慮して ingestion_time() を評価します。 カスタム検出ではイベント タイムスタンプではなく ingestion_time() が評価されるため、構成されたルックバック期間より古い値 Timestamp または TimeGenerated 値を持つイベントは、引き続きルールの評価に含まれる可能性があります。
ルックバック期間が頻度より長い場合、重複するイベントが発生する可能性があります。 ただし、カスタム検出は、アラート のノイズと疲労を減らすために、それらをグループ化して 自動的に 重複除去します。
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の場合は、エンティティを手動で選択する必要があります。
注:
エンティティは、アラートをインシデントにグループ化する方法に影響します。 インシデントの高品質を確保するために、エンティティを慎重に確認してください。 詳細については、Microsoft Defender ポータルでのアラートの関連付けとインシデントのマージに関するページを参照してください。
展開された エンティティ マッピング セクションには、エンティティを選択できる 2 つのセクションがあります。
-
影響を受けた資産 – 選択したイベントに表示される影響を受けた資産を追加します。 次の種類の資産を追加できます。
- アカウント
- デバイス
- メールボックス
- クラウド アプリケーション
- Azure リソース
- Amazon Web Services リソース
- Google Cloud Platform リソース
-
関連する証拠 – 選択したイベントに表示される非アセットを追加します。 サポートされているエンティティ型は次のとおりです。
- プロセス
- ファイル
- レジストリ値
- IP
- OAuth アプリケーション
- DNS
- セキュリティ グループ
- URL
- メール クラスター
- メール メッセージ
注:
現在、資産のみを影響を受けたエンティティとしてマップできます。
エンティティ型を選択した後、選択したクエリ結果に存在する識別子の種類を選択して、それを使用してこのエンティティを識別できるようにします。 各エンティティの種類には、関連するドロップダウン メニューに示すように、サポートされている識別子の一覧があります。 各識別子について理解を深めるために、ポインターを合わせると表示される説明をお読みください。
識別子を選択したら、選択した識別子を含むクエリ結果から列を選択します。 [ クエリと結果の探索] を選択して、高度なハンティング コンテキスト パネルを開きます。 このオプションを使用すると、クエリと結果を調べて、選択した識別子に適した列を選択できます。
4. アクションを指定する
カスタム検出ルールでDefenderデータが使用されている場合、クエリが返すデバイス、ファイル、ユーザー、または電子メールに対して自動的にアクションを実行できます。
デバイスでのアクション
クエリ結果の [ DeviceId ] 列のデバイスに次のアクションを適用します。
- デバイスの分離 - Microsoft Defender for Endpointを使用して完全なネットワーク分離を適用し、デバイスがアプリケーションまたはサービスに接続できないようにします。 詳しくは、Microsoft Defender for Endpointマシンの分離に関するページをご覧ください。
- 調査パッケージの収集 - ZIP ファイル内のデバイス情報を収集します。 Microsoft Defender for Endpoint調査パッケージの詳細については、こちらをご覧ください。
- ウイルス対策スキャンの実行 - デバイスで完全なMicrosoft Defenderウイルス対策スキャンを実行します。
- 調査の開始 - デバイスの 自動調査 を開始します。
- アプリの実行を制限 する - Microsoft が発行した証明書で署名されたファイルのみを実行できるように、デバイスに制限を設定します。 Microsoft Defender for Endpointでのアプリの制限について詳しくは、こちらをご覧ください。
ファイルへのアクション
選択すると、[ 許可/ブロック] アクションをファイルに適用できます。 ファイルのブロックは、ファイルの 修復 アクセス許可があり、クエリの結果で SHA-1 ハッシュなどのファイル ID が識別される場合にのみ許可されます。 ファイルがブロックされると、すべてのデバイス上の同じファイルの他のインスタンスもブロックされます。 ブロックが適用されるデバイス グループを制御できますが、特定のデバイスには適用されません。
選択した場合、ファイルを隔離 アクションを、クエリ結果の
SHA1、InitiatingProcessSHA1、SHA256、またはInitiatingProcessSHA256列のファイルに適用できます。 このアクションでは、ファイルが現在ある場所から削除され、コピーが検疫に入ります。
ユーザーへのアクション
選択すると、ユーザーを侵害済みとしてマーク アクションが、クエリ結果の
AccountObjectId、InitiatingProcessAccountObjectId、またはRecipientObjectId列のユーザーに対して適用されます。 このアクションにより、ユーザーのリスク レベルがMicrosoft Entra IDで "高" に設定され、対応する ID 保護ポリシーがトリガーされます。ユーザーのサインインを一時的に禁止するには、[ ユーザーの無効化] を選択します。
[ユーザー認証のリセット] を選択して、次のサインイン セッションでパスワードを変更するか (オンプレミス ID の場合)、もう一度サインインするように要求するか (Microsoft Entra ID の場合)、ユーザーにメッセージを表示します。
[ユーザー認証の無効化] オプションと [ユーザー認証のリセット] オプションの両方で、
AccountSid、InitiatingProcessAccountSid、RequestAccountSid、OnPremSidの列にあるユーザー セキュリティ識別子 (SID) が必要です。Microsoft Entra ID の場合、すべてのアクションに
AccountObjectIdパラメーターが必要です。
ユーザーアクションの詳細については、「Microsoft Defender for Identityの修復アクション」と「Microsoft Defender for Cloud Appsの修復アクション」を参照してください。
メールに対するアクション
カスタム検出によってメール メッセージが生成される場合は、[ メールボックス フォルダーに移動 ] を選択して、選択したフォルダー ( 迷惑メール、 受信トレイ、または 削除済みアイテム のフォルダー) にメールを移動できます。 具体的には、受信トレイ オプションを選択すると、隔離済みアイテムからメールを移動できます (たとえば誤検知の場合)。
または、[ メールの削除 ] を選択し、メールを削除済みアイテム (論理的な削除) に移動するか、選択したメールを完全に削除 (ハード削除) するかを選択できます。
電子メール メッセージにアクションを適用するには、クエリの出力結果に NetworkMessageId 列と RecipientEmailAddress 列が存在する必要があります。
5. ルールの範囲を設定する
ルールがカバーするデバイスを指定するスコープを設定します。 この範囲で、デバイスをチェックするルールが影響されますが、メールボックスのみをチェックするルールやユーザー アカウントまたは ID のみをチェックするルールには影響はありません。
スコープを設定する場合は、次を選択します。
- すべてのデバイス
- 特定のデバイス グループ
ルールは、スコープ内のデバイスからのみデータを照会します。 これらのデバイスでのみアクションが実行されます。
注:
ユーザーは、ルールのスコープに含まれるデバイスに対応するアクセス許可を持っている場合にのみ、カスタム検出ルールを作成または編集できます。 たとえば、管理者は、すべてのデバイス グループに対するアクセス許可がある場合にのみ、すべてのデバイス グループを対象とするルールを作成または編集できます。
6. ルールを確認して有効にする
ルールを確認した後、[作成] を選択して保存します。 カスタム検出ルールはすぐに実行されます。 一致をチェックし、アラートを生成し、応答アクションを実行するように構成された頻度に基づいて、もう一度実行されます。
重要
効率と有効性を確認するために、カスタム検出を定期的に確認します。 クエリを最適化する方法のガイダンスについては、「 高度なハンティング クエリのベスト プラクティス」を参照してください。 真のアラートをトリガーする検出を作成していることを確認するには、「既存のカスタム検出ルールを管理する」の手順に従って、既存の カスタム検出を確認する時間がかかります。
カスタム検出の広さまたは特異性を制御します。 カスタム検出によって生成された誤ったアラートは、ルールの特定のパラメーターを変更する必要があることを示している可能性があります。
カスタム検出で重複アラートを処理する方法
カスタム検出ルールを作成して確認する際の重要な考慮事項は、アラート のノイズと疲労です。 カスタム検出は、イベントをグループ化し、重複を排除して 1 件のアラートにまとめます。 同じエンティティ、カスタムの詳細、動的な詳細を含むイベントでカスタム検出ルールが 2 回実行される場合、両方のイベントに対して 1 つのアラートが作成されます。 検出ルールでイベントが同一であると認識された場合は、作成されたアラートのイベントの 1 つをログに記録し、重複を処理します。 ルックバック期間が頻度より長い場合、重複が発生する可能性があります。 イベントが異なる場合、カスタム検出では両方のイベントがアラートに記録されます。
関連コンテンツ
- カスタム検出の概要
- カスタム検出を管理する
- 高度なハンティングの概要
- 高度な捜索のクエリ言語について学習する
- 高度なハンティング クエリをMicrosoft Defender for Endpointから移行する
- カスタム検出用の Microsoft Graph セキュリティ API
ヒント
さらに詳しく知りたいですか? Tech Community 内の Microsoft Security コミュニティにご参加ください: 「Microsoft Defender XDR Tech Community」。