Microsoft Sentinel で分析ルールを作成してカスタマイズする

完了

Microsoft Sentinel にデータ ソースを接続した後、環境内の脅威や異常な動作を検出するために役立つカスタム分析ルールを作成します。

分析ルールでは、環境全体にわたる特定のイベントまたは一連のイベントを検索したり、特定のイベントしきい値または条件に達したときはユーザーに警告したり、SOC でトリアージと調査を行うためのインシデントを生成したり、自動化された追跡および修復プロセスを使用して脅威に対応したりします。

スケジュールされたクエリを使用してカスタム分析ルールを作成する

  1. Microsoft Sentinel のナビゲーション メニューから [分析] を選択します。

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

スケジュールされたクエリを実行する方法の例を示すスクリーンショット。

分析ルール ウィザード - [全般] タブ

  • 一意の [名前] と [説明] を指定します。
  • [戦術と手法] フィールドでは、ルールを分類する攻撃のカテゴリを選択できます。 これらは、MITRE ATT&CK フレームワークの戦術と手法に基づいています。
  • MITRE ATT&CK の戦術と手法にマップされたルールによって検出されたアラートから作成されたインシデントは、そのルールのマッピングを自動的に継承します。
  • 必要に応じて、アラートの [重大度] を設定します。
    • 情報。 システムに影響はありませんが、情報は、脅威アクターによって計画された将来の手順を示している可能性があります。
    • 低 。 即時の影響は最小です。 脅威アクターは、環境への影響を達成する前に、複数の手順を実行する必要がある可能性があります。
    • 中間。 脅威アクターは、このアクティビティを使用して環境に何らかの影響を与える可能性がありますが、スコープが制限されるか、追加のアクティビティが必要になります。
    • 高 。 特定されたアクティビティは、脅威アクターに、環境に対するアクションを実行するための幅広いアクセスを提供するか、環境への影響によってトリガーされます。
  • 重大度レベルの既定値は、現在のまたは環境への影響レベルを保証するものではありません。 アラートの詳細をカスタマイズして、クエリ出力の関連フィールドの値を使用して、アラートの特定のインスタンスの重大度、戦術、およびその他のプロパティをカスタマイズします。
  • Microsoft Sentinel 分析ルール テンプレートの重大度定義は、分析ルールによって作成されたアラートにのみ関連します。 他のサービスから取り込まれたアラートの場合、重大度はソース セキュリティ サービスによって定義されます。
  • ルールを作成すると、その [状態] は既定で [有効] になります。これは、作成が終わるとすぐに実行されることを意味します。 すぐに実行したくない場合は、 [無効] を選択します。ルールは [アクティブな規則] タブに追加され、必要に応じてそこから有効にすることができます。

新しいルールを作成する方法の例を示すスクリーンショット。

ルールのクエリ ロジックを定義して設定を構成する

[ルールのロジックを設定] タブでは、 [ルールのクエリ] フィールドにクエリを直接入力するか、または Log Analytics でクエリを作成し、コピーしてフィールドに貼り付けることができます。

  • クエリは Kusto クエリ言語 (KQL) で作成します。
  • このスクリーンショットに示されている例では、SecurityEvent テーブルにクエリを実行して、失敗した Windows ログオン イベントの種類を表示します。

ルール ロジックを設定する方法の例を示すスクリーンショット。

もう 1 つ、異常な数のリソースが Azure アクティビティで作成されたときにアラートを発するサンプル クエリを次に示します。

Kusto

AzureActivity

| where OperationNameValue == "MICROSOFT.COMPUTE/VIRTUALMACHINES/WRITE" or OperationNameValue == "MICROSOFT.RESOURCES/DEPLOYMENTS/WRITE"

| where ActivityStatusValue == "Succeeded"

| make-series dcount(ResourceId) default=0 on EventSubmissionTimestamp in range(ago(7d), now(), 1d) by Caller

重要

クエリでは、ネイティブ テーブルではなく、高度なセキュリティ情報モデル (ASIM) パーサーを使用することをお勧めします。 これにより、クエリは、1 つのデータ ソースではなく、現在または将来の関連するデータ ソースをサポートします。

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

  • クエリの長さは 1 から 10,000 文字にする必要があります。また、search * または union * を含めることはできません。 ユーザー定義関数を使用すると、クエリの長さの制限を克服できます。
  • ADX 関数を使用して Log Analytics クエリ ウィンドウ 内で Azure Data Explorer クエリを作成することは、サポートされていません。
  • クエリで bag_unpack 関数を使用するとき、project field1 を使用して列をフィールドとして投影し、その列が存在しない場合、クエリは失敗します。 このような事態を防ぐために、次のように列を射影する必要があります。
    • project field1 = column_ifexists("field1","")

アラート エンリッチメント

  • エンティティ マッピング構成に関するセクションを参考にして、クエリ結果からのパラメーターを Microsoft Sentinel で認識しているエンティティにマッピングします。 エンティティにより、ルールの出力 (アラートとインシデント) が、その後の調査プロセスと修正アクションの構成要素として機能する重要な情報で強化されます。 また、[インシデントの設定] タブでアラートをインシデントにグループ化できる基準でもあります。
  • [カスタムの詳細] 構成セクションを使用すると、クエリからイベント データ項目を抽出し、このルールによって生成されるアラートにそれらを表示できます。これにより、アラートとインシデントでイベント コンテンツをすぐに確認できます。
  • [アラートの詳細] 構成セクションを使用して、アラートのプロパティの既定値を基になるクエリ結果の詳細でオーバーライドします。 アラートの詳細を使用すると、たとえば攻撃者の IP アドレスやアカウント名をアラート自体のタイトルに表示できます。したがって、インシデント キューに表示され、脅威状況をより明確にはっきりと把握できます。

Note

アラート全体のサイズ制限は 64 KB です

  • 64 KB を超えるアラートは切り捨てられます。 エンティティが識別されると 1 つずつアラートに追加され、アラート サイズが 64 KB に達すると、残りのエンティティはアラートから削除されます。
  • 他のアラート エンリッチメントもアラートのサイズに影響します。
  • アラートのサイズを小さくするには、クエリで project-away 演算子を使用して、不要なフィールドをすべて削除します。 (保持する必要があるフィールドが少数しかない場合は、project 演算子も検討してください。)

クエリのスケジュール設定とアラートのしきい値

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

スケジュールされた新しいルールを作成する例を示すスクリーンショット。

  • [クエリの実行間隔] の設定では、クエリが実行される頻度 (5 分間隔の高頻度や、14 日に 1 回の低頻度) を制御します。
  • [次の時間分の過去のデータを参照します] の設定では、クエリの対象となるデータの期間を決定します。たとえば、過去 10 分間のデータや、過去 6 時間のデータのクエリを実行できます。 最大値は 14 日です。
  • 新しい [実行の開始] 設定 (プレビュー段階) に関して:
    • ルールは作成直後に初めて実行され、その後は [クエリの実行間隔] 設定で設定されている間隔で実行されるという元の動作を続行するには、これを [自動的] に設定したままにします。
    • ルールをすぐに実行するのではなく、最初にルールを実行するのはいつなのかかを決定する場合は、
    • スイッチを特定の時刻に切り替えます。 次に、カレンダー選択機能を使用して日付を選択し、例に示されている形式で時刻を入力します。

クエリ スケジュール パラメーターを構成する方法の例を示すスクリーンショット。

ルールが最初に実行されたら、その後の実行は指定された間隔で行われます。

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

クエリ間隔とルックバック期間

これら 2 つの設定は、ある程度まで互いに独立しています。 間隔より長い期間をカバーする短い間隔でクエリを実行できますが (重複するクエリがある場合)、カバレッジ期間を超える間隔でクエリを実行することはできません。そうしないと、クエリ カバレッジ全体にギャップが生じることになります。

インジェストの遅延

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

ルールの感度を定義するには、 [アラートのしきい値] セクションを使用します。 たとえば、クエリが実行されるたびに 1,000 件を超える結果が返される場合にのみアラートを生成するルールが必要な場合は、 [クエリ結果件数でアラートを生成する] を [次の値より大きい] に設定し、数値の 1,000 を入力します。 これは必須フィールドなので、しきい値を設定しない場合、つまりアラートですべてのイベントを登録する場合は、数値のフィールドに「0」を入力します。

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

[インシデントの設定] タブでは、アラートをアクションにつながるインシデントに変換するかどうか、およびその方法を選択できます。 このタブを設定しないと、すべてのアラートに対して個別に 1 つのインシデントが作成されます。 このタブの設定を変更することで、インシデントを作成しないようにしたり、複数のアラートを 1 つのインシデントにグループ化したりすることができます。

インシデントの設定

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

  • このルールによってインシデントが作成されないようにする場合は (たとえば、このルールが後続の分析のために情報を収集するだけの場合)、これを [無効] に設定します。
  • 単一のインシデントをアラートごとにではなく、アラートのグループから作成する場合は、次のセクションをご覧ください。

アラートのグループ化

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

  • [選択した期間内に作成されたアラートのみにグループを制限する] :似たアラートまたは繰り返し発生するアラートをグループ化する期間を決定します。 この期間内の対応するすべてのアラートでは、1 つのインシデントまたはインシデントのセットがまとめて生成されます (以下のグループ化の設定に依存します)。 この期間外のアラートでは、個別のインシデントまたはインシデントのセットが生成されます。
  • [この分析ルールによってトリガーされるアラートを次の方法で単一のインシデントにグループ化する] :アラートをグループ化する基準を選択します。
オプション 説明
すべてのエンティティが一致した場合にアラートを 1 つのインシデントにグループ化する (上の [ルールのロジックを設定] タブに定義された) マップされている各エンティティに関して同じ値を共有している場合、アラートはグループ化されます。 これは推奨される設定です。
このルールによってトリガーされるすべてのアラートを 1 つのインシデントにグループ化する 値が同じではない場合でも、このルールによって生成されるすべてのアラートをグループ化します。
選択したエンティティと詳細が一致する場合にアラートを 1 つのインシデントにグループ化する マップされたエンティティ、アラートの詳細、および各ドロップダウン リストから選択されたカスタムの詳細のすべてに関して同じ値を共有している場合、アラートはグループ化されます。

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

注: このオプションを選択する場合は、ルールに対して少なくとも 1 つのエンティティ型またはフィールドが選択されている必要があります。 そうしないと、ルールの検証が失敗し、ルールは作成されません。
  • [Re-open closed matching incidents](クローズされた一致するインシデントを再度開く) :あるインシデントが解決されて閉じられたとします。後でそのインシデントに属するはずの別のアラートが生成されたときに、閉じられたインシデントを再び開きたい場合は、この設定を [有効] に設定します。別のアラートで新しいインシデントを作成する場合は [無効] のままにします。

注意

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

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

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

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

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

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

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

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

自動応答を構成する方法の例を示すスクリーンショット。

  • 画面下部の [アラートのオートメーション (クラシック)] の下に、古い方式を使用してアラートが生成されたときに自動的に実行するように構成したプレイブックが表示されます。
    • 2023 年 6 月の時点で、このリストにプレイブックを追加することはできなくなりました。 既にここに記載されているプレイブックは、2026 年 3 月にこの方法が非推奨となるまで実行され続けます。
    • ここに記載されているプレイブックをまだお持ちの場合は、代わりにアラート作成トリガーに基づいて自動化ルールを作成し、そこからプレイブックを呼び出す必要があります。 完了したら、ここに記載されているプレイブックの行の末尾にある省略記号を選択し、[削除] を選択します。

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

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

  • 新しく作成された ("Scheduled" 型の) カスタム ルールは、メインの [分析] 画面の [アクティブなルール] タブの下の表内で確認できます。 この一覧から、各ルールを有効にしたり、無効にしたり、削除したりできます。
  • 作成した分析ルールの結果を表示するには、[インシデント] ページに移動します。ここでは、インシデントのトリアージ、インシデントの調査、脅威の修復を行うことができます。
  • ルール クエリを更新して、偽陽性を除外できます。