カスタム検出ルールを作成および管理する

[アーティクル]
10/18/2024

適用対象:

Microsoft Defender XDR

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

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

重要

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

カスタム検出を管理するには、次の役割の割り当てのうちどれかが必要になります。

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

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

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

注:

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

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

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

注:

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

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

1. クエリを準備する

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

重要

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

クエリ結果に必要な列

カスタム検出ルールを作成するには、クエリで次の列を返す必要があります。

Timestamp—生成されたアラートのタイムスタンプを設定するために使用されます
ReportId—元のレコードのルックアップを有効にします
特定のデバイス、ユーザー、またはメールボックスを識別する次のいずれかの列。
- DeviceId
- DeviceName
- RemoteDeviceName
- RecipientEmailAddress
- SenderFromAddress (封筒送信者または Return-Path アドレス)
- SenderMailFromAddress (メールクライアントによって表示される送信者アドレス)
- RecipientObjectId
- AccountObjectId
- AccountSid
- AccountUpn
- InitiatingProcessAccountSid
- InitiatingProcessAccountUpn
- InitiatingProcessAccountObjectId

注:

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

or 演算子を使用projectsummarizeして結果をカスタマイズまたは集計しない単純なクエリは、通常、これらの共通列を返します。

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

重要

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

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

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. 新しいルールを作成し、アラートの詳細を指定する

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

検出名 — 検出ルールの名前。一意である必要があります
頻度 — クエリを実行してアクションを実行するための間隔。ルールの頻度に関するセクションで、その他のガイダンスを参照してください
アラートタイトル — ルールによってトリガーされたアラートと共に表示されるタイトル。一意である必要があります
重大度 - ルールによって識別されるコンポーネントまたはアクティビティの潜在的なリスク
カテゴリ - ルールによって識別される脅威コンポーネントまたはアクティビティ
MITRE ATT&CK 手法 — MITRE ATT&CK フレームワークに記載されているように、ルールによって識別される 1 つ以上の攻撃手法。このセクションは、マルウェア、ランサムウェア、不審なアクティビティ、不要なソフトウェアなど、特定のアラートカテゴリでは非表示です
説明 — ルールによって識別されるコンポーネントまたはアクティビティに関する詳細情報
推奨されるアクション - アラートに応答して応答者が実行する可能性がある追加のアクション

ルールの頻度

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

24 時間ごと — 24 時間ごとに実行され、過去 30 日間のデータが確認されます
12 時間ごと — 12 時間ごとに実行され、過去 48 時間のデータが確認されます
3 時間ごと — 3 時間ごとに実行され、過去 12 時間のデータが確認されます
1 時間ごとに 実行され、過去 4 時間のデータが確認されます
継続的 (NRT) — 継続的に実行され、ほぼリアルタイム (NRT) で収集および処理されるイベントからのデータを確認します。「継続的 (NRT) 頻度」を参照してください。

ヒント

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

ルールを編集すると、設定した頻度に従ってスケジュールされた次の実行時に、適用する変更と一緒に実行されます。ルールの頻度は、インジェスト時間ではなく、イベントタイムスタンプに基づいています。

連続 (NRT) 周波数

カスタム検出を継続的 (NRT) 頻度で実行するように設定すると、脅威をより迅速に特定するorganizationの能力を向上させることができます。

注:

継続的 (NRT) 頻度の使用は、リソースの使用状況への影響を最小限に抑えるので、organization内の修飾されたカスタム検出ルールについて考慮する必要があります。

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

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

クエリは 1 つのテーブルのみを参照します。
クエリでは、サポートされている KQL 演算子の一覧から演算子を使用します。 サポートされている KQL 機能
クエリでは、結合、共用体、または演算子は externaldata 使用されません。
クエリにはコメント行/情報は含まれません。

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

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

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

注:

継続的 (NRT) 頻度をサポートできるのは、一般公開されている列のみです。

3. 影響を受けたエンティティの選択

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

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

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

カスタム検出ルールは、クエリによって返されるデバイス、ファイル、ユーザー、または電子メールに対して自動的にアクションを実行できます。

デバイスでのアクション

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

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

ファイルへのアクション

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

ユーザーへのアクション

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

Disable userオプションと Force password reset オプションの両方に、、、、および OnPremSidの各列AccountSidInitiatingProcessAccountSidRequestAccountSidに含まれるユーザー SID が必要です。

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

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

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

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

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

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

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

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

スコープ内のデバイスからのデータのみがクエリされます。また、これらのデバイスでのみアクションが実行されます。

注:

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

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

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

重要

効率と有効性については、カスタム検出を定期的に確認する必要があります。真のアラートをトリガーする検出を作成していることを確認するには、「既存のカスタム検出イオンルールを管理する」の手順に従って、既存のカスタム検出を確認する時間がかかります。

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

既存のカスタム検出ルールを管理する

既存のカスタム検出ルールの一覧を表示し、以前の実行をチェックし、トリガーされたアラートを確認できます。必要に応じてルールを実行し、変更することもできます。

ヒント

カスタム検出によって発生したアラートは、アラートとインシデント API を介して使用できます。詳細については、「サポートされているMicrosoft Defender XDR API」を参照してください。

既存のルールを表示する

既存のすべてのカスタム検出ルールを表示するには、[ ハンティング>カスタム検出ルール] に移動します。ページには、次の実行情報を含むすべてのルールが一覧表示されます。

最終実行 — クエリの一致をチェックしてアラートを生成するルールが最後に実行されたとき
最後の実行状態 — ルールが正常に実行されたかどうか
次の実行 — 次にスケジュールされた実行
状態 - ルールがオンまたはオフになっているかどうか

ルールの詳細の表示、ルールの変更、およびルールの実行

カスタム検出ルールに関する包括的な情報を表示するには、[ ハンティング>カスタム検出ルール ] に移動し、ルールの名前を選択します。その後、情報、実行状態、スコープなど、ルールに関する一般的な情報を表示できます。このページには、トリガーされたアラートとアクションの一覧も表示されます。

また、このページからルールに対して次のアクションを実行することもできます。

[実行 ] - ルールを直ちに実行します。これにより、次の実行の間隔もリセットされます。
編集 - クエリを変更せずにルールを変更する
クエリの変更 - 高度なハンティングでクエリを編集する
灯す / オフにする - ルールを有効にするか、実行を停止します
削除 - ルールをオフにして削除します

トリガーされたアラートを表示して管理する

ルールの詳細画面 (ハンティング>カスタム検出>[ルール名]) で、[ トリガーされたアラート] に移動します。ルールに一致して生成されたアラートが一覧表示されます。アラートを選択して、アラートに関する詳細情報を表示し、次のアクションを実行します。

状態と分類 (true または false アラート) を設定してアラートを管理する
アラートをインシデントにリンクする
高度な捜索でアラートをトリガーしたクエリを実行する

アクションを確認する

ルールの詳細画面 (ハンティング>カスタム検出>[ルール名]) で、[ トリガーされたアクション] に移動します。このアクションには、ルールへの一致に基づいて実行されたアクションが一覧表示されます。

ヒント

情報をすばやく表示し、テーブル内の項目に対してアクションを実行するには、テーブルの左側にある選択列 [✓] を使用します。

注:

この記事の一部の列は、Microsoft Defender for Endpointでは使用できない場合があります。 Microsoft Defender XDRをオンにして、より多くのデータソースを使用して脅威を探します。高度なハンティングワークフローをMicrosoft Defender for EndpointからMicrosoft Defender XDRに移動するには、「高度なハンティングクエリをMicrosoft Defender for Endpointから移行する」の手順に従います。

次の方法で共有