ルールの割り当てについて

以下でサポートされています。

Google Security Operations は、検出ルールの容量制限を適用して、一貫したシステム パフォーマンスとクエリ速度を確保します。

ルール容量は、次の 2 つのカテゴリで管理されます。

  • カスタムルール: チームが作成して管理するルール。

  • キュレーテッド検出: Google が作成、管理するルール。

カスタムルールの割り当てを追跡する

カスタムルールには、複雑さに基づいて厳格なパフォーマンス割り当てが適用されます。

カスタムルールの割り当てを追跡する手順は次のとおりです。

  1. Google SecOps で、[検出] > [ルールと検出] に移動します。

  2. [ルール ダッシュボード] タブに移動します。

  3. [ルールの容量] をクリックして、[マルチイベント ルールの割り当て] ダイアログを開きます。マルチイベント ルールルールの合計の割り当てが表示されます。

割り当てタイプ 説明 割り当てにカウントされるもの
ルールの合計割り当て 環境で有効にできるルールの最大数。 有効なすべてのルール: シングル イベントとマルチイベント。
マルチイベント ルールの割り当て マルチイベント ルール用に予約された合計割り当ての制限付きサブセット。 マルチイベント ルールのみ: 複数のイベントを時間経過とともに相関付けたり、結合を使用したり、ウィンドウ集計を実行したりするルール(一致セクションを含むルールなど)。

マルチイベント ルールは、単一イベント ルールよりもはるかに多くのリソースを消費します。合計割り当てには空き容量があっても、マルチイベント割り当てを使い切っている場合は、新しいルールを有効にできないことがあります。

キュレーテッド検出の割り当てを追跡する

キュレーションされた検出は、Enterprise と Enterprise Plus をご利用のお客様が対象です。ライセンスの利用資格は、キュレートされたルールセットのライブラリ全体に対応するように明示的にサイズ設定されています。ダッシュボードには容量または重みの指標が表示されますが、これらの数値は情報提供を目的としたものであり、ハードリミットではありません。

Enterprise と Enterprise Plus をご利用のお客様の場合、ライセンスの利用資格は、キュレートされたルールセットのライブラリ全体に対応できるように明示的にサイズ設定されています。ダッシュボードには容量または重みの指標が表示されますが、これらの数値は情報提供を目的としたものであり、厳密な上限ではありません。

パフォーマンスのトレードオフや容量の上限に達するリスクを冒すことなく、すべてのキュレートされたルールセットを同時に有効にできます。上限に関する警告がトリガーされた場合は、ライセンス パッケージの構成を確認します。

システム パフォーマンスの最適化

このセクションでは、ルール容量とシステム パフォーマンスを最大化するための最適化戦略について説明します。

複雑なロジックをモジュール化する

軽量な単一イベントルールを作成して、アトミックな動作にフラグを設定します。つまり、未加工のログから攻撃のすべてのステージを検出しようとする大規模なマルチイベント ルールを作成しないようにします。

  1. 単一イベントルールでシグナルを検出する

    • 個々の行動(User Login FailedProcess Launched など)に対して単一イベント ルールを作成します。

    • 影響: アクティブな割り当ての合計(十分な量)を消費し、ほぼリアルタイムで実行されます。

  2. 複合ルールまたはマルチイベント ルールでアラートを関連付ける

    • 手順 1 で生成された検出結果を入力として使用する複合ルールを作成します。

    • 影響: 複数イベントの割り当てを消費します(高コスト)。

    • メリット: 異なるシナリオで未加工ログを複数回再処理するのではなく、ロジックでマルチイベント割り当てを 1 回使用します。

効率的なルール設計を作成する

  • 単一イベント ロジックを優先する: 1 つのログ行で検出できる場合(「ユーザーが既知の不正なドメインにアクセスした」など)、相関関係のマルチイベント割り当てを節約するために、単一イベント ルールとして記述します。一致ウィンドウの使用を避けます。

  • リファレンス リストを使用する: N 個の指標に対して N 個のルールを使用する代わりに、リファレンス リスト(target.ip in %suspicious_ips など)を参照する単一のルールを使用します。これにより、ルール割り当ての 1 単位のみが消費されます。

  • 定期的な監査を実施する: 一時停止または無効になっているルールを定期的に監査します。アーカイブは有効な割り当てのカウントには含まれませんが、アーカイブすることで環境をクリーンに保つことができます。

ユースケース: ブルート フォースによるラテラル ムーブメントを検出する

シナリオ: Risk Data Platform(RDP)を介してサーバーに侵入しようとし、不審な管理ツール(PsExec など)を直ちに実行して横方向に移動する攻撃者を検出します。

ステップ 1: 単一イベント ルールでシグナルを検出する

十分な合計アクティブ割り当てで実行される軽量ルールを 2 つ作成します。これらは検出を生成します。

  • ルール A(ブルート フォース シグナル):

    • ロジック:

      • auth.status = FAILURE を確認します。

      • グループのログイン イベント。

      • 1 分間に 5 回以上失敗した場合にトリガーします。

    • 入力: 未加工の UDM イベント。

    • 出力: Possible_RDP_Brute_Force という名前の検出アラート。

    • 費用: 低(合計アクティブ割り当てを使用)。

  • ルール B(不審なツールのシグナル):

    • ロジック: プロセスが psexec.exe の場合にトリガーします。

    • 入力: 未加工の UDM イベント。

    • 出力: PsExec_Usage という名前の検出アラート。

    • 費用: 低(アクティブな合計割り当てを使用)。

ステップ 2: アラートと複合ルールを関連付ける

未加工のログではなく、手順 1 で生成された検出を調べる複合ルールを 1 つ作成します。

  • ルール C:

    • ロジック: 10 分以内に同じ principal.hostname で発生する Possible_RDP_Brute_Force AND PsExec_Usage を探します。

    • 入力: ルール A とルール B からの検出。

    • 費用: 高(マルチイベントの割り当てを使用)ですが、ステップ 1 で生成されたアラートのみを処理します。

この階層型アプローチでは、初期シグナルの生成を複雑な相関ロジックから切り離すことで、パフォーマンスと費用対効果の両方を最適化します。単一イベント ルールを使用して数十億件の未加工の UDM イベントをフィルタリングして忠実度の高い検出に変換することで、マルチイベント エンジンで処理されるデータ量を削減できます。

さらにサポートが必要な場合 コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。