Microsoft Sentinel での擬陽性の処理

[アーティクル]
01/22/2024

ネットワークで疑わしい問題が発生すると、Microsoft Azure Sentinel の分析ルールによって通知されます。完璧な分析ルールはありません。必ず処理が必要な偽陽性を受け取ります。この記事では、オートメーションを使用するか、スケジュールが設定された分析ルールを変更して、偽陽性を処理する方法について説明します。

偽陽性の原因と防止

正しく構築された分析ルールでも、多くの場合、偽陽性はルールから除外する必要があるユーザーや IP アドレスのような特定のエンティティに由来します。

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

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

この記事では、偽陽性を回避する 2 つの方法について説明します。

オートメーションルールでは、分析ルールを変更することなく、例外を作成します。
スケジュールが設定された分析ルールの変更では、より詳細で永続的な例外を許可します。

次の表で、各方法の特徴について説明します。

Method	特徴
オートメーションルール	複数の分析ルールに適用できる。監査証跡が保持される。例外によって、作成されたインシデントが自動的かつ直ちにクローズされ、クローズの理由とコメントが記録されます。多くの場合、アナリストによって生成される。限られた時間で例外の適用が許可される。たとえば、メンテナンス作業によって、メンテナンス期間外では真のインシデントになる偽陽性がトリガーされる場合があります。
分析ルールの変更	高度なブール式およびサブネットベースの例外を許可する。ウォッチリストを使用して例外管理を一元化できる。通常はセキュリティオペレーションセンター (SOC) のエンジニアによる実装が必要。最も柔軟で完全な偽陽性ソリューションであるが、より複雑。

Method

特徴

オートメーションルール

複数の分析ルールに適用できる。
監査証跡が保持される。例外によって、作成されたインシデントが自動的かつ直ちにクローズされ、クローズの理由とコメントが記録されます。
多くの場合、アナリストによって生成される。
限られた時間で例外の適用が許可される。たとえば、メンテナンス作業によって、メンテナンス期間外では真のインシデントになる偽陽性がトリガーされる場合があります。

分析ルールの変更

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

オートメーションルールを使用して例外を追加する

例外を追加する最も簡単な方法は、偽陽性のインシデントが表示されたときにオートメーションルールを追加することです。

偽陽性を処理するオートメーションルールを追加するには、次のようにします。

Microsoft Azure Sentinel の [インシデント] で、例外を作成するインシデントを選択します。
[オートメーションルールを作成する] を選択します。
[Create new automation rule](新しいオートメーションルールの作成) サイドバーで、必要に応じて、アラートルール名だけではなく、新しいルール名を変更して例外を識別します。
[条件] の下に、必要に応じて、例外を適用する分析ルール名を追加します。分析ルール名を含むドロップダウンボックスを選択し、一覧からさらに分析ルールを選択します。
サイドバーには、現在のインシデントで、偽陽性の原因となった可能性がある特定のエンティティが表示されます。自動提案を受け入れるか、修正して例外を微調整します。たとえば、IP アドレスの条件を変更して、サブネット全体に適用することができます。
条件の設定が完了したら、ルールの処理内容の定義に進みます。
- このルールは、例外条件を満たすインシデントをクローズするように既に構成されています。
- 指定した終了理由をそのままにすることも、別の理由がより適切な場合は変更することもできます。
- 自動的にクローズされたインシデントには、例外を説明するコメントを追加できます。たとえば、インシデントが既知の管理アクティビティからのものであることを指定できます。
- 既定では、ルールは 24 時間後に自動的に期限が切れるように設定されます。この有効期限は必要な場合があり、偽陰性のエラーが発生する可能性を減らします。より長い例外が必要な場合は、 [ルールの有効期限] を後の時間に設定してください。
必要に応じて、アクションをさらに追加できます。たとえば、インシデントにタグを追加したり、プレイブックを実行してメールや通知を送信したり、外部システムと同期したりできます。
[適用] を選択して例外をアクティブにします。

ヒント

インシデントから開始することなく、オートメーションルールをゼロから作成することもできます。 Microsoft Azure Sentinel の左側のナビゲーションメニューから [オートメーション] を選択し、 [作成]>[新しいルールの追加] を選択します。自動化ルールの詳細情報については、こちらをご覧ください。

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

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

クエリを変更する

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

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

一般的なルールプリアンブルで例外を実装するために、ルールクエリの先頭付近に 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'

サブネットを除外する

組織で使用される 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');

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

SAP® アプリケーション用の Microsoft Sentinel ソリューションには、アラートのトリガーからユーザーまたはシステムを除外するために使用できる機能が用意されています。

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

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

次のステップ

詳細については、次を参照してください。