脅威を検出するためのカスタム分析規則を作成する

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

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

ヒント

カスタム ルールを作成する場合は、既存のルールをテンプレートとして、または参照用に使用します。 既存のルールをベースラインとして使用すると、ほとんどのロジックを構築した後で、必要な変更を加えることができます。

  • 分析ルールを作成する
  • イベントとアラートの処理方法を定義する
  • アラートとインシデントの生成方法を定義する
  • ルールに対して脅威への自動対応を選択する

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

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

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

    スケジュール済みクエリを作成する

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

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

  • [方針] フィールドでは、ルールを分類する攻撃のカテゴリを選択できます。 これらは、MITRE ATT&CK フレームワークの方針に基づいています。

  • 必要に応じて、アラートの [重大度] を設定します。

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

    カスタム分析ルールの作成を開始する

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

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

  • クエリは Kusto クエリ言語 (KQL) で作成します。 KQL の概念クエリの詳細については、この便利なクイック リファレンス ガイドに関するページを参照してください。

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

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

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

    AzureActivity
    | where OperationName == "Create or Update Virtual Machine" or OperationName =="Create Deployment"
    | where ActivityStatus == "Succeeded"
    | make-series dcount(ResourceId)  default=0 on EventSubmissionTimestamp in range(ago(7d), now(), 1d) by Caller
    

    注意

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

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

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

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

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

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

重要

アラート エンリッチメント機能は、現在 プレビュー 段階です。 ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用されるその他の法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。

  • クエリ結果のパラメーターを Azure Sentinel で認識されるエンティティにマップするには、 [エンティティのマッピング] 構成セクションを使用します。 エンティティにより、ルールの出力 (アラートとインシデント) が、その後の調査プロセスと修正アクションの構成要素として機能する重要な情報で強化されます。 また、 [インシデントの設定] タブでアラートをインシデントにグループ化するための条件でもあります。

    Azure Sentinel のエンティティについて詳しく確認します。

    エンティティのマッピングの詳細な手順と、下位互換性に関する重要な情報については、「データ フィールドを Azure Sentinel のエンティティにマップする」をご覧ください。

  • [カスタムの詳細] 構成セクションを使用すると、クエリからイベント データ項目を抽出し、このルールによって生成されるアラートにそれらを表示できます。これにより、アラートとインシデントでイベント コンテンツをすぐに確認できます。

    アラートにカスタムの詳細を表示する詳細については、詳細な手順を参照してください。

  • [アラートの詳細] 構成セクションは、アラートの表示詳細を実際のコンテンツに合わせて調整するために使用します。 アラートの詳細を使用すると、たとえば攻撃者の IP アドレスやアカウント名をアラート自体のタイトルに表示できます。したがって、インシデント キューに表示され、脅威状況をより明確にはっきりと把握できます。

    詳細な手順については、アラート詳細のカスタマイズに関するページを参照してください。

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

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

    クエリのスケジュールとイベントのグループ化の設定

    • [クエリの実行間隔] の設定では、クエリが実行される頻度 (頻繁な 5 分間隔、または 14 日に 1 回程度の低い頻度) を制御します。

    • [次の時間分の過去のデータを参照します] の設定では、クエリの対象となるデータの期間を決定します。たとえば、過去 10 分間や過去 6 時間のデータのクエリを実行できます。 最大値は 14 日です。

      注意

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

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

      インジェストの遅延

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

      この遅延が必要になる理由とこの問題を解決する方法の技術的な詳細については、Ron Marsiano による Azure Sentinel のスケジュールされたアラート ルールでのインジェストの遅延を処理する方法に関するすばらしいブログ投稿をご覧ください。

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

結果のシミュレーション

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

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

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

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

イベントのグループ化とルールの抑制

重要

現在、イベントのグループ化は プレビュー段階 にあります。 ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用されるその他の法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。

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

    • [すべてのイベントを単一のアラートにグループ化する] (既定の設定)。 このルールでは、クエリで前記の アラートのしきい値 よりも多くの結果が返される限り、実行されるたびに 1 つのアラートが生成されます。 このアラートには、結果で返されたすべてのイベントの概要が含まれています。

    • [各イベントに対するアラートをトリガーする] 。 このルールでは、クエリによって返されるイベントごとに独自のアラートが生成されます。 これは、イベントを個々に表示する場合や、ユーザーやホスト名など、特定のパラメーター別にイベントをグループ化する場合に便利です。 これらのパラメーターはクエリ内で定義できます。

      現在のところ、1 つのルールで生成できるアラートの数は 20 に制限されています。 特定のルールで、 [イベントのグループ化][各イベントに対するアラートをトリガーする] に設定されていて、ルールのクエリから 20 を超えるイベントが返された場合、最初の 19 件のイベントについてはそれぞれに独自のアラートが生成され、20 番目のアラートでは、返された一連のイベント全体がまとめられます。 言い換えると、20 番目のアラートは、 [すべてのイベントを単一のアラートにグループ化する] オプションによって生成されたであろうアラートです。

      このオプションを選択すると、Azure Sentinel によって、新しいフィールド [OriginalQuery] がクエリの結果に追加されます。 既存の [Query] フィールドと新しいフィールドの比較を次に示します。

      フィールド名 内容 このフィールドでクエリを実行した場合の
      結果
      クエリ このアラート インスタンスを生成したイベントの圧縮レコード このアラート インスタンスを生成したイベント
      OriginalQuery 分析 ルールに記述されている元のクエリ クエリによって定義されたパラメーターに適合する、クエリが実行される時間枠内で最新のイベント

      つまり、OriginalQuery フィールドは、Query フィールドの通常の動作と同様に動作します。 この追加フィールドの結果として、下のトラブルシューティング セクションの最初の項目で説明されている問題が解決されました。

    注意

    イベントアラート の違いは何でしょうか。

    • イベント は、アクションの 1 回の出現を表します。 たとえば、ログ ファイル内の 1 つのエントリは、1 つのイベントとしてカウントされる可能性があります。 このコンテキストでは、1 つのイベントは、分析ルールのクエリによって返された単一の結果を指します。

    • アラート は、一緒にまとめられるイベントのコレクションで、セキュリティの観点からは重要なものです。 イベントにセキュリティ上の重要な意味がある場合は、1 つのアラートに 1 つのイベントが含まれる場合があります。たとえば、勤務時間外に外国からの管理ログインがあったなどです。

    • では、インシデント とは何でしょうか。 Azure Sentinel の内部ロジックでは、アラート またはアラートのグループから インシデント が作成されます。 インシデント キューは、トリアージ、調査、修復といった SOC アナリストの作業の中心です。

    Azure Sentinel は、いくつかのデータ ソースから未加工のイベントを取り込み、他のデータ ソースから処理済みのアラートを取り込みます。 ある時点で、どちらを扱っているかに注目することが重要です。

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

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

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

重要

インシデントの設定のタブは、現在、プレビュー段階 にあります。 ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用されるその他の法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。

次に例を示します。

インシデントの作成とアラートのグループ化の設定を定義する

インシデントの設定

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

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

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

アラートのグループ化

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

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

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

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

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

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

    注意

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

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

  1. [Automated responses](自動応答) タブでは、この分析ルールによって生成された 1 つまたは複数のアラートに基づいて、またはアラートによって作成されたインシデントに基づいて、自動化を設定できます。

    • アラート ベースの自動化の場合は、 [Alert automation](アラート自動化) の下にあるドロップダウン リストから、アラートが生成されたときに自動的に実行するプレイブックを選択します。
    • インシデントベースの自動化では、 [Incident automation (preview)](インシデント自動化 (プレビュー)) で自動化ルールを選択または作成します。 これらの自動化ルールからプレイブック (インシデント トリガー に基づくもの) を呼び出したり、トリアージ、割り当て、終了を自動化したりすることもできます。
    • プレイブックと自動化ルールを作成する方法の詳細と手順については、「脅威への対応を自動化する」を参照してください。
    • アラート トリガー または インシデント トリガー を使用するタイミングの詳細については、「Azure Sentinel プレイブックでトリガーとアクションを使用する」を参照してください。

    自動応答の設定を定義する

  2. [確認と作成] を選択して新しいアラート ルールのすべての設定を確認します。 "検証に成功しました" というメッセージが表示されたら、 [作成] を選択してアラート ルールを初期化します。

    すべての設定を確認してルールを作成する

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

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

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

  • ルール クエリを更新して、偽陽性を除外できます。 詳細については、「Azure Sentinel での偽陽性の処理」を参照してください。

注意

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

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

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

トラブルシューティング

問題点:クエリ結果にイベントが表示されない

[イベント グループ化][各イベントに対するアラートをトリガーする] に設定されている場合、一部のシナリオでは、後でクエリ結果を表示するときに (インシデントからアラートに戻るときなど)、クエリ結果が表示されない可能性があります。 これは、イベントのアラートへの接続が、特定のイベントの情報のハッシュ化と、クエリにそのハッシュを含めることによって行われるためです。 アラートが生成された後にクエリ結果が変わった場合、ハッシュは無効になり、結果は表示されません。

イベントを表示するには、ルールのクエリからハッシュを含む行を手動で削除し、クエリを実行します。

注意

この問題は、このイベントのグループ化オプションが選択されるときに新しいフィールド OriginalQuery を結果に追加することによって解決されました。 上記の説明を参照してください。

問題点:スケジュールされたルールの実行に失敗するか、名前に「自動無効化」が追加される

スケジュールされたクエリ ルールの実行が失敗することはめったにありませんが、発生する可能性があります。 Azure Sentinel は、具体的な障害の種類とそれを引き起こした状況に基づいて、障害を一時的または永続的として事前に分類します。

一時的な障害

一時的な障害は、一時的な状況が原因で発生し、すぐに正常な状況に戻ります。その時点で、ルールの実行は成功します。 Azure Sentinel によって一時的として分類される障害の例を次に示します。

  • ルール クエリの実行に時間がかかりすぎて、タイムアウトになった。
  • データ ソースと Log Analytics 間、または Log Analytics と Azure Sentinel 間の接続に問題がある。
  • その他の新規および不明な障害は一時的なものと見なされます。

一時的な障害が発生した場合、Azure Sentinel では、(ある時点まで) 毎回増分するように事前定義された間隔で、ルールの実行が再試行し続けられます。 その後、ルールは次回のスケジュールされた時刻にのみ再び実行されます。 一時的な障害が原因で、ルールが自動的に無効になることはありません。

永続的な障害 - ルールの自動無効化

永続的な障害は、ルールの実行を許可する条件が変更されたことが原因で発生します。これは、ユーザーの介入なしでは元の状態に戻りません。 永続的として分類される障害の例をいくつか次に示します。

  • (ルール クエリが運用されている) ターゲット ワークスペースが削除された。
  • (ルール クエリが運用されている) ターゲット テーブルが削除された。
  • Azure Sentinel がターゲット ワークスペースから削除された。
  • ルール クエリで使用される関数が有効ではなくなった (変更または削除された)。
  • ルール クエリのいずれかのデータ ソースに対するアクセス許可が変更された。
  • ルール クエリのいずれかのデータ ソースが削除または切断された。

同じルールに対して同じ種類の永続的な障害が事前に指定されている回数連続して発生した場合、Azure Sentinel ではルールの実行が停止され、次の手順も実行されます。

  • ルールを無効にします。
  • ルールの名前の先頭に「自動無効化」という単語を追加します。
  • 障害 (および無効化) の理由をルールの説明に追加します。

ルールの一覧を名前で並べ替えると、自動無効化されたルールがあるかどうかを簡単に確認することができます。 自動無効化されたルールは、一覧の先頭付近にあります。

SOC マネージャーは、自動無効化されたルールがあるかどうかについて、ルールの一覧を定期的に確認する必要があります。

次のステップ

Azure Sentinel から分析ルールを使用して脅威を検出する場合は、接続されたデータ ソースに関連付けられているすべてのルールを有効にして、環境全体にセキュリティを適用できるようにしてください。 最も効率的に分析ルールを有効にする方法として、関連するルールがすべて一覧表示されているデータ コネクタ ページから直接行います。 詳細については、「データ ソースの接続」を参照してください。

また、APIPowerShell を介して Azure Sentinel にルールをプッシュすることもできます。ただし、それには追加の作業が必要になります。 API または PowerShell を使用する場合は、ルールを有効にする前に、まずルールを JSON にエクスポートする必要があります。 API または PowerShell は、Azure Sentinel の複数のインスタンスでルールを有効にし、各インスタンスで同じ設定を使用する場合に役立つ可能性があります。

詳細については、次を参照してください。

詳細については、次を参照してください。

また、カスタム コネクタZoom を監視するときのカスタム分析ルールの使用例もご覧ください。