検出とレポートのパフォーマンスを最適化する

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

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

合計検出レイテンシ

セキュリティ オペレーション センター（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 時間、24 時間。頻度が高いほど、最小処理レイテンシが高くなります。詳細については、実行頻度を設定するをご覧ください。
  • ルールのタイプと複雑さ: マルチイベント ルールでは、完全に処理するために一致ウィンドウが必要になるため、固有のレイテンシが発生します。他の非リアルタイム検出に依存する複合ルールも遅延を引き起こします。詳細については、複合検出をご覧ください。

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

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

詳細については、ダッシュボード用の 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 のプロフェッショナルから回答を得ることができます。