最も一般的な種類の分析ルールでは、 スケジュールされた ルールは、一定の間隔で実行され、定義された "ルックバック" 期間の生データを調べるために構成された Kusto クエリ に基づいています。 クエリは、ターゲット データに対して複雑な統計操作を実行し、イベントのグループ内のベースラインと外れ値を明らかにすることができます。 クエリによってキャプチャされた結果の数がルールで構成されたしきい値を超えた場合、ルールによってアラートが生成されます。
この記事では、スケジュールされた分析ルールがどのように構築されているかを理解するのに役立ち、すべての構成オプションとその意味について説明します。 この記事の情報は、次の 2 つのシナリオで役立ちます。
テンプレートから分析ルールを作成する: テンプレート で定義されているクエリ ロジックとスケジュール設定とルックバック設定を使用するか、カスタマイズして新しいルールを作成します。
分析ルールをゼロから作成する: 最初から 独自のクエリとルールを構築します。 これを効果的に行うには、データ サイエンスと Kusto クエリ言語を徹底的に基礎にする必要があります。
重要
2027 年 3 月 31 日以降、Microsoft SentinelはAzure portalでサポートされなくなり、Microsoft Defender ポータルでのみ使用できるようになります。 Azure portalでMicrosoft Sentinelを使用しているすべてのお客様は、Defender ポータルにリダイレクトされ、Defender ポータルでのみMicrosoft Sentinelを使用します。
Azure portalでMicrosoft Sentinelを引き続き使用している場合は、スムーズな移行を確保し、Microsoft Defenderによって提供される統合セキュリティ操作エクスペリエンスを最大限に活用するために、Defender ポータルへの移行の計画を開始することをお勧めします。
分析ルール テンプレート
スケジュールされたルール テンプレートのクエリは、Microsoft またはテンプレートを提供するソリューションのベンダーから、セキュリティとデータ サイエンスの専門家によって記述されました。
分析ルール テンプレートを使用するには、テンプレートの一覧からテンプレート名を選択し、それに基づいてルールを作成します。
各テンプレートには、必要なデータ ソースの一覧があります。 テンプレートを開くと、データ ソースの可用性が自動的にチェックされます。 可用性とは、データ ソースが接続されていること、およびデータがデータを介して定期的に取り込まれていることを意味します。 必要なデータ ソースのいずれかが使用できない場合、ルールの作成は許可されず、その旨のエラー メッセージが表示される場合もあります。
テンプレートからルールを作成すると、選択したテンプレートに基づいてルール作成ウィザードが開きます。 すべての詳細が自動的に入力され、特定のニーズに合わせてロジックやその他のルール設定をカスタマイズできます。 このプロセスを繰り返して、テンプレートに基づいてさらにルールを作成できます。 ルール作成ウィザードが終了すると、カスタマイズが検証され、ルールが作成されます。 新しいルールは、[分析] ページの [アクティブなルール] タブに表示されます。 同様に、[ ルール テンプレート ] タブで、ルールを作成したテンプレートが In use タグと共に表示されるようになりました。
分析ルール テンプレートは、バグを修正したり、クエリを絞り込んだりするために、作成者によって常に管理されます。 テンプレートが更新を受け取ると、そのテンプレートに基づくすべてのルールが Update タグと共に表示され、テンプレートに加えられた変更を含むようにそれらのルールを変更できます。 ルールで行った変更を元のテンプレート ベースのバージョンに戻すこともできます。 詳細については、「Microsoft Sentinelでスケジュールされた分析ルールのテンプレート バージョンを管理する」を参照してください。
この記事の構成オプションについて理解したら、「 テンプレートからスケジュールされた分析ルールを作成する」を参照してください。
この記事の残りの部分では、ルールの構成をカスタマイズするためのすべての可能性について説明します。
分析ルールの構成
このセクションでは、ルールの構成を開始する前に考慮する必要がある主な考慮事項について説明します。
分析ルールの名前と詳細
分析ルール ウィザードの最初のページには、ルールの基本情報が含まれています。
名前： ルールの一覧およびルール ベースのフィルターに表示されるルールの名前。 名前はワークスペースに対して一意である必要があります。
説明： ルールの目的の自由テキストの説明。
Id：API の要求や応答などで使用される、Azure リソースとしてのルールの GUID。 この GUID は、ルールが作成されたときにのみ割り当てられるため、 既存のルールを編集している場合にのみ表示されます。 これは読み取り専用フィールドであるため、淡色表示され、変更できません。 テンプレートまたはゼロから新しいルールを作成する場合、まだ存在しません。
重大 度： このルールによって生成されたアラートを提供する評価。 アクティビティの重大度は、アクティビティの発生 による潜在的な 悪影響の計算です。
| 重大度 | 説明 |
|---|---|
| 情報 | システムへの影響はありませんが、情報は脅威アクターによって計画された将来の手順を示している可能性があります。 |
| 低 | 即時の影響は最小限に抑えられます。 脅威アクターは、環境への影響を達成する前に複数の手順を実行する必要がある可能性があります。 |
| Medium | 脅威アクターは、このアクティビティを使用して環境に何らかの影響を与える可能性がありますが、スコープが制限されるか、追加のアクティビティが必要になります。 |
| High | 特定されたアクティビティは、脅威アクターに、環境に対するアクションを実行するための幅広いアクセスを提供するか、環境への影響によってトリガーされます。 |
重大度レベルの既定値は、現在または環境への影響レベルを保証するものではありません。 アラートの詳細をカスタマイズ して、クエリ出力の関連フィールドの値を使用して、アラートの特定のインスタンスの重大度、戦術、およびその他のプロパティをカスタマイズします。
Microsoft Sentinel分析ルール テンプレートの重大度定義は、分析ルールによって作成されたアラートにのみ関連します。 他のサービスから取り込まれたアラートの場合、重大度はソース セキュリティ サービスによって定義されます。
MITRE ATT&CK: このルールによってキャプチャされたアクティビティによって表される攻撃戦術と手法の仕様。 これらは、 MITRE ATT&CK® フレームワークの戦術と手法に基づいています。
MITRE ATT&CK 戦術と規則でここで定義されている手法は、ルールによって生成されたすべてのアラートに適用されます。 また、これらのアラートから作成されたすべてのインシデントにも適用されます。
MITRE ATT&CK 脅威ランドスケープのカバレッジを最大化する方法の詳細については、「 MITRE ATT&CK® フレームワークによるセキュリティ カバレッジを理解する」を参照してください。
ステータス： ルールを作成すると、その 状態 は既定で 有効 になります。つまり、ルールの作成が完了した直後に実行されます。 すぐに実行しない場合は、次の 2 つのオプションがあります。
- [ 無効] を選択すると、ルールは実行されずに作成されます。 ルールを実行する場合は、[ アクティブなルール ] タブでルールを見つけて、そこから有効にします。
- 特定の日時に最初に実行するようにルールをスケジュールします。 このメソッドは現在プレビュー段階です。 この記事の後半の 「クエリ スケジュール 」を参照してください。
ルール クエリ
これがルールの本質です。このルールによって作成されたアラート内の情報と、情報の編成方法を決定します。 この構成は、結果として得られるインシデントの外観、および調査、修復、解決がいかに簡単であるか、または困難であるかに対する後続の影響を与えます。 可能な限り情報が豊富なアラートを作成し、その情報に簡単にアクセスできるようにすることが重要です。
生のログ データを分析する Kusto クエリを表示または入力します。 ルールを最初から作成する場合は、このウィザードを開く前にクエリを計画して設計することをお勧めします。 [ ログ] ページでクエリをビルドしてテストできます。
ルール クエリ ウィンドウに入力した内容はすべてすぐに検証されるため、間違いを犯すとすぐにわかります。
ネイティブ テーブルを使用するのではなく、クエリ ソースとして Advanced Security Information Model (ASIM) パーサー を使用することをお勧めします。 これにより、クエリは、1 つのデータ ソースに依存するのではなく、現在または将来の関連するデータ ソースまたはデータ ソースのファミリをサポートします。
クエリの長さは 1 ~ 10,000 文字にする必要があり、"
search *" または "union *" を含めることはできません。 1 つの関数で数十行のコードを置き換えることができるので、 ユーザー定義 関数を使用してクエリの長さの制限を克服できます。ADX 関数を使用して Log Analytics クエリ ウィンドウ内にAzure Data Explorerクエリを作成することはサポートされていません。
クエリ内で
bag_unpack関数を使用する場合、"" を使用して列をフィールドとしてproject field1し、列が存在しないと、クエリは失敗します。 この問題を防ぐには、次のように 列を投影する 必要があります。project field1 = column_ifexists("field1","")
詳細については、以下を参照してください:
アラートの強化
アラートの検出結果をインシデント内ですぐに確認できるようにし、適切に追跡および調査できるようにするには、アラート拡張構成を使用して、アラート内の重要な情報をすべて表示します。
このアラートの強化により、簡単に見やすくアクセス可能な方法で結果を表示できるという利点が追加されています。
構成できるアラート拡張機能には、次の 3 種類があります。
- エンティティ マッピング
- カスタムの詳細
- アラートの詳細 (動的コンテンツとも呼ばれます)
エンティティ マッピング
エンティティは、攻撃ストーリーの両側のプレイヤーです。 アラート内のすべてのエンティティを特定することは、脅威の検出と調査に不可欠です。 Microsoft Sentinelが生データ内のエンティティを識別できるようにするには、Microsoft Sentinelによって認識されるエンティティ型をクエリ結果のフィールドにマップする必要があります。 このマッピングは、識別されたエンティティをアラート スキーマの [エンティティ] フィールドに統合します。
エンティティマッピングの詳細と完全な手順については、「データ フィールドをMicrosoft Sentinelのエンティティにマップする」を参照してください。
カスタムの詳細
既定では、アラート エンティティとメタデータのみがインシデントに表示され、クエリ結果の生のイベントにドリルダウンされません。 クエリ結果の他のフィールドにアラートとインシデントをすぐに表示するには、 それらをカスタムの詳細として定義します。 Microsoft Sentinelでは、これらのカスタムの詳細がアラートの ExtendedProperties フィールドに統合され、アラートの前に表示され、それらのアラートから作成されたすべてのインシデントに表示されます。
カスタム詳細の表示について詳しく確認し、完全な手順を確認するには、Microsoft Sentinel のアラートでカスタム イベントの詳細を表示するをご覧ください。
アラートの詳細
この設定を使用すると、個々のアラートのさまざまなフィールドの内容に応じて、標準以外のアラート プロパティをカスタマイズできます。 これらのカスタマイズは、アラートの ExtendedProperties フィールドに統合されます。 たとえば、アラートの名前または説明をカスタマイズして、アラートに含まれるユーザー名または IP アドレスを含めることができます。
アラートの詳細のカスタマイズの詳細と、完全な手順については、「Microsoft Sentinelでのアラートの詳細のカスタマイズ」を参照してください。
注:
Microsoft Defender ポータルでは、Defender XDR関連付けエンジンはインシデントの名前付けのみを担当するため、カスタマイズしたアラート名は、これらのアラートからインシデントが作成されるときにオーバーライドされる可能性があります。
クエリ のスケジュール設定
次のパラメーターは、スケジュールされたルールを実行する頻度と、実行するたびに調べる期間を決定します。
| 設定 | 動作 |
|---|---|
| すべてのクエリを実行する | クエリの実行頻度を制御します。 |
| 最後の参照データ | ルックバック期間 (クエリの対象となる期間) を決定します。 |
これらのパラメーターの両方で使用できる範囲は 、5 分 から 14 日です。
クエリ間隔は、ルックバック期間以上短くする必要があります。 短い場合、クエリ期間が重複し、結果が重複する可能性があります。 ただし、ルールの検証では、ルックバック期間より長い間隔を設定することはできません。ただし、これによりカバレッジがギャップになる可能性があります。
[ 実行中の開始 ] 設定 (プレビュー段階) では、状態 が [有効] のルールを作成できますが、最初の実行を所定の日時まで遅らせることができます。 この設定は、ソースからデータが取り込まれると予想されるタイミング、または SOC アナリストが作業日を開始するときに、ルールの実行に時間を取る場合に役立ちます。
| 設定 | 動作 |
|---|---|
| 自動的に | ルールは、作成直後に初めて実行され、その後、[ クエリの実行] 設定で設定された間隔で実行されます。 |
| 特定の時刻 (プレビュー) | 最初に実行するルールの日付と時刻を設定します。その後、[ クエリの実行] 設定で設定された間隔で実行されます。 |
開始実行時間は、ルールの作成 (または有効化) 時間から 10 分から 30 日後である必要があります。
[ Start running]\(実行の開始 \) 設定の下のテキスト行 (左側の情報アイコン) は、現在のクエリ のスケジュール設定とルックバック設定をまとめたものです。
注:
インジェストの遅延
ソースでイベントが生成されてから Microsoft Sentinel に取り込まれるまでの間に発生する可能性のある遅延を考慮し、データを重複させることなく完全に網羅できるようにするため、Microsoft Sentinel では、スケジュールされた分析ルールをそのスケジュール時刻から5 分遅らせて実行します。
詳細については、「 スケジュールされた分析ルールでのインジェスト遅延の処理」を参照してください。
アラートのしきい値
多くの種類のセキュリティ イベントは、通常または少数で予想されますが、大きな数の脅威の兆候です。 大きな数値のスケールが異なると、さまざまな種類の脅威を意味する可能性があります。 たとえば、1 分間に 2 回または 3 回失敗したサインイン試行は、ユーザーがパスワードを覚えていない兆候ですが、1 分に 50 回は人間の攻撃の兆候である可能性があり、1000 件はおそらく自動攻撃です。
ルールが検出しようとしているアクティビティの種類に応じて、アラートをトリガーするために必要な最小限の数のイベント (クエリ結果) を設定できます。 しきい値は、一括ではなく、ルールを実行するたびに個別に適用されます。
しきい値は、結果の最大数または正確な数に設定することもできます。
イベントのグループ化
イベントのグループ化をアラートに処理するには、次の 2 つの方法があります。
すべてのイベントを 1 つのアラートにグループ化します。 これが既定値です。 クエリが前のセクションで説明した指定したアラート しきい値 よりも多くの結果を返す限り、ルールは実行されるたびに 1 つのアラートを生成します。 この 1 つのアラートは、クエリ結果で返されるすべてのイベントをまとめたものです。
イベントごとにアラートをトリガーします。 ルールは、クエリによって返されるイベント (結果) ごとに一意のアラートを生成します。 このモードは、イベントを個別に表示する場合、または特定のパラメーター (ユーザー、ホスト名など) でグループ化する場合に便利です。 これらのパラメーターはクエリで定義できます。
分析ルールでは、最大 150 個のアラートを生成できます。 [イベントのグループ化] が [イベントのアラートをトリガーする] に設定されていて、ルールのクエリから 150 を超えるイベントが返された場合、最初の 149 イベントはそれぞれ一意のアラート (149 個のアラート) を生成し、150 番目のアラートは返されたイベントのセット全体を集計します。 つまり、150 番目のアラートは、 イベントのグループ化 が [ すべてのイベントを 1 つのアラートにグループ化する] に設定されている場合に生成される可能性があります。
アラートの [クエリ] セクションは、これら 2 つのモードのそれぞれで異なります。 [ すべてのイベントを 1 つのアラート モードにグループ化 する] では、アラートをトリガーしたすべてのイベントを表示できるクエリがアラートから返されます。 クエリ結果にドリルダウンして、個々のイベントを表示できます。 [ イベント モードごとにアラートをトリガー する] では、クエリ領域に base64 でエンコードされた結果が返されます。 Log Analytics でこの出力をコピーして実行して base64 をデコードし、元のイベントを表示します。
[ イベントごとにアラートをトリガー する] 設定では、クエリ結果が見つからないか、予期した値とは異なる問題が発生する可能性があります。 このシナリオの詳細については、「Microsoft Sentinelでの分析ルールのトラブルシューティング 」 を参照してください。 |問題: クエリ結果にイベントが表示されません。
抑制
アラートが生成された後、このルールの動作を一定期間停止する場合は、[アラートが 生成された後にクエリの実行を停止 する] 設定 を [オン] に設定します。 次に、クエリの 実行を停止する 時間 (最大 24 時間) を に設定する必要があります。
結果シミュレーション
分析ルール ウィザードを使用すると、現在のデータ セットで実行することで、その有効性をテストできます。 テストを実行すると、現在定義されているスケジュールに従って、クエリが過去 50 回にわたって生成した結果のグラフが [ 結果シミュレーション ] ウィンドウに表示されます。 クエリを変更した場合は、もう一度テストを実行してグラフを更新できます。 このグラフには、定義した期間の結果の数が表示されます。これは、定義したクエリ スケジュールによって決まります。
前のスクリーンショットのクエリの結果シミュレーションの例を次に示します。 左側は既定のビューで、右側はグラフ上のポイントインタイムにマウス ポインターを合わせると表示されます。
クエリでトリガーされるアラートが多すぎる、または頻度が高すぎる場合は、スケジュール設定としきい値設定を試してシミュレーションを再実行できます。
インシデント設定
Microsoft Sentinel でアラートを対応可能なインシデントに変換するかどうかを選択します。
インシデントの作成は既定で有効になっています。 Microsoft Sentinelでは、ルールによって生成された各アラートとは別の 1 つのインシデントが作成されます。
このルールによってインシデントが作成されないようにする場合 (たとえば、このルールが後続の分析のために情報を収集するだけの場合)、これを [無効] に設定します。
重要
Microsoft Sentinelを Defender ポータルにオンボードした場合、Microsoft Defenderはインシデントの作成を担当します。 ただし、Defender XDR でこのアラートに対するインシデントを作成する場合は、この設定を 有効 のままにしておく必要があります。 Defender XDRは、ここで定義されている命令を受け取ります。
これは、Microsoft Defender サービスで生成されたアラートのインシデントを作成する Microsoft セキュリティの種類の分析ルールと混同しないでください。 これらのルールは、Microsoft Sentinelを Defender ポータルにオンボードすると自動的に無効になります。
アラートごとに 1 つではなく、アラートのグループから 1 つのインシデントを作成する場合は、次のセクションを参照してください。
アラートのグループ化
インシデントでアラートをグループ化する方法を選択します。 既定では、Microsoft Sentinelは生成されたすべてのアラートに対してインシデントを作成します。 代わりに、複数のアラートを 1 つのインシデントにまとめるオプションがあります。
インシデントは、すべてのアラートが生成された後にのみ作成されます。 すべてのアラートは、作成時にインシデントにすぐに追加されます。
最大 150 個のアラートを 1 つのインシデントにグループ化できます。 1 つのインシデントにグループ化するルールによって 150 を超えるアラートが生成された場合、元のインシデントの詳細と同じインシデントの詳細を持つ新しいインシデントが生成され、余分なアラートが新しいインシデントにグループ化されます。
アラートをまとめてグループ化するには、アラートのグループ化設定を [有効] に設定します。
アラートをグループ化するときに考慮する必要があるオプションがいくつかあります。
時間枠: 既定では、インシデント内の最初のアラートから 5 時間以内に作成されたアラートは、同じインシデントに追加されます。 5 時間後に、新しいインシデントが作成されます。 この期間は、5 分から 7 日の間の任意の場所に変更できます。
グループ化条件: グループに含めるアラートを決定する方法を選択します。 次の表に、考えられる選択肢を示します。
オプション 説明 すべてのエンティティが一致する場合、アラートを 1 つのインシデントにグループ化する 前に定義した マップされたエンティティ ごとに同じ値を共有する場合、アラートはグループ化されます。 これは推奨される設定です。 このルールによってトリガーされたすべてのアラートを 1 つのインシデントにグループ化する このルールによって生成されたすべてのアラートは、同じ値を共有しない場合でもグループ化されます。 選択したエンティティと詳細が一致する場合、アラートを 1 つのインシデントにグループ化する この設定で選択したすべての マップされたエンティティ、 アラートの詳細、 およびカスタムの詳細 について同じ値を共有する場合、アラートはグループ化されます。 このオプションを選択すると表示されるドロップダウン リストからエンティティと詳細を選択します。
たとえば、ソースまたはターゲット IP アドレスに基づいて個別のインシデントを作成する場合や、特定のエンティティと重大度に一致するアラートをグループ化する場合に、この設定を使用できます。
注: このオプションを選択する場合、ルールに対して少なくとも 1 つのエンティティまたは詳細が選択されている必要があります。 それ以外の場合、ルールの検証は失敗し、ルールは作成されません。インシデントの再オープン: インシデントが解決されて閉じられ、そのインシデントに属する必要がある別のアラートが後で生成された場合は、閉じたインシデントを再度開く場合はこの設定を [有効] に設定し、新しいアラートで新しいインシデントを作成する場合は [無効] のままにします。
Defender ポータルにMicrosoft Sentinelオンボードした場合、閉じたインシデントを再度開くオプションは使用できません。
自動応答
Microsoft Sentinelを使用すると、次の場合に自動応答を実行するように設定できます。
- この分析ルールによってアラートが生成されます。
- インシデントは、この分析ルールによって生成されたアラートから作成されます。
- インシデントは、この分析ルールによって生成されたアラートで更新されます。
作成および自動化できるさまざまな種類の応答について詳しくは、「自動化ルールを使用したMicrosoft Sentinelでの脅威対応の自動化」をご覧ください。
[ 自動化ルール ] 見出しの下に、ワークスペース全体に既に定義されている自動化ルールの一覧が表示されます。その条件はこの分析ルールに適用されます。 これらの既存のルールを編集することも、この分析ルールにのみ適用される 新しい自動化ルールを作成 することもできます。
自動化ルールを使用して、インシデントの 基本的なトリアージ、割り当て、 ワークフロー、終了を実行します。
これらの自動化ルールからプレイブックを呼び出すことで、より複雑なタスクを自動化し、リモート システムからの応答を呼び出して脅威を修復します。 インシデントだけでなく、個々のアラートに対してもプレイブックを呼び出すことができます。
プレイブックと自動化ルールを作成する方法の詳細と手順については、「 脅威の応答を自動化する」を参照してください。
インシデントが作成したトリガー、インシデントが更新したトリガー、またはアラートが作成したトリガーを使用するタイミングの詳細については、「プレイブックでトリガーとアクションを使用する」Microsoft Sentinel参照してください。
[ アラートの自動化 (クラシック)] 見出しの下に、 2026 年 3 月に非推奨となる古いメソッドを使用して自動的に実行するように構成されたプレイブックの一覧が表示される場合があります。 この一覧には何も追加できません。 ここに記載されているプレイブックについては、プレイブックを起動するために、アラート作成トリガーに基づく自動化ルールを作成する必要があります。 その後、ここに表示されているプレイブックの行の末尾にある省略記号を選択し、削除 を選択します。 詳細な手順については、「Microsoft Sentinelアラートトリガープレイブックを自動化ルールに移行する」を参照してください。
次の手順
Microsoft Sentinel分析ルールを使用して環境全体の脅威を検出する場合は、接続されたデータ ソースに関連付けられているすべてのルールを有効にして、環境の完全なセキュリティ カバレッジを確保してください。
ルールの有効化を自動化するには、API と PowerShell を使用してルールをMicrosoft Sentinelにプッシュします。ただし、その場合は、さらに多くの労力が必要です。 API または PowerShell を使用する場合は、ルールを有効にする前に、まずルールを JSON にエクスポートする必要があります。 API または PowerShell は、各インスタンスで同じ設定を持つMicrosoft Sentinelの複数のインスタンスでルールを有効にする場合に役立ちます。
詳細については、以下を参照してください: