Microsoft Sentinelのウォッチリスト

Microsoft Sentinelのウォッチリストは、セキュリティ アナリストがイベント データを効率的に関連付け、エンリッチするのに役立ちます。 価値の高い資産や退職した従業員のリストなど、参照データを柔軟に管理できます。 監視リストを検出ルール、脅威ハンティング、応答ワークフローに統合して、アラートの疲労を軽減し、脅威に迅速に対応します。 この記事では、Microsoft Sentinelでウォッチリストを使用する方法、主要なシナリオと制限事項の概要、およびセキュリティ操作を強化するためのウォッチリストの作成とクエリに関するガイダンスについて説明します。

検索クエリ、検出ルール、脅威ハンティング、応答プレイブックでウォッチリストを使用します。 ウォッチリストは、Watchlist テーブルのMicrosoft Sentinel ワークスペースに名前と値のペアとして格納され、最適なクエリ パフォーマンスのためにキャッシュされます。

重要

ウォッチリスト テンプレートの機能と、Azure Storage 内のファイルからウォッチリストを作成する機能は、現在プレビュー段階にあります。 Azureプレビュー補足条項には、ベータ版、プレビュー版、または一般公開されていないAzure機能に適用される追加の法的条件が含まれています。

ウォッチリストを使用するタイミング

これらのシナリオではウォッチリストを使用します。

• 脅威を調査するには、IP アドレス、ファイル ハッシュ、その他のデータをカンマ区切り値 (CSV) ファイルからインポートし、ウォッチリストの名前と値のペアを、アラート ルール、脅威ハンティング、ワークブック、ノートブック、クエリでの結合やフィルター処理に使用します。

• ビジネス データ をウォッチリストとしてインポートします。 たとえば、特権を持つシステム アクセス権を持つユーザー リストや、終了した従業員のリストをインポートします。 次に、ウォッチリストを使用して許可リストとブロックリストを作成し、それらのユーザーがネットワークにサインインすることを検出または禁止します。

• アラートの疲労を軽減します。 許可リストを作成して、通常はアラートをトリガーするタスクを実行する承認された IP アドレスのユーザーなど、ユーザーのグループからのアラートを抑制します。 問題のないイベントがアラートにならないようにします。

• 外部データ ソースからの名前と値の組み合わせを使用してイベント データを強化します。

ウォッチリストの制限事項

ウォッチリストを作成する前に、次の制限事項を確認してください。

制限	詳細
ウォッチリスト名とエイリアスの長さ	ウォッチリストの名前とエイリアスは 3 文字から 64 文字にする必要があります。 最初と最後の文字は英数字である必要があります。その間にはスペース、ハイフン、アンダースコアを使用できます。
使用目的	参照データにのみウォッチリストを使用します。 ウォッチリストは、大きなデータ ボリューム用に設計されていません。
アクティブなウォッチリストアイテムの最大数	ワークスペース内のすべてのウォッチリストで、最大 1,000 万個のアクティブなウォッチリスト アイテムを使用できます。 削除されたアイテムはカウントされません。 ボリュームが大きい場合は、 カスタム ログを使用します。
データ保存期間	Log Analytics Watchlist テーブルのデータは、28 日間保持されます。
更新間隔	ウォッチリストは 12 日ごとに更新され、 TimeGenerated フィールドが更新されます。
ワークスペース間管理	Azure Lighthouse を使用したワークスペース間でのウォッチリストの管理はサポートされていません。
ローカル ファイルのアップロード サイズ	ローカル ファイルのアップロードは、最大 3.8 MB のファイルに制限されます。
Azure ストレージ ファイルのアップロード サイズ (プレビュー)	Azureストレージのアップロードは、最大 500 MB のファイルに制限されます。
列とテーブルの制限	ウォッチリストは、列と名前の Kusto クエリ言語 (KQL) エンティティの名前付け制限に 従う必要があります。

Microsoft Sentinel でのウォッチリストの作成方法

Microsoft Sentinelでウォッチリストを作成するには、次のいずれかの方法を使用します。

• ローカル フォルダーまたはAzure Storage アカウントからファイルをアップロードします。
• Microsoft Sentinelからウォッチリスト テンプレートをダウンロードし、データを追加して、ファイルをアップロードします。

大きなファイル (最大 500 MB) からウォッチリストを作成するには、ファイルを Azure ストレージ アカウントにアップロードします。 Microsoft Sentinel がウォッチリスト データを取得できるように、共有アクセス署名 (SAS) URL を作成します。 SAS URL には、リソース URI とリソースの SAS トークン (ストレージ アカウント内の CSV ファイルなど) の両方が含まれます。 Microsoft Sentinelでウォッチリストをワークスペースに追加します。

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

• Microsoft Sentinelでウォッチリストを作成する
• 組み込みのウォッチリスト スキーマ
• Azure Storage SAS トークン

検索および検出ルール向けクエリ内のウォッチリスト

ウォッチリスト データを他のMicrosoft Sentinelデータと関連付けるために、joinやlookupなどの Kusto 表形式演算子をWatchlistテーブルに使用します。 Microsoft Sentinelには、ウォッチリストのクエリに役立つ次の組み込み関数が用意されています。

• _GetWatchlistAlias - すべてのウォッチリストのエイリアスを返します
• _GetWatchlist - 指定したウォッチリストの名前と値のペアを照会します

ウォッチリストを作成するときは、 SearchKey を定義します。 検索キーは、ウォッチリスト内の列の名前で、他のデータとの結合または頻繁な検索オブジェクトとして使用すると想定されます。 たとえば、国/地域名とそれぞれの 2 文字の国コードを含むサーバー ウォッチリストがあるとします。 多くの場合、検索や結合に国コードを使用することが想定されています。 そのため、検索キーとして国コード列を使用します。

Heartbeat
| lookup kind=leftouter _GetWatchlist('mywatchlist') 
  on $left.RemoteIPCountry == $right.SearchKey

他のいくつかのクエリ例を見てみましょう。

分析ルールでウォッチリストを使用するとします。 ipwatchlistとIPAddressの列を含むLocationというウォッチリストを作成します。 IPAddress を SearchKey として設定します。

IPAddress,Location
10.0.100.11,Home
172.16.107.23,Work
10.0.150.39,Home
172.20.32.117,Work

ウォッチリストに IP アドレスからのイベントのみを含めるために、 watchlist を変数またはインラインとして使用するクエリを使用できます。

次のクエリ例では、ウォッチリストを変数として使用します。

  //Watchlist as a variable
  let watchlist = (_GetWatchlist('ipwatchlist') | project IPAddress);
  Heartbeat
  | where ComputerIP in (watchlist)

次のクエリ例では、クエリとウォッチリストに対して定義された検索キーを使用して、ウォッチリストをインラインで使用します。

  //Watchlist inline with the query
  //Use SearchKey for the best performance
  Heartbeat
  | where ComputerIP in ( 
      (_GetWatchlist('ipwatchlist')
      | project SearchKey)
  )

ウォッチリストを使用したクエリと検出ルールの構築の詳細については、「Microsoft Sentinelでのウォッチリストを使用したクエリと検出ルールの構築」を参照してください。Kusto の演算子とステートメントについては、次の記事を参照してください。

• where 演算子
• project 演算子
• lookup 演算子
• in 演算子
• let ステートメント

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

その他のリソース：

• KQL クイック リファレンス
• Kusto クエリ言語の学習リソース

インシデントおよびクエリの問題時のウォッチリストのトラブルシューティング

ポータルまたは API の可用性に関する問題のトラブルシューティング

ウォッチリスト ページが空白、繰り返し更新、またはウォッチリスト操作によって502 Bad Gatewayまたはその他の5XX応答が返される場合は、ウォッチリストの構成を変更する前に、まず問題がサービス側である可能性があるかどうかを判断します。

次のチェックを使用します。

• 問題がすべてのウォッチリストまたは複数のウォッチリストに影響するかどうかを確認します。

• 問題が複数のユーザーに影響するかどうかを確認します。

• 問題がAzure ポータルと自動化または API ベースの操作の両方に影響するかどうかを確認します。

• ウォッチリスト データがログから引き続きクエリ可能かどうかを検証します。

  _GetWatchlistAlias
  

  ウォッチリストのエイリアスがわかっている場合は、次のテストも行います。

  _GetWatchlist('watchlist-alias')
  | take 10
  

• Microsoft Sentinel関連の影響については、Azure Service Healthとアクティブなインシデント通信を確認します。

• インシデントがアクティブな間は、削除と再作成の試行を繰り返さないようにします。 ポータルまたは API の障害は、ウォッチリストのデータ損失を必ずしも示すわけではありません。

• ユーザーまたはワークスペース全体で 502 またはその他の 5XX エラーを返す空のポータルまたはウォッチリストの作成、読み取り、更新、削除 (CRUD) 操作は、より広範なプラットフォームへの影響を排除するまで、潜在的なサービス インシデントとして扱います。

• ウォッチリスト操作を呼び出す Logic Apps ワークフローが502 Bad Gatewayまたは同様の一時的なエラーを返し始める場合は、問題がコネクタのアクセス許可またはワークフローの構成によって引き起こされていると想定する前に、サービスの正常性Microsoft Sentinel検証します。 自動化エラーは、ワークフロー ID と構成が変更されていない場合でも、ウォッチリスト サービス インシデント中に一般的なアクセスまたはゲートウェイ エラーとして発生する可能性があります。

サービス インシデントの間、最も安全な最初の検証は、ウォッチリストがまだクエリ可能かどうかを確認することです。 クエリ アクセスも失敗した場合は、サポート要求を開く前に、タイムスタンプ、操作、および HTTP 状態コードをキャプチャします。

保持と更新の動作を理解する

28 日間のリテンション期間の値は、ウォッチリストが 28 日後に使用できなくなるという意味ではありません。

ウォッチリストは、削除するまで使用できます。 保有期間の値は、基になるLog Analyticsウォッチリスト テーブルのレコードに適用されますが、ウォッチリスト サービスは定期的にウォッチリスト データを更新します。 ウォッチリストは定期的に更新されるため、削除しない限り、または別の問題が可用性に影響を与えない限り、時間の経過と同時にクエリ可能なままになります。

この区別は、長期的な分析を計画する場合や、ウォッチリストがクエリ結果に表示されるかどうかを検証する場合に重要です。

作成後に 0 行が表示されるウォッチリストのトラブルシューティング

ウォッチリストが正常に作成されたが、ポータルまたは _GetWatchlist() が行を返さない場合は、トラブルシューティングの一環としてワークスペースインジェストの制約を確認します。

• ウォッチリストが予想されるワークスペースに作成されたことを確認します。

• エイリアスでウォッチリストにクエリを実行します。

  _GetWatchlist('watchlist-alias')
  | take 10
  

• Log Analytics ワークスペースの構成で、日次上限を含むインジェスト制限を確認します。

• ワークスペースが日次上限に達した場合は、インジェストを再開し、ウォッチリストをもう一度検証します。

0 行の結果は、ウォッチリスト定義が見つからないことを常に示すとは限りません。 インジェスト関連のワークスペースの制限は、ウォッチリスト データがワークスペースに表示されるタイミングに影響する可能性があります。

管理プレーンとクエリ動作の相違のトラブルシューティング

クエリ アクセスと管理アクセスは、一時的なサービスの問題中に動作が異なる場合があります。

場合によっては、ポータルのエクスペリエンス、編集操作、またはその他の管理プレーン アクションが一時的に使用できない場合でも、 _GetWatchlistAlias または _GetWatchlist() でウォッチリストに対してクエリを実行できます。 クエリ結果が返されてもポータルが空白の場合、またはウォッチリストの更新が失敗した場合は、ウォッチリストが削除されたかスキーマが変更されたと想定する前にサービスの正常性を検証してください。

KQL クエリが成功すると、管理エクスペリエンスが低下した場合でも、ウォッチリスト データがワークスペースで引き続き使用できる可能性があることを示します。

空または部分的なクエリ結果のトラブルシューティング

重要

ウォッチリスト クエリの結果は、クエリの時間範囲と、周囲のクエリに適用されるフィルターの影響を受ける可能性があります。

ウォッチリストは定期的な間隔で更新され、クエリ関数は基になるウォッチリスト データから現在のウォッチリストの状態を返します。 トラブルシューティング中に、グローバルな日時範囲を狭く設定したり、その他の制限の厳しいフィルターを適用したりすると、クエリによって、想定されるウォッチリストの内容を返すために必要なレコードが除外される可能性があります。 その場合、ウォッチリストがまだ存在していても、 _GetWatchlist() は空または部分的な結果を返すように見える可能性があります。

予期しない空の結果が返される場合のトラブルシューティング:

• 正しいウォッチリストエイリアスに対してクエリを実行していることを確認します。
• クエリ レベルの時間スコープを削除または拡大します。
• クエリを再実行し、結果を比較します。

クエリ レベルの datetime スコープに依存するシナリオでは、ウォッチリストの更新サイクルを含めるのに十分な範囲の時間範囲を使用します。

関連コンテンツ

• Microsoft Sentinelでウォッチリストを作成する
• Microsoft Sentinel でウォッチリストを管理する