瞭解規則重播和 MTTD

支援的國家/地區：

Google SecOps SIEM

本文說明規則重播 (也稱為清理執行) 如何管理延遲抵達的資料和情境更新，以及這對偵測平均時間 (MTTD) 指標的影響。

規則重播

Google SecOps 會處理大量安全性資料，為確保規則引擎能準確偵測出依附於情境或相關資料的規則，系統會自動執行規則重播程序。

規則重播程序會處理兩類規則：

單一事件規則：當 UDM 擴充程序更新先前評估的事件時，系統會重新執行單一事件規則。
多事件規則： 多事件規則會按照您選取的排程執行，並處理事件時間區塊。這些規則會以不同間隔重複重新評估同一時間區塊，以擷取延遲的擴充更新，例如比對使用者或資產內容資料，或是遭入侵指標 (IOC)。
舉例來說，規則可能會執行至少兩到三次 (在 5 到 8 小時後，以及 24 到 48 小時後)，以考量延遲抵達的事件和內容資料。

當相關情境資料送達，或情境資料的處理時間晚於初始事件資料時，系統會重新評估 (重新執行) 規則。

常見的重播原因包括：

延遲抵達的擴充資料：資料擴充管道 (例如實體內容圖 (ECG)) 通常會批次處理資料。如果 UDM 事件先於相關情境資料 (例如資產資訊或使用者情境) 抵達，初始規則執行作業可能會漏掉偵測結果。
回溯 UDM 擴充更新：如果規則在偵測邏輯中使用別名欄位 (擴充欄位)，例如 $udm.event.principal.hostname，當來源資料 (例如 DHCP 記錄) 延遲時，可能會觸發重播。系統會根據延遲抵達時間，追溯更新這些欄位值。後續規則重播會使用這些新擴充的值，可能觸發先前錯過的偵測。

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

如果資料延遲送達而導致重新擴充，或是實體內容圖 (ECG) 等內容來源更新延遲，通常會導致偵測延遲時間過長。

這項時間差可能會導致系統「延遲」或「稍晚」偵測到威脅，進而誤導分析師，並扭曲 MTTD 等成效指標。

指標元件	時間來源	重播對 MTTD 的影響
偵測時間範圍 / 事件時間戳記	原始安全性事件發生的時間。	這項資訊會與活動時間保持一致。
偵測時間 / 建立時間	引擎實際發出偵測結果的時間。	相較於事件時間戳記，這個時間會「延遲」或「延後」，因為系統會根據納入延遲擴充資料的次要 (重播) 執行作業來計算這個時間。這項差異會對 MTTD 計算造成負面影響。

評估 MTTD 的最佳做法

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

Google SecOps 提供多種可供使用者查詢的指標，可準確評估 MTTD。如要瞭解這些指標的詳細資料，請參閱「資訊主頁頁面的 YARA-L 2.0 查詢範例」。

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

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

這也支援更全面地使用複合偵測項目。

由於多事件規則的排定「執行頻率」較高，因此本質上會導致較高的延遲。評估多事件規則偵測的 MTTD 時，請注意自動規則重播會提高涵蓋範圍和準確度。這些重播通常會偵測到需要延遲情境的威脅，因此會增加這些偵測的延遲時間。

如要發出緊急且時效性高的快訊：請使用單一事件規則或多重事件規則，並盡可能縮短執行頻率。縮短比對視窗不會直接影響延遲時間，但設定最短延遲時間可提高效率。
複雜的長期關聯 (UEBA、多階段攻擊)： 這類規則依賴大量的內容聯結或參照清單，因此可能會非同步更新。如果情境或事件資料延遲抵達，可能會導致高延遲，但這類偵測器可提供較高的偵測準確度，而非絕對速度。

如要盡量縮短偵測時間，並減少回溯式擴充執行作業的影響，請盡可能在規則邏輯中使用非別名欄位 (不受下游擴充管道影響的欄位)。