ルールにカスタマイズされたスケジュールを構成する

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

このドキュメントは、マルチイベント ルールのカスタマイズ可能なスケジュールを構成してトラブルシューティングを行うプラットフォーム管理者と SOC アナリストを対象としています。処理スケジュールを設定し、追加のチェックを実行して、遅れて到着したデータを含める方法について説明します。

このドキュメントで説明するプロセスに沿って操作すると、検出レイテンシとデータの完全性を正確に制御できます。正常に完了すると、検出がタイムリーかつ正確になり、取り込みの遅延による偽陰性が減少し、一貫したセキュリティ運用が実現します。

カスタマイズ可能なスケジュールにより、Google Security Operations でマルチイベント ルールがどのように実行されるかを可視化し、制御できます。一部のマルチイベント ルールでは、データを正確に集計するためにバッファ期間が必要になる場合があります。この方法では、システムのデフォルトに依存するのではなく、その期間を定義できます。

このドキュメントと合わせて、ルール実行スケジュールの管理方法をご覧ください。

主な用語

  • 最初の実行（𝑇 + オフセット）: ルールロジックの最初の実行。オフセットは、遅れて到着したデータを考慮して追加される遅延を表します。
  • True-up 実行: 最初の実行後に到着したログまたはエンリッチメント データをキャプチャするために、同じ時間枠のバックグラウンドで再評価します。
  • エンリッチメント: 処理中に追加される外部メタデータ（アセットタグやユーザー エイリアスなど）。

始める前に

ルール スケジュールを変更または自動化する前に、環境とアカウントが必要なセキュリティ要件とシステム要件を満たしていることを確認してください。これらの前提条件を検証すると、デプロイ エラーを防ぎ、検出ロジックが組織の Identity and Access Management ポリシーに沿っていることを確認できます。

  • 権限: ルール スケジュールを変更するには、detection:ModifyRuleSchedule アクションを付与する IAM ロールが必要です。

    • roles/detectionEngine.admin

    • roles/detectionEngine.editor

  • 環境チェック:

    • ルールタイプ: カスタマイズ可能なスケジュールは、マルチイベント ルールにのみ適用されます。単一イベント ルールとキュレーテッド ルールは除外されます。
    • match ウィンドウ: match ウィンドウが 48 時間を超えるルールは、毎日 の実行頻度に制限されます。
    • 移行: レガシー スケジュールからカスタマイズ可能なスケジュールへの移行は一方向のプロセスであり、元に戻すことはできません。

マルチイベント ルールのスケジュールを構成する

マルチイベント ルールのスケジュールを構成する手順は次のとおりです。

  1. Google SecOps で、[Detection > Rules & Detections] に移動します。
  2. [Rules Dashboard] をクリックします。
  3. ルールを見つけて、[その他] more_vert をクリックし、[Run schedule] を選択します。
  4. [Rule schedule] タブで、[First run schedule] フィールドの値を選択し、ルールの実行頻度を選択します。
  5. [Adjust first run for late-arriving data] 切り替えをオンにします。
    • 想定される失敗: オフセットがソースの実際の取り込みレイテンシよりも短い場合、最初の実行でログが欠落する可能性があります。
    • 修正手順: オフセットを増やすか、最終検証で True-up 実行に依存します。
  6. [Ensure enrichment completeness] 切り替えをオンにします。
    • 想定される失敗: アラートがイベントのタイムスタンプよりも大幅に遅れて表示されることがあります。
    • 修正手順: 速度よりも精度が重要な、重要度の低いコンプライアンス ルールにのみ使用してください。
  7. [Rule schedule preview] で実行タイムラインを確認します。
    • 最初の実行（𝑇 + オフセット）: 遅れて到着したデータに対して指定した遅延の後、システムはルールロジックを実行します。
    • True-up 実行 1（𝑇 + 4 時間）: システムは最初の実行から 4 時間後にウィンドウを再スキャンして、欠落したデータや遅れて到着したデータをキャプチャします。[Ensure enrichment completeness] 切り替えをオンにすると、この実行では、関連するすべてのエンリッチメント データの処理が完了するまで待機します。
    • True-up 実行 2（𝑇 + 30 時間）: この実行は、[Ensure enrichment completeness] 切り替えをオンにした場合にのみ表示されます。システムは最初の実行から 30 時間後に最終スキャンを実行して、データの忠実度を最大限に高めます。
  8. [保存] をクリックします。

スケジュール プレビューについて

スケジュール プレビューでは、検出ロジックの特定のマイルストーンが特定されます。これらのバックグラウンド実行を使用して、検出までの平均時間（MTTD）を正確に測定し、アラートの整合性を検証します。

  • 最初の実行（𝑇 + オフセット）: 脅威をできるだけ早く特定します。一部のデータは転送中またはエンリッチメント処理中の可能性があるため、最初の実行での検出は予想よりも遅れて到着する可能性があります。

  • True-up 実行: 時間枠をプロアクティブに再評価します。これらの実行により、プラットフォームは次の情報をキャプチャできます。

    • 遅れて到着したログ: 最初の実行が完了した後にプラットフォームに到達したデータ。
    • エンリッチメント コンテキスト: 追加のバックグラウンド処理が必要なメタデータ（アセット ID やユーザー エイリアスなど）。

検出ソースを特定する

Google SecOps では、視覚的なインジケーターを使用して、最初の検出とバックグラウンドの再実行中に検出されたものを区別できます。

検出インジケーター

In the [Detection type] column, the identifies detections from true-up runs, reprocessing runs, or retrohunts.

  • このアイコンが表示されている場合、検出は最初の実行（𝑇）ではなく、True-up 実行（𝑇+4$ または 𝑇+30$）中に行われました。
  • このアイコンが付いた検出は、通常、遅れて到着したログやエンリッチメントの遅延が原因で、最初の取り込み後にプラットフォームが脅威をキャプチャしたことを示します。

[Alerts] ページでアラートの整合性を確認する

On the [Alerts] page, the indicates the alert source. タイムラインを調査するときに、このインジケーターを使用してアラートのソースを確認します。

トラブルシューティング

スケジュールの問題を調査するには、評価のタイミングとルールの構成を確認します。プラットフォームはほとんどのスケジューリング タスクを自動化しますが、特定の設定やデータの遅延によって検出が表示されるタイミングに影響する可能性があります。

検出は True-up 実行でのみ表示される

最初の実行（𝑇）中に検出が表示されず、True-up 実行（𝑇+4$ または 𝑇+30$）に表示される場合は、次のことを確認してください。

  • 取り込みレイテンシ: ログソースに遅延があるかどうかを確認します。イベントの発生から 15 分後にログが到着する場合、10 分の最初の実行スケジュールではログが欠落します。True-up 実行では、これらの遅延した到着をキャプチャします。
  • コンテキスト エンリッチメント: ルールがアセットタグやユーザー エイリアスなどの外部メタデータに依存しているかどうかを確認します。エンリッチメント プロセスが最初の実行ウィンドウよりも時間がかかる場合、検出は、後続の実行でシステムがエンリッチメントを完了した後にのみ表示されます。

カスタマイズ可能なオプションがない

[Rule schedule] タブにカスタマイズ オプションが表示されない場合や、メニューがグレー表示になっている場合は、次の操作を行います。

  • ルールタイプを確認する: カスタマイズ可能なスケジュールは、マルチイベント ルールにのみ適用されます。単一イベント ルールは継続（リアルタイム）エンジンを使用し、カスタム スケジュールはサポートしていません。
  • `match` ウィンドウを確認する: `match` ウィンドウが 48 時間を超えるルールは、毎日 の実行頻度に制限され、カスタマイズできません。matchmatch
  • キュレーテッド ルールを特定する: キュレーテッド ルールのスケジュールは変更できません。Curated rules uses a legacy schedule メッセージを探して、ルールが保護されたシステムルールかどうかを確認します。

最初の実行アラートで予期しない遅延が発生する

検出がスケジュールされた間隔よりも遅れて到着する場合は、次のことを確認してください。

  • 初期化期間: 新しいルールまたは最近変更されたルールには、1 時間の初期化期間が必要です。プラットフォームがこの初期設定を完了し、最初のスケジュールされたサイクルを開始するまで、検出は表示されません。
  • エンリッチメントの待機時間: Ensure enrichment completeness の切り替えをオンにすると、システムはデータの拡充プロセスが完了するまで待機するようにタイミングを動的に調整することがあります。このプロセスでは検出の欠落を防ぐことができますが、最初の検出が正確な 𝑇 タイムスタンプよりも遅れて到着する可能性があります。

MTTD の測定値が高い

MTTD の測定には、データの完全性に必要なバッファ期間が含まれます。

  • バッファを確認する: 1 時間のスケジュールの場合、システムはイベントの到着から 1 ～ 2 時間後にイベントを評価します。
  • 速度を最適化する: レイテンシを短縮する必要がある場合は、ルールをリアルタイム スケジュールに移行します。注: これにより、完全な精度を得るために True-up 実行に依存する検出の数が増える可能性があります。

制限事項

  • マルチイベント ルールのみ: この機能は、単一イベント ルールでは使用できません。
  • カスタムルールのみ: キュレーテッド ルールは、変更できない固定スケジュールを使用します。キュレーテッド ルールを表示すると、Curated rules use a legacy schedule というメッセージが表示されます。

エラーの修復

エラー 問題 修正
オプションがない [Rule schedule] タブがグレー表示になっているか、オプションが表示されません。 ルールがマルチイベント カスタムルールであり、一致ウィンドウが 48 時間未満であることを確認します。
アラートの遅延 検出がスケジュールされた間隔よりも遅れて到着します。 [Ensure enrichment completeness] 切り替えがオンになっているかどうかを確認します。システムがメタデータ処理を待機している可能性があります。
True-up アラートのみ 最初の実行（𝑇）で検出が表示されません。 [Ingestion Latency] をクリックして確認します。ログの到着が 15 分遅れていて、オフセットが 10 分の場合は、最初の実行のオフセットを増やします。

検証とテスト

スケジュールが意図したとおりに動作していることを確認する手順は次のとおりです。

  1. [Rules Dashboard] に移動します。
  2. ルールを選択し、[Detections] タブを表示します。
  3. でフィルタして、True-up 実行で最初の実行で欠落したデータがキャッチされているかどうかを確認し、必要に応じてオフセットを調整します。

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