カスタム分析ルールを最初から作成する

  • [アーティクル]
  • 適用対象:
    Microsoft Sentinel in the Azure portal, Microsoft Sentinel in the Microsoft Defender portal

コネクタと、デジタル資産全体でアクティビティ データを収集するその他の方法を設定しました。 次に、すべてのデータを調べてアクティビティのパターンを検出し、それらのパターンに適合しない、セキュリティ上の脅威を示している可能性のあるアクティビティを検出する必要があります。

Microsoft Sentinel とそのコンテンツ ハブで提供される多くの ソリューションにより、最も一般的に使用される種類の分析ルールのテンプレートが提供されます。これらのテンプレートを使用して、特定のシナリオに合わせてカスタマイズすることを強くお勧めします。 ただし、まったく異なるものが必要になる場合もあることでしょう。その場合は、分析ルール ウィザードを使用して最初からルールを作成することができます。

この記事では、Analytics ルール ウィザードについて説明し、使用可能なすべてのオプションについて説明します。 Azure portal から (Microsoft Sentinel ユーザーで、Microsoft Defender サブスクライバーではない場合)、または Defender ポータルから (Microsoft Defender 統合セキュリティ運用プラットフォームのユーザーの場合)、ウィザードにアクセスするためのスクリーンショットと指示がついています。

重要

Microsoft Sentinel は、Microsoft Defender ポータルの統合セキュリティ オペレーション プラットフォームのパブリック プレビューの一部として利用できます。 詳細については、「Microsoft Defender ポータルの Microsoft Sentinel」を参照してください。

前提条件

  • Microsoft Sentinel 共同作成者ロール、または Log Analytics ワークスペースとそのリソース グループに対する書き込みアクセス許可を含む他のロールまたはアクセス許可のセットが必要です。

クエリを設計して構築する

何よりもまず、ルールが Log Analytics ワークスペース内の 1 つ以上のテーブルに対するクエリを行うために使用する Kusto クエリ言語 (KQL) でクエリを設計し、作成する必要があります。

  1. 通常とは異なる疑わしいアクティビティを検出するために検索するデータ ソースを決定します。 そのソースからのデータが取り込まれる Log Analytics テーブルの名前を見つけます。 テーブル名は、そのソースのデータ コネクタのページで見つけることができます。 クエリの元になるテーブルとして、このテーブル名 (またはそれに基づく関数) を使用します。

  2. そのテーブルに対して、このクエリでどのような分析を実行するかを決定します。 これを決めることで、クエリで使用するコマンドと関数が決まります。

  3. クエリ結果から必要なデータ要素 (フィールド、列) を決定します。 これを決めることで、クエリの出力を構成する方法が決まります。

分析ルール クエリのベスト プラクティス

  • ネイティブ テーブルを使用するのではなく、Advanced Security Information Model (ASIM) パーサー をクエリ ソースとして使用することをお勧めします。 こうすることで、クエリが、1 つのデータ ソースに依存するのではなく、現在または将来の関連するデータ ソースをサポートするようになります。

  • クエリの長さは 1 から 10,000 文字にする必要があります。また、"search *" または "union *" を含めることはできません。 ユーザー定義関数を使用すると、クエリの長さの制限を克服できます。

  • ADX 関数を使用して Log Analytics クエリウィンドウ 内で Azure Data Explorer クエリを作成することは、サポートされていません。

  • クエリで bag_unpack 関数を使用する場合、"project field1" を使用して列をフィールドとして射影しても、その列が存在しないと、クエリは失敗します。 このような事態を防ぐために、次のように列を射影する必要があります。

    project field1 = column_ifexists("field1","")

Kusto クエリの作成に関する詳細については、「Microsoft Sentinel の Kusto クエリ言語」と、「Kusto クエリ言語クエリのベスト プラクティス」を参照してください。

[ログ] 画面でクエリをビルドしてテストします。 問題がなければ’、ルールで使用するクエリを保存します。

分析ルールを作成する

このセクションでは、Azure portal または Defender ポータルを使用してルールを作成する方法について説明します。

分析ルール ウィザードを開始する

  1. Microsoft Sentinel のナビゲーション メニューの [構成] セクションで、[分析] を選択します。

  2. 上部のアクション バーで、 [+ 作成] を選択し、 [スケジュール済みクエリ ルール] を選択します。 分析ルール ウィザードが開きます。

    Azure portal の [分析] 画面のスクリーンショット。

ルールに名前を付け、一般的な情報を定義する

Azure portal では、段階がタブとして視覚的に表されます。 Defender ポータルでは、タイムライン上のマイルストーンとして視覚的に表されます。 例については、以下のスクリーンショットを参照してください。

  1. 一意の [名前] と [説明] を指定します。

  2. アラートの重大度を適宜設定し、ルールが真陽性の場合にルールをトリガーするアクティビティがターゲット環境に与える影響と一致させます。

    重大度 説明
    Informational システムに影響はありませんが、情報は、脅威アクターによって計画された将来の手順を示している可能性があります。
    低 即時の影響は最小です。 脅威アクターは、環境への影響を達成する前に、複数の手順を実行する必要がある可能性があります。
    Medium 脅威アクターは、このアクティビティを使用して環境に何らかの影響を与える可能性がありますが、スコープが制限されるか、追加のアクティビティが必要になります。
    高 特定されたアクティビティは、脅威アクターに、環境に対するアクションを実行するための幅広いアクセスを提供するか、環境への影響によってトリガーされます。

    重大度レベルの既定値は、現在または環境への影響レベルを保証するものではありません。 アラートの詳細をカスタマイズして、クエリ出力の関連フィールドの値を使用して、アラートの特定のインスタンスの重大度、戦術、およびその他のプロパティをカスタマイズします。

    Microsoft Sentinel 分析ルール テンプレートの重大度定義は、分析ルールによって作成されたアラートにのみ関連します。 他のサービスから取り込まれたアラートの場合、重大度はソース セキュリティ サービスによって定義されます。

  3. [戦術と手法] フィールドでは、ルールを分類する脅威のアクティビティのカテゴリを選択できます。 これらは、MITRE ATT&CK フレームワークの戦術と手法に基づいています。

    MITRE ATT&CK の戦術と手法にマップされたルールによって検出されたアラートから作成されたインシデントでは、ルールのマッピングが自動的に継承されます。

    MITRE ATT&CK ランドスケープの対象範囲を最大化する方法の詳細については、「MITRE ATT&CK® フレームワークによるセキュリティ カバレッジについて」を参照してください

  4. ルールを作成すると、その [状態] は既定で [有効] になります。これは、作成が終わるとすぐに実行されることを意味します。 すぐに実行したくない場合は、 [無効] を選択します。ルールは [アクティブな規則] タブに追加され、必要に応じてそこから有効にすることができます。

    Note

    すぐに実行しないでルールを作成する別の方法がありますが、現在プレビュー段階です。 ルールは、特定の日時に初回実行するようにスケジュールできます。 下記の「クエリをスケジュールしてスコープを設定する」を参照してください。

  5. ルール ロジックを設定 を選択します。

ルールのロジックを定義する

  1. ルールに対するクエリを入力します。

    設計、ビルド、テストしたクエリを [ルール クエリ] ウィンドウに貼り付けます。 このウィンドウで行うすべての変更は即座に検証されるため、間違いがある場合は、ウィンドウのすぐ下に表示されます。

  2. エンティティをマップします。

    エンティティは、脅威の検出と調査に不可欠です。 Microsoft Sentinel によって認識されるエンティティ型をクエリ結果のフィールドにマップします。 このマッピングにより、検出されたエンティティがアラート スキーマの[エンティティ] フィールドに統合されます。

    エンティティのマッピングの詳細な手順については、「データ フィールドを Microsoft Sentinel のエンティティにマップする」を参照してください。

  3. アラートのカスタム詳細を表示します。

    既定では、アラート エンティティとメタデータのみがインシデントに表示され、クエリ結果の生のイベントへのドリルダウンは行われません。 この手順では、クエリ結果の他のフィールドを取得し、それらをアラートの [ExtendedProperties] フィールドに統合して、アラートやそれらのアラートから作成されたすべてのインシデントに表示されるようにします。

    カスタム詳細の表示に関する完全な手順については、「Microsoft Sentinel のアラートのカスタム イベントの詳細を表示する」を参照してください。

  4. アラートの詳細をカスタマイズします。

    この設定により、個々のアラートのさまざまなフィールドの内容に応じて、標準のアラート プロパティとは異なるようカスタマイズできます。 これらのカスタマイズは、アラートの [ExtendedProperties] フィールドに統合されます。 たとえば、アラートの名前や説明をカスタマイズして、アラートに含まれるユーザー名や IP アドレスを含むようにすることができます。

    アラートの詳細をカスタマイズする方法の詳細については、「Microsoft Sentinel でアラートの詳細をカスタマイズする」を参照してください。

  5. クエリをスケジュールしてスコープを設定します。

    1. [クエリのスケジュール設定] セクションで、次のパラメーターを設定します。

      設定 動作
      クエリの実行間隔 クエリの実行頻度、つまりクエリの実行間隔を制御します。
      参照する過去データの範囲 クエリの対象となる期間、つまりルックバック期間を決定します。

      • これらの両方のパラメーターで使用できる範囲は、[5 分] から [14 日間] です。

      • クエリ間隔は、ルックバック期間以下である必要があります。 ルックバック期間が短い場合、クエリ期間が重複し、結果の重複が発生する可能性があります。 ただし、ルールの検証では、ルックバック期間よりも長い間隔を設定することはできません。そのため、カバレッジにギャップが生じます。

    2. [実行の開始] を設定します。

      設定 動作
      [自動] ルールは、まず作成直後に実行され、その後 [クエリの実行間隔] 設定に設定されている間隔で実行されます。
      [特定の時刻に] (プレビュー) ルールの初回実行の日付と時刻を設定します。その後は、[クエリの実行間隔] で設定された間隔で実行されます。

      • [実行の開始] の時刻は、ルールの作成 (または有効化) の時点以降 10 分～ 30 日の間である必要があります。

      • [Start running](実行の開始) 設定の下にあるテキスト行 (その左側に情報アイコンがある) に、クエリのスケジュールとルックバックの設定が要約されます。

        詳細スケジュールの切り替えと設定のスクリーンショット。

    Note

    インジェストの遅延

    ソースでのイベントの生成と Microsoft Sentinel へのインジェストの間で発生する可能性がある待ち時間を考慮し、データが重複せずに完全にカバーされるようにするために、Microsoft Sentinel では、スケジュールされた時間から 5 分間遅延して、スケジュールされた分析ルールが実行されます。

    詳細については、「スケジュールされた分析ルールでインジェストの遅延を処理する」を参照してください。

  6. アラートを作成するためのしきい値を設定します。

    ルールの感度を定義するには、 [アラートのしきい値] セクションを使用します。

    • [アラートを生成するクエリ結果の数] を [より大きい] に設定し、ルールによってアラートが生成されるのに見つかる必要があるクエリ期間中のイベントの最小数を入力します。
    • これは必須フィールドであるため、しきい値—を設定しない場合、つまり、所定の期間に 1 つでもイベントがあればアラートをトリガーする場合は、数値フィールドに「0」を入力します。

  7. イベントのグループ化設定を設定します。

    [イベントのグループ化] で、イベントのアラートへのグループ化を処理する 2 つの方法のうち、いずれかを選択します。

    設定 動作
    すべてのイベントを単一のアラートにグループ化する
    (既定値)。    		 このルールでは、クエリで前記のアラートのしきい値よりも多くの結果が返される限り、実行されるたびに 1 つのアラートが生成されます。 この単一アラートで、クエリ結果で返されるすべてのイベントがまとめられます。
    各イベントについてアラートをトリガーする このルールでは、クエリによって返されるイベントごとに独自のアラートが生成されます。 これは、イベントを個々に表示する場合や、ユーザーやホスト名など、特定のパラメーター別にイベントをグループ化する場合に便利です。 これらのパラメーターはクエリ内で定義できます。

    分析ルールでは、最大 150 個のアラートを生成できます。 [イベントのグループ化] が [各イベントについてアラートをトリガーする] に設定されていて、ルールのクエリから 150 を超えるイベントが返された場合、最初の 149 件のイベントについてはそれぞれに独自のアラート (149 件のアラート) が生成され、150 番目のアラートでは、返された一連のイベント全体がまとめられます。 言い換えると、150 番目のアラートは、[イベントのグループ化] が[すべてのイベントを単一のアラートにグループ化する] に設定されていた場合に生成されたはずのアラートです。

  8. アラートが生成された後、ルールを一時的に抑制します。

    アラートが生成された後、クエリ間隔を超える期間だけこのルールの操作を中断する場合は、 [抑制] セクションで、 [アラートの生成後にクエリの実行を停止する] の設定を [オン] にすることができます。 これをオンにする場合は、 [クエリの実行を停止する] をクエリの実行を停止する時間 (最大 24 時間) に設定する必要があります。

  9. クエリとロジック設定の結果をシミュレートします。

    [結果のシミュレーション] 領域で、[現在のデータでテストする] を選択すると、Microsoft Sentinel によって、現在定義されているスケジュールに従って、クエリから実行された直近の 50 回で生成された結果 (ログ イベント) のグラフが表示されます。 クエリを変更する場合は、 [Test with current data](現在のデータでテストする) をもう一度クリックして、グラフを更新します。 グラフには、定義された期間における結果の数が表示されます。これは、 [クエリのスケジュール設定] セクションの設定によって決まります。

    上のスクリーンショットのクエリに対する結果のシミュレーションは次のようになります。 左側は既定のビューであり、右側はグラフ上の特定の時点にマウス ポインターを合わせたときに表示される内容です。

    結果のシミュレーションのスクリーンショット

    クエリによってトリガーされるアラートが多すぎる場合や頻繁すぎる場合は、[クエリのスケジュール設定] セクションと [アラートのしきい値] セクションの設定を試してから、[現在のデータでテストする] をもう一度選択します。

  10. [Next: Incident settings] (次へ: インシデントの設定) を選びます。

インシデントの作成の設定を構成する

[インシデントの設定] タブで、Microsoft Sentinel でアラートをアクションにつながるインシデントに変換するかどうか、およびアラートがインシデント内でまとめてグループ化されるかどうかを選択します。

  1. インシデントの作成を有効にします。

    [インシデントの設定] セクションでは、 [この分析ルールによってトリガーされるアラートからインシデントを作成する] が既定で [有効] に設定されています。つまり、ルールによってトリガーされるすべての個々のアラートから、1 つの個別のインシデントが作成されます。

    • このルールによってインシデントが作成されないようにする場合は (たとえば、このルールが後続の分析のために情報を収集するだけの場合)、これを [無効] に設定します。

      重要

      Microsoft Sentinel を Microsoft Defender ポータルの統合セキュリティ運用プラットフォームにオンボードし、このルールで Microsoft 365 または Microsoft Defender ソースからアラートをクエリして作成する場合は、この設定を [無効] に設定する必要があります。

    • 単一のインシデントをアラートごとにではなく、アラートのグループから作成する場合は、次のセクションをご覧ください。

  2. アラートのグループ化設定を設定します。

    最大 150 件の類似したアラートまたは繰り返し発生するアラートのグループから単一のインシデントを生成する場合 (注を参照) は、 [アラートのグループ化] セクションで、 [この分析ルールによってトリガーされる関連アラートをインシデントにグループ化する] を [有効] に設定し、以下のパラメーターを設定します。

    1. [選択した期間内に作成されたアラートのみにグループを制限する] :似たアラートまたは繰り返し発生するアラートをグループ化する期間を決定します。 この期間内の対応するすべてのアラートでは、1 つのインシデントまたはインシデントのセットがまとめて生成されます (以下のグループ化の設定に依存します)。 この期間外のアラートでは、個別のインシデントまたはインシデントのセットが生成されます。

    2. [この分析ルールによってトリガーされるアラートを次の方法で単一のインシデントにグループ化する] :アラートをグループ化する基準を選択します。

      オプション 説明
      すべてのエンティティが一致した場合にアラートを 1 つのインシデントにグループ化する (上の [ルールのロジックを設定] タブに定義された) マップされている各エンティティに関して同じ値を共有している場合、アラートはグループ化されます。 これは推奨される設定です。
      このルールによってトリガーされるすべてのアラートを 1 つのインシデントにグループ化する 値が同じではない場合でも、このルールによって生成されるすべてのアラートをグループ化します。
      選択したエンティティと詳細が一致する場合にアラートを 1 つのインシデントにグループ化する マップされたエンティティ、アラートの詳細、および各ドロップダウン リストから選択されたカスタムの詳細のすべてに関して同じ値を共有している場合、アラートはグループ化されます。

      たとえば、ソースまたはターゲットの IP アドレスに基づいて別々のインシデントを作成したい場合や、特定のエンティティと重要度に一致するアラートをグループ化したい場合、この設定を使用できます。

      注: このオプションを選択する場合は、ルールに対して少なくとも 1 つのエンティティ型またはフィールドが選択されている必要があります。 そうしないと、ルールの検証が失敗し、ルールは作成されません。

    3. [Re-open closed matching incidents](クローズされた一致するインシデントを再度開く) :あるインシデントが解決されて閉じられたとします。後でそのインシデントに属するはずの別のアラートが生成されたときに、閉じられたインシデントを再び開きたい場合は、この設定を [有効] に設定します。別のアラートで新しいインシデントを作成する場合は [無効] のままにします。

    注意

    最大 150 件のアラートを 1 つのインシデントにグループ化できます。

    • インシデントが作成されるのは、すべてのアラートが生成された後です。 すべてのアラートは、インシデントの作成時にすぐにそこに追加されます。

    • アラートを 1 つのインシデントにグループ化するルールによって生成されたアラートが 150 件を超える場合は、最初と同じインシデントの詳細を含む新しいインシデントが生成され、超過したアラートは新しいインシデントにグループ化されます。

  3. [Next: Automated response] (次へ: 自動応答) を選びます。

自動応答を設定してルールを作成する

[Automated responses] (自動応答) タブでは、自動化ルールを使用して、次の 3 種類の場合に自動応答を実行するように設定できます。

  • この分析ルールによってアラートが生成されたとき。
  • この分析ルールによって生成されたアラートからインシデントが作成されたとき。
  • この分析ルールによって生成されたアラートを使用してインシデントが更新されたとき。

[自動化ルール] の下に表示されるグリッドには、この分析ルールに既に適用されている自動化ルールが表示されます (これらのルールで定義されている条件を満たしているため)。 ルールの名前または各行の末尾にある省略記号を選択することで、これらの任意のものを編集できます。 または、[+ 新規追加] を選択して、新しいオートメーション ルールを作成することができます。

自動化ルールを使用して、インシデントの基本的なトリアージ、割り当て、ワークフロー、終了を実行します。

これらの自動化ルールからプレイブックを呼び出すことで、より複雑なタスクを自動化し、リモート システムからの応答を呼び出して脅威を修復します。 インシデントと個々のアラートについて、プレイブックを呼び出すことができます。

  • 画面下部の [アラートのオートメーション (クラシック)] の下に、古い方式を使用してアラートが生成されたときに自動的に実行するように構成したプレイブックが表示されます。

    • 2023 年 6 月の時点で、このリストにプレイブックを追加することはできなくなりました。 既にここに記載されているプレイブックは、2026 年 3 月にこの方法が非推奨となるまで実行され続けます。

    • ここに記載されているプレイブックをまだお持ちの場合は、代わりにアラート作成トリガーに基づいて自動化ルールを作成し、その自動化ルールからプレイブックを呼び出す必要があります。 完了したら、ここに記載されているプレイブックの行の末尾にある省略記号を選択し、[削除] を選択します。 詳細な手順については、「Microsoft Sentinel のアラートトリガー プレイブックをオートメーション ルールに移行する」を参照してください。

[次へ: 確認と作成] を選択して新しい分析ルールのすべての設定を確認します。 "検証に成功しました" のメッセージが表示されたら、[作成] を選びます。

ルールとその出力を表示する

ルール定義を表示します。

  • 新しく作成されたカスタムルール (種類は "スケジュールされた") は、メインの [分析] 画面の [アクティブなルール] タブの下のテーブルにあります。 この一覧から、各ルールを有効にしたり、無効にしたり、削除したりできます。

ルール検証の結果を表示します。

  • Azure portal で作成した分析ルールの結果を表示するには、[インシデント] ページに移動します。ここで、インシデントをトリアージし、調査し、脅威を修復できます。

ルールを調整します。

注意

Microsoft Sentinel で生成されたアラートは、Microsoft Graph Security を通じて使用できます。 詳細については、Microsoft Graph のセキュリティ アラートのドキュメントを参照してください。

ルールを ARM テンプレートにエクスポートする

ルールをコードとして管理およびデプロイするようにパッケージ化する場合は、簡単にルールを Azure Resource Manager (ARM) テンプレートにエクスポートできます。 また、ルールをユーザー インターフェイスに表示して編集するために、テンプレート ファイルからインポートすることもできます。

次のステップ

分析ルールを使用して Microsoft Sentinel から脅威を検出する場合は、セキュリティが環境全体に確実に適用されるように、接続されたデータ ソースに関連付けられているすべてのルールを必ず有効にしてください。

ルールの有効化を自動化するには、API および PowerShell 経由で Microsoft Sentinel にルールをプッシュすることもできますが、それを行うには追加の作業が必要です。 API または PowerShell を使用する場合は、ルールを有効にする前に、最初にルールを JSON にエクスポートする必要があります。 API または PowerShell は、Microsoft Sentinel の複数のインスタンスでルールを有効にし、各インスタンスの設定を同じにする場合に役立つことがあります。

詳細については、以下を参照してください:

また、カスタム コネクタで Zoom を監視するするときにカスタム分析ルールを使用する例も参照してください。