本頁面由 Cloud Translation API 翻譯而成。

瞭解規則重播和 MTTD

支援的國家/地區：

Google SecOps SIEM

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

規則重播

Google SecOps 會處理大量安全性資料。為確保規則能準確偵測到情境或相關資料，規則引擎會自動執行規則重播程序。這個程序會在不同間隔評估同一組事件資料多次，以處理延遲抵達的資料或需要更新環境的規則，例如比對遭入侵指標 (IOC)。

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

常見的規則重播觸發條件包括：

延遲抵達的擴充資料

資料擴充管道 (例如實體內容圖表 (ECG)) 可能會批次處理資料。如果 UDM 事件先於相關情境資料 (例如資產資訊或使用者情境) 抵達，系統在初始規則執行期間可能會錯過偵測。
追溯 UDM 擴充更新

如果規則在偵測邏輯中使用別名欄位 (經過擴充的欄位)，例如 $udm.event.principal.hostname，且來源資料 (例如 DHCP 記錄) 晚了一小時以上才送達，系統會針對該特定事件時間追溯更新這些欄位值。後續規則執行 (「清除作業」) 時，就會使用這些新加入的值，進而觸發先前未偵測到的項目。
排定的多重事件規則

多重事件 (ME) 規則會依排程 (例如每 10 分鐘、每小時或每天) 執行，以評估事件時間區塊。為擷取歷史資料的後續擴充更新，這些規則稍後會重新評估同一時間區塊，通常至少會執行兩到三次 (例如，在 5 到 8 小時後檢查，然後在 24 到 48 小時後再次檢查)。

如果偵測結果來自規則重播，警報的「偵測時間範圍」或「事件時間戳記」會顯示原始惡意活動的時間。「建立時間」是建立偵測結果的時間，可能比實際發生時間晚很多，有時甚至會晚幾小時或幾天。

偵測延遲時間過長 (事件與偵測之間的時間差過大)，通常是因為重新豐富延遲抵達的資料，或是實體內容圖 (ECG) 管道發生延遲。

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

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

評估 MTTD 的最佳做法

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

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

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

由於多事件規則的執行頻率是排定的，因此本質上會造成較高的延遲。評估多事件規則產生的偵測結果的 MTTD 時，請務必瞭解自動重新執行的規則所產生的偵測結果，有助於提高涵蓋範圍和準確度。雖然這些重播通常會偵測到需要延遲脈絡的威脅，但必然會增加該特定偵測的回報延遲。

針對時效性高的重大警報：使用單一事件規則或多重事件規則，並盡可能縮短執行頻率 (例如縮短比對時間範圍，少於一小時)。
複雜的長期關聯 (UEBA、多階段攻擊)：如果規則依賴大量的內容聯結或參考清單 (可能非同步更新)，延遲時間可能會較長 (最多 48 小時以上)。這項功能的優點是偵測準確度較高，而非絕對速度。

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