Microsoft Sentinelで誤検知を処理する

重要

カスタム検出は、SIEM Microsoft Defender XDR全体で新しいルールMicrosoft Sentinel作成するための最良の方法になりました。カスタム検出を使用すると、インジェストコストを削減し、無制限のリアルタイム検出を取得し、自動エンティティマッピングを使用してDefender XDRデータ、関数、修復アクションとシームレスに統合できます。詳細については、このブログを参照してください。

Microsoft Sentinel分析ルールは、ネットワークで疑わしいことが発生したときに通知します。分析ルールは完璧でなく、処理が必要な誤検知を受け取る必要があります。この記事では、自動化を使用するか、スケジュールされた分析ルールを変更して、誤検知を処理する方法について説明します。

誤検知の原因と予防

正しく構築された分析ルールでも、誤検知は、多くの場合、ルールから除外する必要があるユーザーや IP アドレスなどの特定のエンティティから発生します。

一般的なシナリオは次のとおりです。

特定のユーザー (通常はサービスプリンシパル) による通常のアクティビティは、疑わしいと思われるパターンを示します。
既知の IP アドレスからの意図的なセキュリティスキャンアクティビティは、悪意のあるものとして検出されます。
プライベート IP アドレスを除外するルールでは、プライベートではない一部の内部 IP アドレスも除外する必要があります。

この記事では、誤検知を回避するための 2 つの方法について説明します。

自動化ルール では、分析ルールを変更せずに例外が作成されます。
スケジュールされた分析ルールの変更により、 より詳細で永続的な例外が許可されます。

次の表では、各メソッドの特性について説明します。

メソッド	特性
自動化ルール	複数の分析ルールに適用できます。監査証跡を保持します。例外は、作成されたインシデントを直ちに自動的に閉じ、終了の理由とコメントを記録します。多くの場合、アナリストによって生成されます。制限付き時間の例外の適用を許可します。たとえば、メンテナンス作業によって誤検知が発生し、メンテナンス期間外が真のインシデントになる可能性があります。
分析ルールの変更	高度なブール式とサブネットベースの例外を許可します。ウォッチリストを使用して例外管理を一元化できます。通常、Security Operations Center (SOC) エンジニアによる実装が必要です。最も柔軟で完全な偽陽性ソリューションですが、より複雑です。

メソッド

特性

自動化ルール

複数の分析ルールに適用できます。
監査証跡を保持します。例外は、作成されたインシデントを直ちに自動的に閉じ、終了の理由とコメントを記録します。
多くの場合、アナリストによって生成されます。
制限付き時間の例外の適用を許可します。たとえば、メンテナンス作業によって誤検知が発生し、メンテナンス期間外が真のインシデントになる可能性があります。

分析ルールの変更

高度なブール式とサブネットベースの例外を許可します。
ウォッチリストを使用して例外管理を一元化できます。
通常、Security Operations Center (SOC) エンジニアによる実装が必要です。
最も柔軟で完全な偽陽性ソリューションですが、より複雑です。

自動化ルールを使用して例外を追加する (Azure portalのみ)

この手順では、誤検知インシデントが発生したときに自動化ルールを追加する方法について説明します。この手順は、Azure portalでのみサポートされています。

Microsoft Sentinelが Defender ポータルにオンボードされている場合は、インシデントの詳細に基づいて自動化ルールをゼロから作成します。詳細については、「自動化ルールを使用したMicrosoft Sentinelでの脅威対応の自動化」を参照してください。

誤検知を処理する自動化ルールを追加するには:

Microsoft Sentinelの [インシデント] で、例外を作成するインシデントを選択します。
横の [インシデントの詳細] ウィンドウで、[ アクション] > [自動化ルールの作成] を選択します。
[ 新しい自動化ルールの作成 ] サイドバーで、必要に応じて、アラートルール名だけでなく、例外を識別するように新しいルール名を変更します。
[ 条件] で、必要に応じて、例外を適用する 分析ルール名s を追加します。分析ルール名を含むドロップダウンボックスを選択し、一覧からその他の分析ルールを選択します。
サイドバーには、誤検知の原因となった可能性がある現在のインシデント内の特定のエンティティが表示されます。自動候補を保持するか、例外を微調整するように変更します。たとえば、サブネット全体に適用する IP アドレスの条件を変更できます。
条件に満足したら、サイドウィンドウを下にスクロールして、引き続きルールの動作を定義します。
- ルールは、例外条件を満たすインシデントを閉じるよう既に構成されています。
- 指定した終了理由をそのまま保持することも、別の理由がより適切な場合は変更することもできます。
- 例外を説明する自動的に閉じられたインシデントにコメントを追加できます。たとえば、インシデントが既知の管理アクティビティから発生したことを指定できます。
- 既定では、ルールは 24 時間後に自動的に期限切れに設定されます。この有効期限は必要な場合があり、誤った負のエラーが発生する可能性を減らします。より長い例外が必要な場合は、 ルールの有効期限 を後の時刻に設定します。
必要に応じて、さらにアクションを追加できます。たとえば、インシデントにタグを追加したり、プレイブックを実行してメールや通知を送信したり、外部システムと同期したりできます。
[ 適用] を選択して例外をアクティブにします。

分析ルールを変更して例外を追加する

例外を実装するためのもう 1 つのオプションは、分析ルールクエリを変更することです。ルールに例外を直接含めることができます。可能な場合はウォッチリストへの参照を使用します。その後、ウォッチリストで例外リストを管理できます。

クエリを変更する

既存の分析ルールを編集するには、左側のナビゲーションメニュー Microsoft Sentinel [Automation] を選択します。編集するルールを選択し、右下にある [編集 ] を選択して 、分析ルールウィザードを開きます。

分析ルールウィザードを使用して分析ルールを作成および編集する方法の詳細については、「脅威を検出するためのカスタム分析ルールを作成する」を参照してください。

一般的なルールのプリアンブルで例外を実装するには、ルールクエリの先頭付近に where IPAddress !in ('<ip addresses>') のような条件を追加します。この行は、ルールから特定の IP アドレスを除外します。

let timeFrame = 1d;
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| where IPAddress !in ('10.0.0.8', '192.168.12.1')
...

この種類の例外は、IP アドレスに限定されません。 [ UserPrincipalName ] フィールドを使用して特定のユーザーを除外したり、 AppDisplayNameを使用して特定のアプリを除外したりできます。

複数の属性を除外することもできます。たとえば、IP アドレス 10.0.0.8 またはユーザー user@microsoft.comからアラートを除外するには、次を使用します。

| where IPAddress !in ('10.0.0.8')
| where UserPrincipalName != 'user@microsoft.com'

該当する場合に、よりきめ細かい例外を実装し、偽陰性の可能性を減らすために、属性を組み合わせることができます。次の例外は、両方の値が同じアラートに表示される場合にのみ適用されます。

| where IPAddress != '10.0.0.8' and UserPrincipalName != 'user@microsoft.com'

サブネットを除外する

organizationで使用される IP 範囲を除外するには、サブネットの除外が必要です。次の例は、サブネットを除外する方法を示しています。

ipv4_lookup 演算子はエンリッチメント演算子であり、フィルター処理演算子ではありません。 where isempty(network)行は、一致するものが表示されないイベントを検査することで、実際にはフィルター処理を行います。

let subnets = datatable(network:string) [ "111.68.128.0/17", "5.8.0.0/19", ...];
let timeFrame = 1d;
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| evaluate ipv4_lookup(subnets, IPAddress, network, return_unmatched = true)
| where isempty(network)
...

ウォッチリストを使用して例外を管理する

ウォッチリストを使用して、ルール自体の外部にある例外の一覧を管理できます。該当する場合、このソリューションには次の利点があります。

アナリストは、SOC のベストプラクティスに従って、ルールを編集せずに例外を追加できます。
同じウォッチリストを複数のルールに適用して、一元的な例外管理を有効にすることができます。

ウォッチリストの使用は、直接例外の使用に似ています。ウォッチリストを呼び出すには、 _GetWatchlist('<watchlist name>') を使用します。

let timeFrame = 1d;
let logonDiff = 10m;
let allowlist = (_GetWatchlist('ipallowlist') | project IPAddress);
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| where IPAddress !in (allowlist)
...

ウォッチリストを使用してサブネットのフィルター処理を行うこともできます。たとえば、前のサブネットの除外コードでは、サブネット datatable 定義をウォッチリストに置き換えることができます。

let subnets = _GetWatchlist('subnetallowlist');

前の例で使用した次の項目の詳細については、Kusto のドキュメントを参照してください。

KQL の詳細については、「Kusto 照会言語 (KQL) の概要」を参照してください。

その他のリソース：

例: SAP® アプリケーションのMicrosoft Sentinel ソリューションの例外を管理する

SAP® アプリケーション用のMicrosoft Sentinel ソリューションは、ユーザーまたはシステムがアラートをトリガーしないようにするために使用できる機能を提供します。

ユーザーを除外します。 SAPUsersGetVIP 関数を使用して、次の処理を行います。
- アラートのトリガーから除外するユーザーの呼び出しタグ。アスタリスク (*) をワイルドカードとして使用して、 SAP_User_Config ウォッチリストのユーザーにタグを付け、指定した名前付け構文ですべてのユーザーにタグを付けます。
- アラートのトリガーから除外する特定の SAP ロールまたはプロファイルを一覧表示します。
システムを除外します。 SelectedSystemRoles パラメーターをサポートする関数を使用して、運用システムのみ、UAT システムのみ、またはその両方を含む、特定の種類のシステムのみがアラートをトリガーすることを決定します。

詳細については、「SAP® アプリケーションのソリューションMicrosoft Sentinelデータリファレンス」を参照してください。

詳細については、以下を参照してください:

フィードバック

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

Last updated on 2026-04-23