瞭解規則重播和 MTTD

支援的國家/地區：

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

規則重播

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

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

  • 單一事件規則：當 UDM 擴充程序更新先前評估的事件時，系統會重新執行單一事件規則。(請參閱下方的資料表規則例外狀況)。

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

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

規則重播觸發條件

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

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

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

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

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

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

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

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

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

  • 多重事件規則：

    • 多事件規則會依排程執行，並重新評估時間區塊，以納入延遲資料。設定規則的排程時，請注意以下事項：
      • 預設時間表：系統通常會在活動時間後約 5 小時和 24 小時，自動執行結算。如果資料在 24 小時執行完畢後才送達，系統就不會針對該時間範圍評估這項規則。
      • 啟用可自訂時間表：透過「執行頻率」設定，進一步控管執行時間。請參閱「設定規則的自訂時間表」。重要時間如下：
        • 首次執行：系統會在活動時間加上設定的偏移量後，首次執行作業 (例如 T + 1 小時)。
        • 第 1 次結算執行：系統會在首次執行後約 4 小時，執行第 1 次結算。也就是說，系統可以納入大約 T + 4 到 5 小時內抵達的事件。
        • 第 2 次補正執行 (條件式)：如果開啟「確保資料豐富度完整」，系統會在首次執行後約 30 小時，執行最後一次補正。這樣一來，系統處理延遲資料的時間範圍就會延長至 T + 30 到 31 小時左右。
      • 截止時間影響：自訂時間表時，最後一次的調整作業會決定納入延遲資料的有效截止時間。這通常會在首次執行後約 4 小時發生，如果啟用「確保資料擴充完整性」，則會在首次執行後約 30 小時發生。如果事件或補充資料在特定時間範圍的最終調整作業執行後才送達，這項規則就不會處理該時間範圍的資料。

資料延遲抵達情境範例

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

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

  • 情境 2：延遲擴充 - 單一事件規則

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

  • 情境 3：來源事件延遲 - 多事件規則 (預設時間表)

    • 如果事件在事件時間戳記 10 小時後送達，系統會在 5 小時的校正執行期間錯過該事件，但會在 24 小時的校正執行期間處理該事件。如果事件延遲 25 小時才送達，系統就不會處理。

  • 情境 4：來源事件延遲 - 多事件規則 (可自訂時間表)

    • 您設定了多事件規則，首次執行的偏移時間為 1 小時。事件會在時間戳記後 6 小時內送達。
    • 這項事件錯過首次執行 (T + 1 小時) 和首次調整執行 (T + 4 小時)。除非啟用「確保資料豐富度完整」，否則系統不會根據這項規則處理事件。

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

    • 多重事件規則的時差為 1 小時，且您已啟用「確保資料豐富度完整」。事件的擴充資料會在事件時間戳記後 28 小時內送達。
    • 如果啟用「確保充實完整性」，系統會在 T + 30 小時左右進行第二次「補償執行」，屆時可能會有部分延遲充實資料。如果系統取得補充資料，就會使用這項資料重新評估規則。

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

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

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

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

對時間指標的影響

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

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

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

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

指標元件 時間來源 重播對 MTTD 的影響
偵測時間範圍 / 事件時間戳記 原始安全性事件發生的時間。 重播功能會將時間準確地設為活動時間。
偵測時間 / 建立時間 引擎實際發出偵測結果的時間。 如果次要 (重播) 執行作業納入延遲的擴充資料，這個時間就會相對於事件時間戳記延遲或延後。這項差異會對 MTTD 計算造成負面影響。

評估 MTTD 的最佳做法

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

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

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

優先採用即時偵測系統

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

這也支援更全面的複合偵測。

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

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

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

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

調整規則，減少對延遲資料的依賴

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

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