ルールのパフォーマンスを最適化する

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

このドキュメントでは、検出とレポートのパフォーマンスを最適化する方法について説明します。

合計検出レイテンシ

セキュリティ オペレーション センター（SOC）の場合、合計平均検出時間（MTTD）は、セキュリティ パイプライン全体の遅延時間の合計です。MTTD を正確に測定して短縮するには、次の 3 つの主要なコンポーネントを追跡する必要があります。

ログ取り込みのレイテンシ（ログの作成からデータの取り込みまで）

ログ取り込みのレイテンシとは、ソースシステムでセキュリティ イベントが発生した時点（metadata.event_timestamp）から、Google Security Operations でログが正常に取り込まれて解析された時点（metadata.ingested_time）までの経過時間です。

要因:

  • コレクタまたはフォワーダーの問題（バックログやネットワーク スロットリングなど）。
  • ログソースの解析の問題（UDM の正規化の遅延など）。

ログ取り込みのレイテンシを短縮するには、次の操作を行います。

  • ログソースの健全性をモニタリングし、コレクタまたはフォワーダーの構成を最適化します。
  • 差分をモニタリングするには、YARA-L または Data Lake で UDM タイムスタンプ（metadata.ingested_timestamp と metadata.event_timestamp）を比較します。

ルール処理のレイテンシ（データの取り込みから検出の作成まで）

ルール処理のレイテンシとは、データの取り込みから検出エンジンがアラートを正常に作成するまでの経過時間（detection.creation_time）です。このコンポーネントは、YARA-L ルールの構成に大きく影響されます。

要因:

  • ルールの実行頻度: 準リアルタイム（最小レイテンシ）、10 分、1 時間、または match_window / 10（一致ウィンドウが 48 時間を超える場合）。詳細については、ルールの実行スケジュールの概要をご覧ください。
  • ルールの種類と複雑さ: マルチイベント ルールを完全に処理するには一致ウィンドウが必要なため、固有のレイテンシが発生します。他のリアルタイム以外の検出に依存する複合ルールでも遅延が発生します。詳細については、複合検出をご覧ください。

ルール処理のレイテンシを短縮するには、次の操作を行います。

  • 可能な場合は、準リアルタイムで実行される単一イベント ルールを使用します。
  • マルチイベント ルールの場合は、可能な限り小さいウィンドウ サイズを設定します。

詳細については、ダッシュボード用の YARA-L 2.0 クエリのサンプルをご覧ください。

ルール処理のレイテンシをモニタリングする YARA-L ルール

次の YARA-L ルールは、ログが取り込まれた時刻と検出が作成された時刻の差が特定のしきい値を超えるインスタンスを特定します。このルールを使用して、検出パイプラインのパフォーマンスのボトルネックを特定します。

このルールをテスト環境にデプロイして、ログソースのベースラインを設定します。

これらの結果をダッシュボードにエクスポートして、さまざまなログタイプでのレイテンシの傾向を可視化できます。

このルールでは、metadata.event_timestamp（アクティビティが発生した時刻）と metadata.ingested_time（Google SecOps がログを受信した時刻）を比較します。

rule rule_processing_latency_monitor {
  meta:
    author = "SecOps Engineering"
    description = "Alerts when the gap between ingestion and detection creation is greater than 15 minutes."
    severity = "Low"

  events:
    $event.metadata.event_timestamp.seconds = $event_ts
    $event.metadata.ingested_time.seconds = $ingest_ts
    
    // Calculate the delta in seconds
    $latency_delta = $ingest_ts - $event_ts

    // Threshold: 900 seconds (15 minutes)
    $latency_delta > 900

  match:
    $event.metadata.log_type over 1h

  outcome:
    $max_latency = max($latency_delta)
    $log_source = array_distinct($event.metadata.log_type)

  condition:
    $event
}

ケース確認のレイテンシ（検出の作成からアナリストの割り当てまで）

このセクションは、Google SecOps SIEM スタンドアロン プラットフォームを使用しているお客様には関係ありません。

ケース確認のレイテンシとは、アラートを作成する検出から、SOAR コンポーネントでトリアージのためにアナリストがアラートを確認するまでの経過時間です。

平均確認時間（MTTA）指標は、生成されたアラートに対応する SOC チームの効率を具体的に追跡します。

  • ケース確認のレイテンシを短縮するには、アラートのルーティング、チューニング、自動化（自動割り当てやエンリッチメントにプレイブックを使用するなど）を最適化して、アラートをトリアージ ステージに迅速に移行します。

次のステップ

  • ルール再生（クリーンアップ実行とも呼ばれます）が遅延したデータとコンテキストの更新を管理する方法と、これが MTTD 指標に与える影響については、ルール再生と MTTD の概要をご覧ください。
  • Google SecOps でのルール検出の遅延、要因、トラブルシューティング、遅延を短縮する手法の詳細については、ルール検出の遅延についてをご覧ください。

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