Microsoft Sentinel のスケジュールされた分析ルール
分析ルールの種類としては最も一般的であるスケジュール化されたルールは、Kusto クエリに基づいています。このクエリは一定の間隔で実行するように構成されており、定義済みの "ルックバック" 期間の生データを調べます。 クエリでは、複雑な統計操作をターゲット データに対して実行できるので、一群のイベント内のベースラインと外れ値が明らかになります。 クエリによって捕捉された結果の数がルール内で構成されたしきい値を超えている場合は、ルールによってアラートが生成されます。
この記事は、スケジュールされた分析ルールの構築方法の理解に役立ち、すべての構成オプションとその意味について説明します。 この記事の情報は、次の 2 つのシナリオで役立ちます。
テンプレートから分析ルールを作成する: クエリのロジックと、スケジューリングとルックバックの設定をテンプレートで定義されているとおりに使用するか、それらをカスタマイズして新しいルールを作成します。
分析ルールを最初から作成する: 独自のクエリとルールを最初から構築します。 これを効果的に行うには、データ サイエンスと Kusto クエリ言語について十分な基礎知識が必要です。
重要
Microsoft Sentinel は Microsoft Defender ポータルの Microsoft の統合セキュリティ オペレーション プラットフォーム内で一般提供されています。 プレビュー版については、Microsoft Defender XDR または E5 ライセンスなしで Defender ポータルで Microsoft Sentinel を使用できます。 詳しくは、「Microsoft Defender ポータルの Microsoft Sentinel」を参照してください。
分析ルール テンプレート
スケジュールされたルール テンプレートの中のクエリは、Microsoft またはそのテンプレートを提供するソリューションのベンダーの、セキュリティとデータ サイエンスのエキスパートによって書かれています。
分析ルール テンプレートを使用するには、テンプレートのリストからテンプレート名を選び、それに基づいてルールを作成します。
各テンプレートには、必要なデータ ソースの一覧があります。 テンプレートを開くと、データ ソースの可用性が自動的にチェックされます。 可用性とは、データ ソースが接続されており、そのデータ ソースを通じてデータが定期的に取り込まれていることを意味します。 必要なデータ ソースのいずれかが利用できない場合は、ルールを作成できず、その旨のエラー メッセージが表示されることもあります。
テンプレートからルールを作成すると、選択したテンプレートに基づいてルール作成ウィザードが開きます。 詳細はすべて自動的に入力されますが、特定のニーズに合わせてロジックやその他のルール設定をカスタマイズできます。 この手順を繰り返して、テンプレートに基づく追加のルールを作成できます。 ルール作成ウィザードが終了すると、カスタマイズが検証され、ルールが作成されます。 新しいルールが、[分析] ページの [アクティブなルール] タブに表示されます。 同様に、[ルール テンプレート] タブには、ルールの作成元となったテンプレートが In use タグ付きで表示されます。
分析ルール テンプレートは、バグを修正するため、またはクエリを改良するために、作成者によって継続的にメンテナンスされています。 テンプレートが更新プログラムを受け取ると、そのテンプレートに基づくすべてのルールが Update タグ付きで表示されるため、それらのルールを変更してテンプレートに加えられた変更を組み込むことができます。 ルールに加えた変更を元のテンプレート ベースのバージョンに戻すこともできます。 詳細については、「Microsoft Azure Sentinel でスケジュール化された分析ルールのテンプレート バージョンを管理する」を参照してください。
この記事の構成オプションについて理解したら、「スケジュール化された分析ルールをテンプレートから作成する」を参照してください。
この記事の残りの部分では、ルールの構成をカスタマイズするためのすべての可能性について説明します。
分析ルールの構成
このセクションでは、ルールの構成を開始する前に考慮する必要がある主な考慮事項について説明します。
分析ルールの名前と詳細
分析ルール ウィザードの最初のページには、ルールの基本情報が含まれています。
名前: ルールのリストとルールベースのフィルターに表示されるルールの名前。 名前はワークスペースに対して一意である必要があります。
説明: ルールの目的に関する自由形式の説明です。
ID: API の要求や応答などに使用される、Azure リソースとしてのルールの GUID。 この GUID はルールの作成時にのみ割り当てられるため、既存のルールを編集しているときにのみ表示されます。 これは読み取り専用フィールドであるため、淡色表示され、変更することはできません。 テンプレートからでも最初からでも、新しいルールを作成するときは、まだ存在しません。
重大度: このルールによって生成されるアラートに与える評価です。 アクティビティの重大度は、アクティビティの発生による潜在的な悪影響の計算です。
| 重大度 | 説明 |
|---|---|
| Informational | システムに影響はありませんが、情報は、脅威アクターによって計画された将来の手順を示している可能性があります。 |
| 低 | 即時の影響は最小です。 脅威アクターは、環境への影響を達成する前に、複数の手順を実行する必要がある可能性があります。 |
| Medium | 脅威アクターは、このアクティビティを使用して環境に何らかの影響を与える可能性がありますが、スコープが制限されるか、追加のアクティビティが必要になります。 |
| 高 | 特定されたアクティビティは、脅威アクターに、環境に対するアクションを実行するための幅広いアクセスを提供するか、環境への影響によってトリガーされます。 |
重大度レベルの既定値は、現在または環境への影響レベルを保証するものではありません。 アラートの詳細をカスタマイズして、クエリ出力の関連フィールドの値を使用して、アラートの特定のインスタンスの重大度、戦術、およびその他のプロパティをカスタマイズします。
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","")
Kusto クエリの作成に関する詳細については、「Microsoft Sentinel の Kusto クエリ言語」と、「Kusto クエリ言語クエリのベスト プラクティス」を参照してください。
アラートの拡張機能
アラートの調査結果がインシデントで即座に表示され、適切に追跡および調査されるようにするには、アラートの拡張機能構成を使用してアラートにすべての重要な情報を表示させます。
このアラートの拡張機能には、調査結果を見やすく、アクセスしやすい方法で表示するという付加価値があります。
構成できるアラートの拡張機能には、次の 3 種類があります。
- エンティティ マッピング
- カスタム詳細
- アラートの詳細 (動的コンテンツとも呼ばれます)
エンティティ マッピング
エンティティは、攻撃ストーリーのどちら側にも存在するプレイヤーです。 脅威を検出して調査するためには、アラート内のすべてのエンティティを識別することが不可欠です。 Microsoft Sentinel で生データ内のエンティティを識別できるようにするには、Microsoft Sentinel で認識されるエンティティ型をクエリ結果のフィールドにマップする必要があります。 このマッピングにより、識別されたエンティティがアラート スキーマの [エンティティ] フィールドに統合されます。
エンティティ マッピングの詳細と完全な手順については、「データ フィールドを Microsoft Azure Sentinel のエンティティにマップする」を参照してください。
カスタム詳細
既定では、アラート エンティティとメタデータのみがインシデントに表示され、クエリ結果の生のイベントへのドリルダウンは行われません。 クエリ結果の他のフィールドをアラートとインシデントですぐに表示するには、それらをカスタム詳細として定義します。 Microsoft Sentinel では、これらのカスタム詳細がアラートの [ExtendedProperties] フィールドに統合され、アラートや、それらのアラートから作成されたすべてのインシデントに表示されます。
カスタム詳細の表示の詳細と完全な手順については、「Microsoft Sentinel でアラートに含まれるカスタム イベントの詳細を表示する」を参照してください。
アラートの詳細
この設定により、個々のアラートのさまざまなフィールドの内容に応じて、標準のアラート プロパティとは異なるようカスタマイズできます。 これらのカスタマイズは、アラートの [ExtendedProperties] フィールドに統合されます。 たとえば、アラートの名前や説明をカスタマイズして、アラートに含まれるユーザー名や IP アドレスを含むようにすることができます。
アラートの詳細をカスタマイズする方法の詳細については、「Microsoft Sentinel でアラートの詳細をカスタマイズする」を参照してください。
Note
Microsoft Defender ポータルでは、Defender XDR 相関関係エンジンがインシデントの命名を単独で担うため、これらのアラートからインシデントが作成されると、カスタマイズしたアラート名がオーバーライドされる可能性があります。
クエリのスケジューリング
次のパラメーターは、スケジュールされたルールが実行される頻度と、実行されるたびに検査される期間を決定します。
| 設定 | 動作 |
|---|---|
| クエリの実行間隔 | クエリの実行頻度、つまりクエリの実行間隔を制御します。 |
| 参照する過去データの範囲 | クエリの対象となる期間、つまりルックバック期間を決定します。 |
これらの両方のパラメーターで使用できる範囲は、[5 分] から [14 日間] です。
クエリ間隔は、ルックバック期間以下である必要があります。 ルックバック期間が短い場合、クエリ期間が重複し、結果の重複が発生する可能性があります。 ただし、ルールの検証では、ルックバック期間よりも長い間隔を設定することはできません。そのため、カバレッジにギャップが生じます。
現在プレビュー段階の [実行の開始] 設定を使用すると、状態が [有効] のルールを作成し、その最初の実行を事前に決定した日時まで延期することができます。 この設定は、ソースからデータが取り込まれると予想される時間や、SOC アナリストが仕事を始める時間に応じてルールの実行時間を設定する場合に役立ちます。
| 設定 | 動作 |
|---|---|
| [自動] | ルールは、まず作成直後に実行され、その後 [クエリの実行間隔] 設定に設定されている間隔で実行されます。 |
| [特定の時刻に] (プレビュー) | ルールの初回実行の日付と時刻を設定します。その後は、[クエリの実行間隔] で設定された間隔で実行されます。 |
[実行の開始] の時刻は、ルールの作成 (または有効化) の時点以降 10 分～ 30 日の間である必要があります。
[Start running](実行の開始) 設定の下にあるテキスト行 (その左側に情報アイコンがある) に、クエリのスケジュールとルックバックの設定が要約されます。
Note
インジェストの遅延
ソースでのイベントの生成と Microsoft Sentinel へのインジェストの間で発生する可能性がある待ち時間を考慮し、データが重複せずに完全にカバーされるようにするために、Microsoft Sentinel では、スケジュールされた時間から 5 分間遅延して、スケジュールされた分析ルールが実行されます。
詳細については、「スケジュールされた分析ルールでインジェストの遅延を処理する」を参照してください。
通知のしきい値
セキュリティ イベントの多くは、少数であれば正常または予想の範囲内ですが、大量に発生すると脅威の兆候となります。 規模が異なる大きな数値は、異なる種類の脅威を意味することがあります。 たとえば、1 分間に 2、3 回のサインイン試行の失敗は、ユーザーがパスワードを思い出せないことを示している可能性がありますが、1 分に 50 回は人間による攻撃の兆候である可能性があり、1,000 回は自動化された攻撃を示している可能性があります。
ルールで検出しようとしているアクティビティの種類に応じて、アラートをトリガーするために必要なイベント (クエリ結果) の最小数を設定できます。 このしきい値は、ルールが実行されるたびに個別に適用され、全体に適用されるわけではありません。
このしきい値は、結果の最大数または正確な数に設定することもできます。
イベントのグループ化
イベントのアラートへのグループ化を処理するには、次の 2 つの方法があります。
[すべてのイベントを単一のアラートにグループ化する]: これが既定値です。 このルールでは、クエリで前のセクションで説明したアラートのしきい値よりも多くの結果が返される限り、実行されるたびに 1 つのアラートが生成されます。 この単一アラートで、クエリ結果で返されるすべてのイベントがまとめられます。
[各イベントに対するアラートをトリガーする]: このルールでは、クエリによって返されるイベント (結果) ごとに独自のアラートが生成されます。 このモードは、イベントを個々に表示する場合や、ユーザーやホスト名など、特定のパラメーター別にイベントをグループ化する場合に便利です。 これらのパラメーターはクエリ内で定義できます。 |
分析ルールでは、最大 150 個のアラートを生成できます。 [イベントのグループ化] が [各イベントについてアラートをトリガーする] に設定されていて、ルールのクエリから 150 を超えるイベントが返された場合、最初の 149 件のイベントについてはそれぞれに独自のアラート (149 件のアラート) が生成され、150 番目のアラートでは、返された一連のイベント全体がまとめられます。 言い換えると、150 番目のアラートは、[イベントのグループ化] が[すべてのイベントを単一のアラートにグループ化する] に設定されていた場合に生成されたはずのアラートです。
[各イベントに対するアラートをトリガーする] 設定を使用すると、クエリ結果が欠落したり、予想と異なる結果になったりする問題が発生する可能性があります。 このシナリオの詳細については、「Microsoft Sentinel での分析ルールに関するトラブルシューティングを実行する」の「問題点: クエリ結果にイベントが表示されない」を参照してください。
抑制
アラートを生成した後、このルールの動作を一定期間停止する場合は、[アラートの生成後にクエリの実行を停止する] 設定を [オン] にします。 次に、[クエリの実行を停止する] をクエリの実行を停止する時間 (最大 24 時間) に設定する必要があります。
結果のシミュレーション
分析ルール ウィザードを現在のデータ セットで実行すると、その有効性をテストできます。 テストを実行すると、[結果のシミュレーション] ウィンドウに、現在定義されているスケジュールに従って、そのクエリが直近の 50 回実行された場合に生成されたであろう結果のグラフが表示されます。 クエリを変更した場合は、もう一度テストを実行してグラフを更新できます。 グラフには、定義したクエリ スケジュールによって決まる、定義された期間における結果の数が表示されます。
上のスクリーンショットのクエリに対する結果のシミュレーションは次のようになります。 左側は既定のビューであり、右側はグラフ上の特定の時点にマウス ポインターを合わせたときに表示される内容です。
クエリによってトリガーされるアラートが多すぎる場合や頻繁すぎる場合は、スケジュールとしきい値の設定を試して、シミュレーションを再度実行できます。
インシデントの設定
Microsoft Sentinel がアラートを実用的なインシデントに変えるかどうかを選択します。
インシデントの作成は既定で有効になっています。 Microsoft Sentinel では、ルールによって生成されるアラートごとに個別のインシデントが 1 つ作成されます。
このルールによってインシデントが作成されないようにする場合は (たとえば、このルールが後続の分析のために情報を収集するだけの場合)、これを [無効] に設定します。
重要
Microsoft Sentinel を Defender ポータルにオンボードした場合、Microsoft Defender がインシデントの作成を担います。 ただし、Defender XDR でこのアラートのインシデントを作成する場合は、この設定を [有効] のままにしておく必要があります。 Defender XDR は、ここで定義されている命令を受け取ります。
これは、Microsoft Defender サービスで生成されたアラートのインシデントを作成する Microsoft セキュリティの分析ルールの種類と混同しないでください。 これらのルールは、Microsoft Sentinel を Defender ポータルにオンボードすると自動的に無効になります。
単一のインシデントをアラートごとにではなく、アラートのグループから作成する場合は、次のセクションをご覧ください。
アラートのグループ化
インシデントでどのようにアラートをグループ化するかを選びます。 既定では、Microsoft Sentinel では生成されたすべてのアラートに対してインシデントが作成されます。 代わりに、複数のアラートを 1 つのインシデントにグループ化することもできます。
インシデントは、すべてのアラートが生成された後にのみ作成されます。 すべてのアラートは、作成後すぐにインシデントに追加されます。
最大 150 件のアラートを 1 つのインシデントにグループ化できます。 アラートを 1 つのインシデントにグループ化するルールによって生成されたアラートが 150 件を超える場合は、元のインシデントと同じインシデントの詳細を持つ新しいインシデントが生成され、超過したアラートは新しいインシデントにグループ化されます。
アラートをグループ化するには、アラートのグループ化設定を [有効] に設定します。
アラートをグループ化するときに考慮すべきいくつかのオプションがあります。
概算時間: 既定では、インシデントの最初のアラートから 5 時間後までに作成されたアラートが同じインシデントに追加されます。 5 時間後に、新しいインシデントが作成されます。 この期間は、5 分から 7 日間の間で変更できます。
グループ化条件: グループに含めるアラートを決定する方法を選択します。 次の表に、考えられる選択肢を示します。
オプション 説明 すべてのエンティティが一致した場合にアラートを 1 つのインシデントにグループ化する 以前に定義したマップされたエンティティごとに同じ値を共有する場合、アラートはグループ化されます。 これは推奨される設定です。 このルールによってトリガーされるすべてのアラートを 1 つのインシデントにグループ化する 値が同じではない場合でも、このルールによって生成されるすべてのアラートをグループ化します。 選択したエンティティと詳細が一致する場合にアラートを 1 つのインシデントにグループ化する すべてのマップされたエンティティ、アラートの詳細、およびこの設定で選択したカスタムの詳細で同じ値を共有する場合、アラートはグループ化されます。 このオプションを選択すると表示されるドロップダウン リストからエンティティと詳細を選択します。
たとえば、ソースまたはターゲットの IP アドレスに基づいて別々のインシデントを作成したい場合や、特定のエンティティと重要度に一致するアラートをグループ化したい場合、この設定を使用できます。
注: このオプションを選択する場合は、ルールに対して少なくとも 1 つのエンティティまたは詳細が選択されている必要があります。 そうしないと、ルールの検証が失敗し、ルールは作成されません。インシデントを再度開く: あるインシデントが解決されて閉じられたとします。後でそのインシデントに属するはずの別のアラートが生成されたときに、閉じられたインシデントを再び開く場合は、この設定を [有効] に設定します。新しいアラートで新しいインシデントを作成する場合は [無効] のままにします。
Microsoft Sentinel を Defender ポータルにオンボードした場合、閉じたインシデントを再度開くオプションは使用できません。
自動応答
Microsoft Sentinel を使用すると、次の場合に自動応答を実行するように設定できます。
- この分析ルールによってアラートが生成される場合。
- この分析ルールによって生成されたアラートからインシデントが作成される場合。
- この分析ルールによって生成されたアラートを使用してインシデントが更新される場合。
作成および自動化できるさまざまな種類の応答について詳しくは、「自動化ルールを使って Microsoft Sentinel の脅威への対応を自動化する」をご覧ください。
ウィザードの [オートメーション ルール]の見出しの下には、ワークスペース全体で既に定義されているオートメーション ルールのリストが表示され、その条件がこの分析ルールに適用されます。 これらの既存のルールを編集することも、この分析ルールにのみ適用される新しいオートメーション ルールを作成することもできます。
自動化ルールを使用して、インシデントの基本的なトリアージ、割り当て、ワークフロー、終了を実行します。
これらの自動化ルールからプレイブックを呼び出すことで、より複雑なタスクを自動化し、リモート システムからの応答を呼び出して脅威を修復します。 インシデントと個々のアラートについて、プレイブックを呼び出すことができます。
プレイブックや自動化ルールの作成に関する詳細と手順については、「脅威への対応を自動化する」を参照してください。
インシデント作成トリガー、インシデント更新トリガー、アラート作成トリガーを使用するタイミングの詳細については、「Microsoft Sentinel のプレイブックでトリガーとアクションを使用する」を参照してください。
[アラートのオートメーション (クラシック)] の見出しの下に、2026 年 3 月に非推奨になる予定の以前の方法を使用して自動的に実行するように構成されたプレイブックのリストが表示される場合があります。 このリストには何も追加できません。 ここに一覧表示されているすべてのプレイブックには、アラート作成トリガーに基づいてプレイブックを呼び出すオートメーション ルールが作成されている必要があります。 完了したら、ここに記載されているプレイブックの行の末尾にある省略記号を選択し、[削除] を選択します。 詳細な手順については、「Microsoft Sentinel のアラートトリガー プレイブックをオートメーション ルールに移行する」を参照してください。
次のステップ
Microsoft Sentinel 分析ルールを使用して環境全体の脅威を検出する場合は、接続されたデータ ソースに関連付けられているすべてのルールを有効にして、環境の完全なセキュリティ カバレッジを確保してください。
ルールの有効化を自動化するには、API および PowerShell 経由で Microsoft Sentinel にルールをプッシュすることもできますが、それを行うには追加の作業が必要です。 API または PowerShell を使用する場合は、ルールを有効にする前に、最初にルールを JSON にエクスポートする必要があります。 API または PowerShell は、Microsoft Sentinel の複数のインスタンスでルールを有効にし、各インスタンスの設定を同じにする場合に役立つことがあります。
詳細については、以下を参照してください:
- ARM テンプレート間で分析ルールをエクスポートおよびインポートします
- Microsoft Sentinel での分析ルールに関するトラブルシューティングを実行する
- Microsoft Sentinel でのインシデントの確認と調査
- Microsoft Sentinel のエンティティ
- チュートリアル: Microsoft Sentinel でオートメーション ルールとプレイブックを使用する
また、カスタム コネクタで Zoom を監視するするときにカスタム分析ルールを使用する例も参照してください。