瞭解規則重播和 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 小時)，執行第一次評估。
      • 第一次調整執行：系統會在主要執行作業完成後約 4 小時，執行第一次調整作業。這樣系統就能納入延遲抵達的事件。
      • 第 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：來源事件延遲 - 具有比對時間範圍的多重事件規則

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

  • 情境 7：來源事件延遲 - 設有時間範圍的單一事件規則

    • 如果來源事件的時間戳記是 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 專業人員尋求解答。