Microsoft Sentinel サービスで包括的で中断なく改ざんのない脅威検出を実現するには、分析ルールの正常性と整合性を追跡します。 分析ルールの実行に関する分析情報を監視し、正常性ログと監査ログに対してクエリを実行し、手動再実行を使用して分析ルールをテストおよび最適化することで、それらを最適に機能させ続けます。
関連する利害関係者に対して正常性イベントと監査イベントの通知を設定し、アクションを実行できます。 たとえば、メールやMicrosoft Teamsメッセージを定義して送信したり、チケット作成システムで新しいチケットを作成したりします。
この記事では、Microsoft SentinelでMicrosoft Sentinelの監査と正常性の監視を使用して、分析ルールの正常性と整合性をMicrosoft Sentinel内から追跡する方法について説明します。
ルールの分析情報とルールの手動再実行の詳細については、「 スケジュールされた分析ルールの実行を監視して最適化する」を参照してください。
まとめ
Microsoft Sentinelには、正常性ログと監査ログという 2 種類の分析ルールを監視するためのログが用意されています。 次のセクションでは、各ログがキャプチャする内容と、データが格納される場所について説明します。
Microsoft Sentinel の分析ルール正常性ログ:
- このログは、分析ルールの実行と、これらの実行の最終的な結果を記録するイベント (成功または失敗した場合、失敗した場合は理由) をキャプチャします。
- ログには、分析ルールの実行ごとにも記録されます。
- ルールのクエリでキャプチャされたイベントの数。
- イベントの数がルールで定義されたしきい値を超えたかどうか。ルールがアラートを発生させます。
これらのログは、Log Analytics の SentinelHealth テーブルで収集されます。
Microsoft Sentinel の分析ルール監査ログ:
- このログは、次の詳細を含む、分析ルールに加えられた変更を記録するイベントをキャプチャします。
- 変更されたルールの名前。
- 変更されたルールのプロパティ。
- 変更前後のルール設定の状態。
- 変更を加えたユーザーまたは ID。
- 変更のソース IP と日付/時刻。
- ...などです。
これらのログは、Log Analytics の SentinelAudit テーブルに収集されます。
- このログは、次の詳細を含む、分析ルールに加えられた変更を記録するイベントをキャプチャします。
SentinelHealth および 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"
開始に役立つサンプル クエリを次に示します。
"自動無効のスケジュールされた分析ルール" であるルールを検索します。
_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, ReasonSentinelAudit テーブルでルール削除アクティビティを検索します。 このクエリでは、分析ルールが削除された監査レコードが返されるため、ルールを削除したユーザーと次のタイミングを追跡できます。
_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 演算子と関数の詳細については、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 クエリ言語 の Kusto クエリ言語の概要 と Kusto クエリ言語のベスト プラクティス に関するドキュメントを参照してください。 クエリによって呼び出された関数が見つかりませんでした。 クエリによって呼び出されたすべての関数のワークスペースに存在することを確認します。 クエリで使用されているワークスペースが見つかりませんでした。 クエリ内のすべてのワークスペースが存在することを確認します。 このクエリを実行するためのアクセス許可がありません。 (設定を変更せずに) 編集して保存することで、分析ルールをリセットしてみてください。 クエリ内の 1 つ以上のリソースに対するアクセス許可がありません。 クエリは、見つからなかったストレージ パスを参照しました。 クエリがストレージ パスへのアクセスを拒否されました。 このワークスペースには、同じ名前の複数の関数が定義されています。 冗長関数を削除または名前変更し、ルールを編集して保存してリセットします。 このクエリは結果を返しませんでした。 このクエリの複数の結果セットは許可されません。 クエリ結果には、1 行あたりのフィールド数に一貫性がありません。 データ インジェスト時間が長いため、ルールの実行が遅延しました。 一時的な問題により、ルールの実行が遅延しました。 アラートは一時的な問題のために強化されませんでした。 エンティティのマッピングの問題により、アラートに追加情報を付与できませんでした。 < number> 件のエンティティは、32 KB のアラート サイズ制限により、アラート <name> から除外されました。 < number>件のエンティティが、エンティティ マッピングの問題により、アラート<name>から除外されました。 クエリの結果、<number> 件のイベントとなり、行ごとにアラートを生成するイベント グループ化構成の <ルールの種類> ルールで許可される結果の最大数 <limit> を超えています。 最初の<limit-1>イベントに対して行ごとのアラートが生成され、すべてのイベントを考慮して追加の集計アラートが生成されました。
- <number> = クエリによって返されるイベントの数
- <limit> = 現在、スケジュールされたルールのアラートは 150、NRT ルールの場合は 30
- <ルールの種類> = Scheduled または NRT
監査と正常性監視のワークブックを使用する
分析ルールの正常性と監査データを視覚化するには、Microsoft Sentinel コンテンツ ハブから Analytics Health & Audit ブックをインストールして構成します。
ワークスペースでブックを使用できるようにするには、Microsoft Sentinel コンテンツ ハブからブック ソリューションをインストールします。
Microsoft Sentinel ポータルで、[コンテンツ管理] メニューから [コンテンツ ハブ (プレビュー)] を選択します。
コンテンツ ハブで、検索バーに「health」と入力し、結果の [スタンドアロン] の [ブック] ソリューションの中から [Analytics Health & Audit] を選択します。
詳細ウィンドウから [ インストール ] を選択し、その場所に表示される [保存 ] を選択します。
ソリューションがインストール済みと表示されたら、脅威管理 メニューから ワークブック を選択します。
Workbooks ギャラリーで、Templates タブを選択し、検索バーに health と入力して、検索結果から Analytics Health & Audit を選択します。
ブックの編集可能で使用可能なコピーを作成するには、詳細ウィンドウで [保存] を 選択します。 コピーが作成されたら、[保存済みのブックを表示] を選択します。
ブックに入ったら、最初に表示する サブスクリプション と ワークスペース を選択し (既に選択されている可能性があります)、必要に応じてデータをフィルター処理する TimeRange を定義します。 ヘルプの表示 切り替えを使用して、ワークブック内にその場で説明を表示します。
このブックには、次の 3 つのタブ付きセクションがあります。
[概要] タブで正常性と監査の概要を確認する
[ 概要 ] タブには、正常性と監査の概要が表示されます。
- 選択したワークスペースでの分析ルールの実行状態の正常性の概要:実行の数、成功と失敗、失敗イベントの詳細。
- 選択したワークスペースの分析ルールに関するアクティビティの概要を監査します。時間の経過に伴うアクティビティの数、種類別のアクティビティの数、ルールごとに異なる種類のアクティビティの数。
[正常性] タブを使用して、分析ルールの問題を特定する
[ 正常性 ] タブでは、特定の正常性イベントを調べることができます。
- 状態 (成功または失敗) とルールの種類 (スケジュールまたは NRT) でページ全体のデータをフィルター処理します。
- 選択した期間における (状態フィルターに応じて) 成功したルールと失敗したルールの実行の傾向を確認します。 トレンド グラフを "タイム ブラシ" して、元の時間範囲のサブセットを表示できます。
- ページの残りの部分を 理由でフィルター処理します。
- すべての分析ルールの実行の合計数を確認します。これは、円グラフの状態に比例して表示されます。
- 次に、実行された一意の分析ルールの数を示す表を示します。ルールの種類と状態によって分類されます。
- 状態を選択して、その状態の残りのグラフをフィルター処理します。
- グラフの右上隅にある [選択を解除] アイコン ([元に戻す] アイコンのように表示されます) を選択して、フィルターをクリアします。
- 各状態を確認し、その状態の考えられる理由の数を確認します。 (選択した時間枠の実行で表される理由のみが表示されます)。
- 状態を選択して、その状態の残りのグラフをフィルター処理します。
- グラフの右上隅にある [選択を解除] アイコン ([元に戻す] アイコンのように表示されます) を選択して、フィルターをクリアします。
- 次に、これらの理由の一覧を参照し、合計ルール実行数と実行された一意のルールの数を組み合わせて確認します。
- その理由で、次のグラフをフィルター処理する理由を選択します。
- グラフの右上隅にある [選択を解除] アイコン ([元に戻す] アイコンのように表示されます) を選択して、フィルターをクリアします。
- その後、実行された一意の分析ルールの一覧で、成功と失敗の最新の結果と近似曲線が表示されます (一覧をフィルター処理するために選択された状態に応じて)。
- ドリルダウンするルールを選択し、(選択した時間枠内で) そのルールのすべての実行を含む新しいテーブルを表示します。
- グラフの右上隅にある [選択を解除] アイコン ([元に戻す] アイコンのように表示されます) を選択して、そのテーブルをクリアします。
- 一覧でルールを選択すると、選択したルールの正常性の詳細を含む新しいテーブルが表示されます。
[監査] タブを使用して分析ルールの変更を確認する
[ 監査 ] タブでは、特定の監査イベントにドリルダウンできます。
- ページ全体データを 監査ルールタイプ (スケジュール型またはFusion型、多段階攻撃を検出する相関型ルール)でフィルタリングします。
- 選択した期間の分析ルールに対する監査アクティビティの傾向を確認します。 トレンド グラフを "タイム ブラシ" して、元の時間範囲のサブセットを表示できます。
-
アクティビティとルールの種類別に分類された、監査されたイベントの数を確認します。
- アクティビティを選択して、そのアクティビティの次のグラフをフィルター処理します。
- グラフの右上隅にある [選択を解除] アイコン ([元に戻す] アイコンのように表示されます) を選択して、フィルターをクリアします。
-
ルール名で監査されたイベントの数を確認します。
- ルール名を選択すると、そのルールに対して次のテーブルがフィルター処理され、そのルールのすべてのアクティビティを含む新しいテーブルがドリルダウンされて表示されます (選択した時間枠内)。 (次のスクリーンショットの後を参照してください)。
- グラフの右上隅にある [選択を解除] アイコン ([元に戻す] アイコンのように表示されます) を選択して、フィルターをクリアします。
- 呼び出し元 (アクティビティを実行した ID) によって監査されたイベントの数を確認します。
- 前のグラフでルール名を選択した場合は、そのルールに対する監査済み アクティビティ を示す別のテーブルが表示されます。 ExtendedProperties 列にリンクとして表示される値を選択して、ルールに加えられた変更を表示するサイド パネルを開きます。
関連するコンテンツ
- Microsoft Sentinelで分析ルールの実行を監視および最適化します。
- Microsoft Sentinelでの監査と正常性の監視について説明します。
- Microsoft Sentinel で監査と正常性監視を有効化します
- オートメーション ルールとプレイブックの正常性を監視します。
- データ コネクタの正常性を監視します。
- SentinelHealth テーブル スキーマと SentinelAudit テーブル スキーマの詳細を参照してください。