正常性を監視し、分析ルールの整合性を監査する

Microsoft Sentinel サービスで包括的で中断なく改ざんのない脅威検出を実現するには、分析ルールの正常性と整合性を追跡します。実行分析情報を監視し、正常性ログと監査ログに対してクエリを実行し、手動再実行を使用してルールをテストおよび最適化することで、それらを最適に機能させ続けます。

関連する利害関係者に対して正常性イベントと監査イベントの通知を設定し、アクションを実行できます。たとえば、メールやMicrosoft Teamsメッセージを定義して送信したり、チケット作成システムで新しいチケットを作成したりします。

この記事では、Microsoft Sentinelの監査と正常性の監視機能を使用して、分析ルールの正常性と整合性をMicrosoft Sentinel内から追跡する方法について説明します。

ルールの分析情報とルールの手動再実行の詳細については、「スケジュールされた分析ルールの実行を監視して最適化する」を参照してください。

まとめ

分析ルールの正常性ログをMicrosoft Sentinelします。
- このログは、分析ルールの実行と、これらの実行の最終的な結果を記録するイベント (成功または失敗した場合、失敗した場合は理由) をキャプチャします。
- ログには、分析ルールの実行ごとにも記録されます。
  - ルールのクエリでキャプチャされたイベントの数。
  - イベントの数がルールで定義されたしきい値を超えたかどうか。ルールがアラートを発生させます。
これらのログは、Log Analytics の SentinelHealth テーブルで収集されます。
分析ルール監査ログをMicrosoft Sentinelします。
- このログは、次の詳細を含む、分析ルールに加えられた変更を記録するイベントをキャプチャします。
  - 変更されたルールの名前。
  - 変更されたルールのプロパティ。
  - 変更前後のルール設定の状態。
  - 変更を加えたユーザーまたは ID。
  - 変更のソース IP と日付/時刻。
  - ...などです。
これらのログは、Log Analytics の SentinelAudit テーブルに収集されます。

SentinelHealth および SentinelAudit データテーブルを使用する

前に説明したテーブルから監査と正常性データを取得するには、まずワークスペースのMicrosoft Sentinel正常性機能を有効にする必要があります。詳細については、「Microsoft Sentinelの監査と正常性の監視を有効にする」を参照してください。

正常性機能が有効になると、自動化ルールとプレイブックに対して生成された最初の成功または失敗イベントで SentinelHealth データテーブルが作成されます。

SentinelHealth および SentinelAudit テーブルイベントについて

SentinelHealth テーブルでは、次の種類の分析ルール正常性イベントがログに記録されます。

スケジュールされた分析ルールの実行。
NRT 分析ルールを実行します。

詳細については、「 SentinelHealth テーブル列スキーマ」を参照してください。

SentinelAudit テーブルは、次の種類の分析ルール監査イベントをログに記録します。

分析ルールを作成または更新します。
分析ルールが削除されました。

詳細については、「 SentinelAudit テーブル列スキーマ」を参照してください。

正常性と整合性の問題を検出するクエリを実行する

最適な結果を得るには、テーブルを直接クエリするのではなく、これらのテーブルの 事前構築済み関数(_SentinelHealth() と _SentinelAudit()) に対してクエリを作成します。これらの関数は、テーブルのスキーマに変更が加えられた場合、クエリの下位互換性を維持します。

最初の手順として、分析ルールに関連するデータのテーブルをフィルター処理します。 SentinelResourceType パラメーターを使用します。

_SentinelHealth()
| where SentinelResourceType == "Analytics Rule"

必要に応じて、特定の種類の分析ルールのリストをさらにフィルター処理できます。このために SentinelResourceKind パラメーターを使用します。

| where SentinelResourceKind == "Scheduled"

# OR

| where SentinelResourceKind == "NRT"

開始に役立つサンプルクエリを次に示します。

"autodisabled" であるルールを検索します。

_SentinelHealth()
| where SentinelResourceType == "Analytics Rule"
| where Reason == "The analytics rule is disabled and was not executed."

成功または失敗したルールと実行を理由でカウントします。

_SentinelHealth()
| where SentinelResourceType == "Analytics Rule"
| summarize Occurrence=count(), Unique_rule=dcount(SentinelResourceId) by Status, Reason

ルール削除アクティビティの検索:

_SentinelAudit()
| where SentinelResourceType =="Analytic Rule"
| where Description =="Analytics rule deleted"

ルールのアクティビティを、ルール名とアクティビティ名で検索します。

_SentinelAudit()
| where SentinelResourceType =="Analytic Rule"
| summarize Count= count() by RuleName=SentinelResourceName, Activity=Description

ルールのアクティビティを呼び出し元名 (アクティビティを実行した ID) で検索します。

_SentinelAudit()
| where SentinelResourceType =="Analytic Rule"
| extend Caller= tostring(ExtendedProperties.CallerName)
| summarize Count = count() by Caller, Activity=Description

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

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

その他のリソース：

スケジュールされたルール

スケジュールルールが失敗すると、まったく同じウィンドウでさらに 5 回再試行されます。 6 回の試行のいずれかが成功した場合、ルールはウィンドウをスキップせず、アラートを見逃しません。

6 回の試行の 1 回の失敗は、アラートトリガーの遅延を示します。次のクエリでは、正確な遅延が計算されます。

_SentinelHealth()
| where SentinelResourceType == @"Analytics Rule" 
| where SentinelResourceKind == "Scheduled"
| extend startTime = todatetime(ExtendedProperties["QueryStartTimeUTC"]), executionStart = todatetime(ExtendedProperties["executionStart"])
| extend delay = datetime_diff('minute', startTime, executionStart)

完全なエラー (つまり、スキップされたウィンドウ) を検索するには、次のクエリを使用します。

_SentinelHealth()| where SentinelResourceType == @"Analytics Rule" 
| where SentinelResourceKind == "Scheduled"
| where Status != "Success"
| extend startTime = tostring(ExtendedProperties["QueryStartTimeUTC"])
| summarize failuresByStartTime = count() by startTime, SentinelResourceId
| where failuresByStartTime == 6
| summarize count() by SentinelResourceId

このクエリでは、6 回の再試行が成功しなかったスケジュールされた分析ルールの実行を検索します。再試行は常に元の開始時刻を確認するため、ルールのウィンドウの開始時刻を調べることで再試行を識別できます。このクエリでは、分析ルールごとにスキップされたウィンドウの量が表示されます。スキップされたウィンドウはまれであると予想されます。ウィンドウがスキップされた分析ルールがある場合は、クエリを使用して、これらの特定のルールのエラー理由と、エラーの理由と軽減策の表を理解して修正します。

NRT ルール

NRT ルールの再試行メカニズムは、スケジュールされたルールとは異なる動作をします。ルールの実行に失敗した場合、システムは次の実行 (1 分後) に失敗したウィンドウも考慮します。この動作は、最大 60 エラー (1 時間) まで継続されます。

特定の実行の 1 つの失敗は 1 分の遅延のみを反映するため、単一のエラーを確認しないでください。代わりに、次のクエリを使用して、各分析ルールの遅延を監視します。

_SentinelHealth()
| where SentinelResourceKind == "NRT"
| extend startTime = todatetime(ExtendedProperties["QueryStartTimeUTC"]), endTime = todatetime(ExtendedProperties["QueryEndTimeUTC"]), alertsCreated = toint(ExtendedProperties["AlertsGeneratedAmount"])
| where alertsCreated == 0 
| extend ruleDelay = datetime_diff('minute', endTime, startTime)
| project TimeGenerated, ruleDelay, SentinelResourceId
| render timechart

分析ルールを定義して、重大な遅延に関するアラートをトリガーすることもできます (たとえば、NRT ルールの遅延が 10 分を超える場合など)。

状態、エラー、推奨される手順

[スケジュールされた分析ルールの実行] または [NRT 分析ルールの実行] には、次のいずれかの状態と説明が表示される場合があります。

成功: ルールが正常に実行され、 <n> アラートが生成されました。
成功: ルールは正常に実行されましたが、アラートの生成に必要なしきい値 (<n>) に達しませんでした。

失敗: これらの説明では、ルールの失敗と、それらに対して実行できる操作について説明します。

説明	修復
クエリの実行中に内部サーバーエラーが発生しました。
クエリの実行がタイムアウトしました。
クエリで参照されているテーブルが見つかりませんでした。	関連するデータソースが接続されていることを確認します。
クエリの実行中にセマンティックエラーが発生しました。	(設定を変更せずに) 編集して保存することで、分析ルールをリセットしてみてください。
クエリによって呼び出される関数の名前は、予約語で指定されます。	関数を削除または名前変更します。
クエリの実行中に構文エラーが発生しました。	(設定を変更せずに) 編集して保存することで、分析ルールをリセットしてみてください。
ワークスペースが存在しません。
このクエリでは、多くのシステムリソースが使用され、実行が禁止されました。	分析ルールを確認して調整します。 Kusto 照会言語の概要とベストプラクティスに関するドキュメントを参照してください。
クエリによって呼び出された関数が見つかりませんでした。	クエリによって呼び出されたすべての関数のワークスペースに存在することを確認します。
クエリで使用されているワークスペースが見つかりませんでした。	クエリ内のすべてのワークスペースが存在することを確認します。
このクエリを実行するためのアクセス許可がありません。	(設定を変更せずに) 編集して保存することで、分析ルールをリセットしてみてください。
クエリ内の 1 つ以上のリソースに対するアクセス許可がありません。
クエリは、見つからなかったストレージパスを参照しました。
クエリがストレージパスへのアクセスを拒否されました。
このワークスペースには、同じ名前の複数の関数が定義されています。	冗長関数を削除または名前変更し、ルールを編集して保存してリセットします。
このクエリは結果を返しませんでした。
このクエリの複数の結果セットは許可されません。
クエリ結果には、1 行あたりのフィールド数に一貫性がありません。
データインジェスト時間が長いため、ルールの実行が遅延しました。
一時的な問題により、ルールの実行が遅延しました。
アラートは一時的な問題のために強化されませんでした。
エンティティマッピングの問題により、アラートがエンリッチされませんでした。
< number>32 KB のアラートサイズ制限により>アラート <name にエンティティが削除されました。
< number>エンティティマッピングの問題により>アラート <name にエンティティが削除されました。
クエリの結果、 <number> イベントが発生し、 <limit> アラートごとのイベントグループ化構成 <ルール> ルールに対して許可される結果が最大になります。最初の<limit-1>イベントに対して行ごとのアラートが生成され、すべてのイベントを考慮して追加の集計アラートが生成されました。 - <number> = クエリによって返されるイベントの数 - <limit> = 現在、スケジュールされたルールのアラートは 150、NRT ルールの場合は 30 - <ルール型> = Scheduled または NRT

監査と正常性の監視ブックを使用する

ワークスペースでブックを使用できるようにするには、Microsoft Sentinel コンテンツハブからブックソリューションをインストールします。
1. Microsoft Sentinel ポータルで、[コンテンツ管理] メニューから [コンテンツハブ (プレビュー)] を選択します。
2. コンテンツハブで、検索バーに「health」と入力し、結果の [スタンドアロン] の [ブック] ソリューションの中から [Analytics Health & Audit] を選択します。
3. 詳細ウィンドウから [ インストール ] を選択し、その場所に表示される [保存 ] を選択します。
ソリューションがインストールされていることを示したら、[脅威の管理] メニューから [ブック] を選択します。
ブック ギャラリーで、[テンプレート] タブを選択し、検索バーに「health」と入力し、結果の中から [分析の正常性] & [監査] を選択します。
ブックの編集可能で使用可能なコピーを作成するには、詳細ウィンドウで [保存] を 選択します。コピーが作成されたら、[ 保存されたブックの表示] を選択します。
ブックに入ったら、最初に表示する サブスクリプション と ワークスペース を選択し (既に選択されている可能性があります)、必要に応じてデータをフィルター処理する TimeRange を定義します。 [ ヘルプの表示 ] トグルを使用して、ブックのインプレース説明を表示します。

このブックには、次の 3 つのタブ付きセクションがあります。

[概要] タブ

[ 概要 ] タブには、正常性と監査の概要が表示されます。

選択したワークスペースでの分析ルールの実行状態の正常性の概要:実行の数、成功と失敗、失敗イベントの詳細。
選択したワークスペースの分析ルールに関するアクティビティの概要を監査します。時間の経過に伴うアクティビティの数、種類別のアクティビティの数、ルールごとに異なる種類のアクティビティの数。

[正常性] タブ

[ 正常性 ] タブでは、特定の正常性イベントを調べることができます。

分析正常性ブックの [正常性] タブの選択のスクリーンショット。

状態 (成功または失敗) とルールの種類 (スケジュールまたは NRT) でページ全体のデータをフィルター処理します。
選択した期間における (状態フィルターに応じて) 成功したルールと失敗したルールの実行の傾向を確認します。トレンドグラフを "タイムブラシ" して、元の時間範囲のサブセットを表示できます。
ページの残りの部分を理由でフィルター処理します。
すべての分析ルールの実行の合計数を確認します。これは、円グラフの状態に比例して表示されます。
次に、実行された一意の分析ルールの数を示す表を示します。ルールの種類と状態によって分類されます。
- 状態を選択して、その状態の残りのグラフをフィルター処理します。
- グラフの右上隅にある [選択を解除] アイコン ([元に戻す] アイコンのように表示されます) を選択して、フィルターをクリアします。
各状態を確認し、その状態の考えられる理由の数を確認します。 (選択した時間枠の実行で表される理由のみが表示されます)。
- 状態を選択して、その状態の残りのグラフをフィルター処理します。
- グラフの右上隅にある [選択を解除] アイコン ([元に戻す] アイコンのように表示されます) を選択して、フィルターをクリアします。
次に、これらの理由の一覧を参照し、合計ルール実行数と実行された一意のルールの数を組み合わせて確認します。
- その理由で、次のグラフをフィルター処理する理由を選択します。
- グラフの右上隅にある [選択を解除] アイコン ([元に戻す] アイコンのように表示されます) を選択して、フィルターをクリアします。
その後、実行された一意の分析ルールの一覧で、成功と失敗の最新の結果と近似曲線が表示されます (一覧をフィルター処理するために選択された状態に応じて)。
- ドリルダウンするルールを選択し、(選択した時間枠内で) そのルールのすべての実行を含む新しいテーブルを表示します。
- グラフの右上隅にある [選択を解除] アイコン ([元に戻す] アイコンのように表示されます) を選択して、そのテーブルをクリアします。
一覧でルールを選択すると、選択したルールの正常性の詳細を含む新しいテーブルが表示されます。

[監査] タブ

[ 監査 ] タブでは、特定の監査イベントにドリルダウンできます。

分析正常性ブックの [監査] タブの選択のスクリーンショット。

監査ルールの種類 (scheduled/Fusion) でページ全体のデータをフィルター処理します。
選択した期間の分析ルールに対する監査アクティビティの傾向を確認します。トレンドグラフを "タイムブラシ" して、元の時間範囲のサブセットを表示できます。
アクティビティとルールの種類別に分類された、監査されたイベントの数を確認します。
- アクティビティを選択して、そのアクティビティの次のグラフをフィルター処理します。
- グラフの右上隅にある [選択を解除] アイコン ([元に戻す] アイコンのように表示されます) を選択して、フィルターをクリアします。
ルール名で監査されたイベントの数を確認します。
- ルール名を選択すると、そのルールに対して次のテーブルがフィルター処理され、そのルールのすべてのアクティビティを含む新しいテーブルがドリルダウンされて表示されます (選択した時間枠内)。 (次のスクリーンショットの後を参照してください)。
- グラフの右上隅にある [選択を解除] アイコン ([元に戻す] アイコンのように表示されます) を選択して、フィルターをクリアします。
呼び出し元 (アクティビティを実行した ID) によって監査されたイベントの数を確認します。
前のグラフでルール名を選択した場合は、そのルールに対する監査済み アクティビティ を示す別のテーブルが表示されます。 ExtendedProperties 列にリンクとして表示される値を選択して、ルールに加えられた変更を表示するサイドパネルを開きます。