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

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

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

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

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

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

主な用語

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

始める前に

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

  • 権限: ルール スケジュールを変更するには、次の IAM 権限が必要です。

    • 個々のスケジュール更新の API 使用のための chronicle.ruleDeployments.update。

    • バッチ API 更新と UI 使用のための chronicle.rules.modifyRules。

    Chronicle API 管理者（roles/chronicle.admin）や Chronicle API 編集者（roles/chronicle.editor）などの事前定義された IAM ロールを使用している場合、これらの権限は自動的に付与されます。

  • 環境チェック:

    • ルールタイプ: カスタマイズ可能なスケジュールは、マルチイベント ルールにのみ適用されます。単一イベント ルールとキュレートされたルールは除外されます。
    • 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] 切り替えボタンをオンにします。
    • 予想される失敗: オフセットがソースの実際の取り込みレイテンシよりも短い場合、初回実行でログが欠落する可能性があります。
    • 修正手順: オフセットを増やすか、最終検証で調整実行に依存します。
  6. [Ensure enrichment completeness] 切り替えボタンをオンにします。
    • 予想される失敗: アラートがイベントのタイムスタンプよりも大幅に遅れて表示されることがあります。
    • 修正手順: 速度よりも精度が重要な、重要度の低いコンプライアンス ルールにのみ使用してください。
  7. [Rule schedule preview] で実行タイムラインを確認します。
    • 初回実行（𝑇 + オフセット）: 遅延到着データに指定した遅延の後、システムはルールロジックを実行します。
    • 調整実行 1（𝑇 + 4 時間）: システムは初回実行から 4 時間後にウィンドウを再スキャンして、欠落したデータや遅延したデータをキャプチャします。[Ensure enrichment completeness] 切り替えボタンをオンにすると、この実行では、関連するすべての拡充データが処理されるまで待機します。
    • 調整実行 2（𝑇 + 30 時間）: この実行は、[Ensure enrichment completeness] 切り替えボタンをオンにした場合にのみ表示されます。システムは初回実行から 30 時間後に最終スキャンを実行して、データの忠実度を最大限に高めます。
  8. [保存] をクリックします。

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

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

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

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

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

検出ソースを特定する

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

検出インジケーター

In the [Detection type] column, the は、調整実行、再処理実行、遡及的な検索による検出を示します。

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

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

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

トラブルシューティング

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

検出は調整実行でのみ表示される

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

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

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

[Rule schedule] タブにカスタマイズ オプションが表示されない場合や、メニューがグレー表示になっている場合は、次のことを確認してください。

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

初回実行アラートの遅延が予想外に発生する

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

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

MTTD の測定値が高い

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

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

制限事項

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

エラーの修復

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

検証とテスト

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

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

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