瞭解規則重播和 MTTD

支援的國家/地區：

本文說明規則重播 (也稱為清除執行或補償執行) 如何處理延遲抵達的資料和背景資訊更新，以及這些重播如何影響偵測平均時間 (MTTD) 指標。

規則重播

Google Security Operations 會處理大量安全性資料。為確保規則能準確偵測情境或相關資料，規則引擎會自動執行規則重播程序。

規則重播程序會處理下列類別的規則：

  • 單一事件規則：如果 UDM 擴充程序更新先前評估的事件，系統會重新執行這些規則。如要瞭解資料表規則的例外狀況，請參閱本文件稍後的「資料延遲抵達情境」一節。

  • 設有時間範圍的單一事件 (WSE) 規則和含有資料表的單一事件規則：這類規則有專屬的排程機制，可處理延遲收到的資料，與標準單一事件和多重事件規則不同。

  • 多事件規則：這類規則會依排程執行，並處理事件時間區塊。系統會以不同間隔重複評估同一時間區塊，以擷取後續的擴充更新，例如比對使用者或資產內容資料，或是擷取遭入侵指標 (IOC)。確切時間取決於排程設定。

規則重播觸發條件

即使資料是在初始規則執行後抵達或更新，系統也會重新評估 (重新執行) 規則，確保能偵測到事件。這類延遲抵達的資料包括下列類別：

  • 來源事件延遲抵達：原始記錄或 UDM 事件本身抵達 Google SecOps 的時間，比事件的實際時間戳記晚了許多。
  • 延遲抵達的擴充資料：與事件相關的脈絡資料 (例如使用者、資產、威脅情報) 在系統首次處理事件後，才會提供或更新。這是因為擴充管道 (例如實體內容圖 (ECG)) 會批次處理資料，或依附外部資料來源。
  • 追溯 UDM 擴充更新：延遲抵達的來源資料 (例如更新主機名稱的 DHCP 記錄) 會觸發 UDM 事件欄位的變更。如果規則在偵測邏輯中使用別名欄位 (經過擴充的欄位)，例如 $udm.event.principal.hostname，則來源資料延遲時可能會觸發重播。系統會追溯更新這些欄位值。

系統會根據規則類型和延遲資料的性質，以不同方式觸發規則重播。目標是兼顧偵測即時性和資料完整性。

系統如何依規則類型處理延遲抵達的資料

規則類型及其設定會決定時間範圍，在此範圍內，延遲抵達的資料可能會觸發規則重新評估。

  • 單一事件規則 (不含比對視窗或資料表)：

    • 來源事件延遲：一般來說，無論事件抵達系統時的時間戳記有多舊，這些規則都會處理事件。系統不會對延遲來源事件的初始處理作業，設定嚴格的截止時間。
    • 延遲補充：如果先前評估的事件收到補充資料或更新，系統會根據新內容重新評估這些單一事件規則。這類事件可能會在初始事件發生後數小時，甚至是數天後才發生。

  • 設有資料表的單一事件規則和設有時間範圍的單一事件 (WSE) 規則：

    • 這些規則不會採用與其他單一事件規則相同的延遲資料處理方式，也不會採用多事件規則的校正排程。
    • 這些欄位具有下列行為：
      • 截止時間：如果事件時間戳記與擷取時間相隔 7 天以上，這些規則就不會處理事件。
      • 延遲抵達的資料 (7 天內)：系統會處理延遲抵達的事件 (7 天內)，但延遲時間可能較長。
      • 延遲抵達的來源事件：如果資料在事件時間戳記 7 天後才抵達 Google SecOps，WSE 規則就不會處理事件。
      • 內容更新：如果事件的內容延遲送達，或是事件經過追溯式擴充，系統會自動根據擴充後的事件重新評估規則。即使初始評估未產生偵測結果，這項規則重播仍可能觸發新的偵測。
      • 延遲擴充：如果 UDM 事件因擴充而更新 (最晚會在擷取後 7 天內發生)，系統會根據更新後的事件重新評估這些規則。不過，與其他規則類型不同的是，更新資料表內容不會觸發系統自動重新評估這些規則的過往事件。
      • 回溯期：這些規則會使用約 7 天的回溯期重新評估事件。如果事件發生在 7 天內，且系統收到相關的擴充資料，就會重新評估規則。

  • 多重事件規則：

    • 多事件規則會依排程執行，並重新評估時間區塊，將延遲資料納入考量。規則的排程會決定有效截止時間範圍：
      • 主要執行：系統會在活動時間加上任何已設定的結算延遲 (例如 T + 1 小時)，執行第一次評估。
      • 第 1 次調整執行：系統會在主要執行作業後約 4 小時，執行第 1 次調整作業。這樣系統就能納入延遲抵達的事件。
      • 第 2 次補償執行 (條件)：如果開啟「確保資料豐富度」，系統會在主要執行後約 30 小時，執行最後一次補償。這樣一來，系統處理延遲抵達的資料和內容擴充作業的時間，最多可延長至約 30 小時。
      • 結算截止的影響：最終的結算執行作業會決定納入延遲資料的有效截止時間。這通常會在主要執行作業後約 4 小時發生 (如果啟用「確保資料豐富完整」，則會在主要執行作業後約 30 小時發生)。如果事件或資料強化作業在特定時間範圍的最終調整執行作業後才抵達，這項規則就不會處理該時間範圍的事件或作業。

延遲送達資料的情境範例

  • 情境 1：來源事件延遲 - 單一事件規則

    • Google SecOps 會擷取 3 天前的事件和時間戳記。標準單一事件規則會將這個事件視為新資料進行處理。

  • 情境 2：延遲強化 - 單一事件規則

    • 系統昨天處理了登入事件。目前，這項服務會擷取並充實相關使用者的新資訊 (例如部門異動)。系統會根據更新後的使用者環境，重新評估登入事件是否符合單一事件規則。

  • 情境 3：來源事件延遲 - 多事件規則 (預設 4 小時的修正時間)

    • 如果多事件規則排程使用預設設定，事件會在事件時間戳記後 3 小時送達。該事件錯過了初始主要執行作業 (T + 1 小時)，但系統會在 4 小時的補償執行作業期間處理該事件。

  • 情境 4：來源事件延遲 - 多重事件規則 (未完成擴充)

    • 您設定了多事件規則，主要執行偏移為 1 小時，但未啟用「確保擴充完整性」。事件會在時間戳記 6 小時後送達。
    • 這項活動錯過了主要執行時間 (T + 1 小時) 和第一次修正執行 (T + 4 小時)。由於這項事件是在最後一次調整後才傳送，因此系統不會處理該時間範圍內的事件。

  • 情境 5：延遲擴充 - 多重事件規則 (含擴充完整度)

    • 多重事件規則的偏移時間為 1 小時，且您已啟用「確保擴充完整性」。事件的擴充資料會在事件時間戳記後 28 小時抵達。
    • 系統會在第二次調整作業 (約在 T + 31 小時) 期間，使用這項延遲的擴充功能重新評估規則。

  • 情境 6：來源事件延遲 - 具有比對視窗的多事件規則

    • 多事件規則的回溯期為 48 小時，且排程已啟用「確保資料完整性」match (最終調整時間約為 T + 30 小時)。事件在時間戳記 36 小時後送達。即使事件時間在規則的相符時間範圍內，相對於其他事件，這個事件也不會處理，因為它是在最終的修正執行後抵達。截止時間是根據相對於調整時間表的抵達時間而定，而不只是比對時間範圍。

  • 情境 7：來源事件延遲 - Windowed-single-event 規則

    • 如果來源事件的時戳是 8 天前，但延遲抵達，可能就會超出 WSE 規則的 7 天回溯期，因此不會處理。

對時間指標的影響

如果偵測結果來自規則重播，系統會使用下列術語：

  • 快訊的「偵測視窗」或「事件時間戳記」是指原始惡意活動發生時間。
  • 「建立時間」是指系統建立偵測結果的時間，可能晚了許多，有時甚至會晚幾小時或幾天。
  • 偵測延遲是指事件時間戳記與偵測建立時間之間的時間差。

時間軸差異和 MTTD

初始事件時間戳記與偵測建立之間經過的時間，會直接影響 MTTD 計算。

管道 / 排程階段 評估時間 對 MTTD 評估的影響
單一事件規則 (串流) 持續 (<5 分鐘後抵達) 即時偵測代表真正的平台速度，對平均診斷時間 (MTTD) 的影響極小。
多事件規則 (主要執行) 抵達後 1 到 2 小時 (加上設定的結算延遲時間) 包括彙整多事件關聯狀態時，不可避免的批次緩衝視窗。
多重事件規則 (結算調整執行) 主要作業執行後 4 小時或 30 小時 如果次要 (重播) 執行作業納入延遲的補充資料，這個時間就會相對於事件時間戳記延遲或延後。這項差異會對 MTTD 計算造成負面影響。

評估 MTTD 的最佳做法

MTTD 會量化從最初入侵到有效偵測到威脅的時間。分析規則重播觸發的偵測結果時，請套用下列最佳做法，確保 MTTD 指標準確無誤。

Google SecOps 提供多項可供使用者查詢的指標，可準確評估 MTTD。如要進一步瞭解這些指標，請參閱資訊主頁的 YARA-L 2.0 查詢範例。

「偵測類型」欄中的 圖示表示偵測結果是根據延遲超過 30 分鐘的事件資料、自動化補正作業、重新處理管道或回溯搜尋產生。這個圖示也會顯示在 Google SecOps 的「快訊」頁面。

優先採用即時偵測系統

如要盡快偵測到事件，請使用單一事件規則。這些規則會近乎即時執行，通常延遲時間不到 5 分鐘。這也支援更全面的複合偵測。

在多事件規則中考量規則重播

多事件規則的執行頻率較高，因此延遲時間較長是正常現象。評估多事件規則偵測的 MTTD 時，請注意自動規則重播會提高涵蓋範圍和準確度。這些重播通常會偵測到需要延遲情境的威脅，因此會增加這些偵測的延遲時間。

  • 針對時間緊迫的重大快訊：使用單一事件規則或多重事件規則，並盡可能縮短執行頻率。縮短比對時間範圍不會直接影響延遲時間，但可設定最短延遲時間，進而提高效率。

  • 複雜的長期關聯 (UEBA、多級式攻擊)： 這類規則依賴大量的內容聯結或參照清單，因此可能會非同步更新。這類模型可能會因背景或事件資料延遲抵達而導致高延遲，但優點是偵測準確度較高，而非絕對速度。

最佳化規則以減少對後期富集的依賴

如要盡量加快偵測速度，並減少回溯式擴充執行作業的影響，請盡可能在規則邏輯中使用非別名欄位 (下游擴充管道不會處理的欄位)。

後續步驟

如要瞭解相關排程概念和設定工作流程，請參閱下列文件：

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