分析規則的成效和效率

支援的國家/地區：

本指南適用於在 Google Security Operations 中建立、部署及監控規則的安全工程師。本文說明如何監控規則，確保規則正常運作，並使用 Google SecOps 執行個體中的資料，避免規則耗用過多資源。這類資料有助於偵錯延遲偵測、瞭解延遲抵達的擴充資料對規則的影響，以及找出平均偵測時間 (MTTD) 最長的規則。

本指南提供下列工作的相關文件：

  • 瞭解如何在規則的初始發布期間評估規則、接收快訊，以及查看規則資訊主頁來監控規則的健康狀態。

  • 如何找出偵測延遲的原因 (例如是否因擷取延遲或邏輯效率不彰)，並調整偵測平均時間 (MTTD) 報表或使用額外的規則排除條件調整規則。

事前準備

如要查看及修改本文所述的規則，您必須是 Chronicle API 編輯者。詳情請參閱「Google Security Operations 角色和權限」。

在 Google SecOps 中分析規則的效力之前，請先充分瞭解 YARA-L 語言、YARA-L 查詢、如何建立及管理規則，以及如何建立資訊主頁：

重要術語

  • 規則：將記錄資料匯入 Google SecOps 帳戶時，系統會自動識別威脅。
  • 配額：資料擷取量、可對資料執行的查詢數量和複雜度，以及 Google SecOps 帳戶中有效規則的數量和複雜度上限。
  • 警示和偵測結果：Google SecOps 和您自己的安全基礎架構發現的安全性問題，需要您採取行動。
  • 擷取：將安全性資料匯入 Google SecOps 並轉換為 UDM 的程序。
  • 規則重播：如果相關比對內容資料的抵達或處理時間晚於初始事件資料，系統會自動對現有資料重新執行規則。
  • 回溯搜尋：將新規則套用至現有資料，找出先前未發現的威脅。

如何分析規則

以下各節說明如何分析規則的成效。

部署規則後進行測試及評估

首次將規則部署至正式環境時，請在 Rule Observability 資訊主頁中監控 24 到 48 小時：

  1. 前往「資訊主頁」

  2. 搜尋 Rule Observability。

  3. 在「規則」欄中搜尋新規則。「規則可觀測性」資訊主頁會顯示偵測次數、擷取延遲時間，以及從擷取到偵測的時間等統計資料。

為確保規則邏輯不會在開始產生高優先順序快訊前，導入人為延遲，您可以參閱偵測的架構參考資料。這個結構定義了用於監控安全性快訊的結構化格式。這項功能經過最佳化，可追蹤偵測頻率、風險分布和規則效能。如要進一步瞭解如何使用結構定義，請仔細查看查詢範例。

找出規則結果延遲的原因

請完成下列步驟，判斷規則結果是否延遲，以及延遲原因：

  1. 依序前往「Detections」>「Alerts & IOCs」。
  2. 在「快訊」分頁中，找到「偵測類型」欄。
  3. 搜尋帶有黃色燈泡圖示的快訊。
  4. 將滑鼠游標懸停在圖示上，查看偵測結果是否由下列任一項目觸發：
    • 規則重新處理：由使用者手動觸發。
    • Retrohunt：由使用者手動觸發。
    • 延遲的事件資料：指出是否預期會發生偵測延遲。

根據偵測時間篩選快訊

  1. 依序前往「Detections」>「Alerts & IOCs」。

  2. 在「快訊」分頁中，使用「偵測時間」資料欄的篩選器元素，依據偵測結果的抵達時間排序。

  3. 按一下表格頂端的重新整理圖示 ，然後點選「立即重新整理」。您可以在 Google SecOps 帳戶中查看最新快訊，以及與每則快訊相關聯的規則 (請查看「規則名稱」欄)。

檢查中繼資料

如要進一步瞭解規則的成效，可以使用 latencyMetrics 檢查原始偵測 JSON，找出 oldestEventTime 和 oldestIngestionTime 之間的差異。

偵測時間值

下表列出與 DetectionTimingDetails 相關聯的列舉值：


值
說明
MTTD 影響

UNSPECIFIED


在標準排程時間範圍內建立偵測。
MTTD 的實際資料。

REPROCESSING


因規則重播 (例如延遲送達的資料) 而產生。
代表營運風險，應計入報表。

RETROHUNT


透過歷來回溯搜尋執行產生。
通常會從標準 MTTD 報表中篩除。

範例：latencyMetrics 中繼資料

以下latencyMetrics範例顯示事件發生時間 (oldestEventTime 與 newestEventTime) 和事件擷取時間 (oldestIngestionTime 與 newestIngestionTime) 的時間差。事件與擷取至 Google SecOps 帳戶之間的延遲時間約為 53 分鐘。

"detectionTimingDetails": ["DETECTION_TIMING_DETAILS_REPROCESSING"],
"latencyMetrics": {
  "oldestIngestionTime": "2025-12-09T16:54:14Z",
  "newestIngestionTime": "2025-12-09T16:54:14Z",
  "oldestEventTime": "2025-12-09T16:01:06Z",
  "newestEventTime": "2025-12-09T16:01:06Z"
}

疑難排解

下表列出一些您可能遇到的規則問題和解決方法：


問題
解決方法

顯示燈泡圖示，但列舉為 UNSPECIFIED.
如果事件時間與擷取時間的差異超過 30 分鐘，就會發生這種正常現象。使用「資料健康狀態中心」指標，調查資料延遲擷取的原因。

偵測結果的顯示時間比事件發生時間晚。
檢查 detectionTimingDetails。如果列舉值為 REPROCESSING，延遲可能是因為擴充資料延遲送達，而非規則執行延遲。如果 UNSPECIFIED，請調查規則邏輯的效率。

運算量過多。
規則可能掃描過多資料，或邏輯效率不彰。前往「規則排除條件」或使用「篩選器卸載」調整規則，縮小資料搜尋範圍。

已知限制

  • 門檻嚴格度：資料延遲的視覺提示固定為 30 分鐘門檻，不會考量使用者定義的延遲時間範圍。
  • 資料健全狀態：規則可觀測能力會提供規則健全狀態資訊，但監控資料健全狀態 (更接近擷取程序) 較能有效找出一般延遲抵達的資料問題。
  • 配額強制執行：資訊主頁會顯示資源用量，但不會在規則接近配額限制時提供即時通知。

後續步驟

如要瞭解規則重播和規則偵測延遲，請參閱下列文章：

還有其他問題嗎？向社群成員和 Google SecOps 專業人員尋求答案。