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>) に達しませんでした。失敗: これらの説明では、ルールの失敗と、それらに対して実行できる操作について説明します。
説明 Remediation クエリの実行中に内部サーバー エラーが発生しました。 クエリの実行がタイムアウトしました。 クエリで参照されているテーブルが見つかりませんでした。 関連するデータ ソースが接続されていることを確認します。 クエリの実行中にセマンティック エラーが発生しました。 分析ルールを編集して保存し (設定を変更せずに) リセットしてみます。 クエリによって呼び出される関数の名前で、予約語が使われています。 関数を削除するか、名前を変更します。 クエリの実行中に構文エラーが発生しました。 分析ルールを編集して保存し (設定を変更せずに) リセットしてみます。 ワークスペースが存在しません。 このクエリでは、使用するシステム リソースが多すぎて実行されませんでした。 分析ルールを確認して調整します。 Kusto 照会言語の概要とベスト プラクティスに関するドキュメントを参照してください。 クエリによって呼び出された関数が見つかりませんでした。 クエリで呼び出されているすべての関数がワークスペース内に存在することを確認します。 クエリで使用されているワークスペースが見つかりませんでした。 クエリ内のすべてのワークスペースが存在することを確認します。 このクエリを実行するためのアクセス許可がありません。 分析ルールを編集して保存し (設定を変更せずに) リセットしてみます。 クエリ内の 1 つ以上のリソースに対するアクセス許可がありません。 クエリは、見つからなかったストレージ パスを参照しました。 クエリによるストレージ パスへのアクセスを拒否されました。 このワークスペースでは、同じ名前で複数の関数が定義されています。 冗長な関数を削除するか、名前を変更し、ルールを編集および保存してリセットします。 このクエリは結果を返しませんでした。 このクエリの複数の結果セットは許可されません。 クエリの結果に含まれる行ごとのフィールド数が一致しません。 データ インジェストの時間が長いため、ルールの実行が遅れました。 一時的な問題のため、ルールの実行が遅れました。 アラートは一時的な問題のために強化されませんでした。 エンティティ マッピングの問題により、アラートがエンリッチされませんでした。 < 32 KB のアラート サイズ制限により、アラート <name> で number> 個のエンティティが削除されました。 < エンティティ マッピングの問題のため、アラート <name> で number> 個のエンティティが削除されました。 クエリの結果のイベント数が <number> 個になりました。これは、行ごとのアラートのイベント グループ化構成で <rule type> ルールに対して許可されている結果の数の上限 <limit> を超えています。 最初の <limit-1> イベントに対しては行ごとのアラートが生成され、すべてのイベントに対する追加の集計アラートが生成されました。
- <number> = クエリによって返されたイベントの数
- <limit> = 現在、スケジュールされたルールの場合は 150 アラート、NRT ルールの場合は 30
- <rule type> = スケジュール済みまたは NRT
監査と正常性の監視ブックを使用する
ワークスペースでブックを使用できるようにするには、Microsoft Sentinel コンテンツ ハブからブック ソリューションをインストールします。
Microsoft Sentinel ポータルで、[コンテンツ管理] メニューの [コンテンツ ハブ (プレビュー)] を選択します。
[コンテンツ ハブ] の検索バーに「health」と入力し、結果の [スタンドアロン] の下にある [ブック] ソリューションの中から [分析の正常性と監査] を選択します。
詳細ペインで [インストール] を選択し、その場所に表示される [保存] を選択します。
ソリューションがインストールされたことが示されたら、[脅威管理] メニューの [ブック] を選択します。
[ブック] ギャラリーで、[テンプレート] タブを選択し、検索バーに「health」と入力して、結果の中から [分析の正常性と監査] を選択します。
詳細ペインで [保存] を 選択して、ブックの編集可能かつ使用可能なコピーを作成します。 コピーが作成されたら、[保存されたブックの表示] を選択します。
ブックに入ったら、最初に表示する サブスクリプション と ワークスペース を選択し (既に選択されている可能性があります)、必要に応じてデータをフィルター処理する TimeRange を定義します。 [ヘルプの表示] トグルを使用すると、ブックの組み込みの説明が表示されます。
![分析ルールの正常性ブックの [概要] タブのスクリーンショット。](media/monitor-analytics-rule-integrity/analytics-health-workbook-overview.png)
このブックには、次の 3 つのタブ付きセクションがあります。
[概要] タブ
[概要] タブに、正常性と監査の概要が表示されます。
- 選択したワークスペースでの分析ルールの実行状態の正常性の概要: 実行の数、成功と失敗、失敗イベントの詳細。
- 選択したワークスペースの分析ルールに関するアクティビティの監査の概要: 時間の経過にともなうアクティビティの数、種類別のアクティビティの数、ルール別の異なる種類のアクティビティの数。
[正常性] タブ
[ 正常性 ] タブでは、特定の正常性イベントを調べることができます。
![分析の正常性ブックの [正常性] タブの選択のスクリーンショット。](media/monitor-analytics-rule-integrity/analytics-health-workbook-health-tab.png)
- 状態 (成功または失敗) とルールの種類 (スケジュール済みまたは NRT) でページ 全体のデータをフィルター処理します。
- 選択した期間における (状態フィルターに応じて) 成功したルールと失敗したルールの実行の傾向を確認します。 傾向グラフに "タイム ブラシ" を実行して、元の時間範囲のサブセットを表示できます。
- ページの残りの部分を理由でフィルター処理します。
- すべての分析ルールの実行の合計数を表示します。状態に比例して円グラフで表示されます。
- その次に、実行された一意の分析ルールの数を、ルールの種類と状態別に分類して示す表があります。
- 状態を選択して、その状態の残りのグラフをフィルター処理します。
- グラフの右上隅にある "選択のクリア" アイコン ("元に戻す" アイコンに似ています) を選択してフィルターをクリアします。
- 各状態を、その状態の考えられる理由の数とともに確認します。 (選択した時間枠内の実行で表される理由のみが表示されます)。
- 状態を選択して、その状態の残りのグラフをフィルター処理します。
- グラフの右上隅にある "選択のクリア" アイコン ("元に戻す" アイコンに似ています) を選択してフィルターをクリアします。
- 次に、ルールの実行を結合した合計数と実行された一意のルールの数を含む、これらの理由の一覧を確認します。
- 理由を選択して、その理由で次のグラフをフィルター処理します。
- グラフの右上隅にある "選択のクリア" アイコン ("元に戻す" アイコンに似ています) を選択してフィルターをクリアします。
- その後、実行された一意の分析ルールの一覧が表示され、最新の結果と成功と失敗の近似曲線が表示されます (一覧をフィルター処理するために選択された状態に応じて)。
- ルールを選択してドリルダウンし、そのルールの (選択した時間枠内の) すべての実行を含む新しい表を表示します。
- グラフの右上隅にある "選択のクリア" アイコン ("元に戻す" アイコンに似ています) を選択してその表をクリアします。
- 一覧でルールを選択すると、選択したルールの正常性の詳細を含む新しいテーブルが表示されます。
[監査] タブ
[監査] タブで、特定の監査イベントにドリルダウンできます。
![分析の正常性ブックの [監査] タブの選択のスクリーンショット。](media/monitor-analytics-rule-integrity/analytics-health-workbook-audit-tab.png)
- AuditRuleType (スケジュール設定/Fusion) でページ全体のデータをフィルター処理します。
- 選択した期間の分析ルールに対する監査アクティビティの傾向を確認します。 傾向グラフに "タイム ブラシ" を実行して、元の時間範囲のサブセットを表示できます。
- 監査されたイベントの数を、アクティビティとルールの種類別に分類して確認します。
- アクティビティを選択して、そのアクティビティで次のグラフをフィルター処理します。
- グラフの右上隅にある "選択のクリア" アイコン ("元に戻す" アイコンに似ています) を選択してフィルターをクリアします。
-
ルール名別に監査されたイベントの数を確認します。
- ルール名を選択して、そのルールで次の表をフィルター処理し、そのルールの (選択した時間枠内の) すべてのアクティビティを含む新しい表をドリルダウンして表示します。 次のスクリーンショットの後をご覧ください。
- グラフの右上隅にある "選択のクリア" アイコン ("元に戻す" アイコンに似ています) を選択してフィルターをクリアします。
- 呼び出し元 (アクティビティを実行した ID) 別の監査されたイベントの数を確認します。
- 前のグラフでルール名を選択した場合は、そのルールの監査済み アクティビティ を示す別のテーブルが表示されます。 [ExtendedProperties] 列にリンクとして表示される値を選択して、ルールに加えられた変更を表示するサイド パネルを開きます。
次のステップ
- Microsoft Sentinel で分析ルールの実行を監視および最適化します。
- Microsoft Sentinel での監査と稼働状況の監視について確認します。
- Microsoft Sentinel で監査と稼働状況の監視を有効にします。
- オートメーション ルールとプレイブックの正常性を監視します。
- データ コネクタの正常性を監視します。
- SentinelHealth と SentinelAudit テーブル スキーマの詳細を確認します。