瞭解規則偵測延遲

支援的國家/地區：

本文說明 Google Security Operations 中的規則偵測延遲問題，找出擷取和處理管道的影響因素，概述結構化疑難排解方法，並提供縮短偵測延遲時間的技巧。

偵測規則總覽

偵測規則會檢查正規化的原始記錄 (包括一般和實體通用資料模型 (UDM) 事件)，並根據規則規格產生安全偵測結果。實體 UDM 事件通常包含背景資訊，例如使用者或資產中繼資料。偵測規則也可以評估先前產生的偵測項目，以產生複合快訊。

預期和非預期的延遲

偵測延遲時間會因規則邏輯、資料依附元件和系統處理週期而異。延遲可分為兩種類型：

  • 預期延遲：結構性因素造成的延遲，例如擷取程序、規則類型、執行頻率、偵測產生方法、比對回溯期長度和已知系統限制。您可以調整偵測規則設定和排程參數，盡量縮短預期延遲時間。
  • 無法預測的延遲：外部或動態管道狀況造成的延遲，包括資料來源的記錄檔傳送瓶頸、Google SecOps 服務內的暫時處理延遲、延遲的內容可用性，以及 UDM 重新擴充週期。

偵測產生方法

Google SecOps 會透過下列執行管道產生規則偵測項目：

  • 串流引擎：高速管道，可持續近乎即時地評估標準和視窗單一事件規則 (通常在擷取後 5 分鐘內)。在標準執行期間，系統會持續評估延遲抵達的事件和追溯擴充功能。
  • 查詢引擎：評估需要跨多個事件或外部資料聯結的時間型事件關聯規則：
    • 複雜的單一事件規則：包括查詢參照清單或資料表的單一事件規則。
    • 多事件規則：根據設定的排程，以批次事件時間區塊 (例如 10 分鐘或 1 小時間隔，或 match_window / 10，適用於超過 48 小時的視窗) 查詢資料。
  • 依據歷來資料執行規則：透過回溯搜尋，根據歷來記錄檔回溯評估規則。歷來掃描完成後，系統就會顯示偵測結果。
  • 重新擴充 UDM 事件：當新內容或更新的實體資料新增至歷來事件時，重新評估先前處理的時間區塊。

導致規則偵測延遲的因素

偵測結果的顯示速度取決於規則複雜度、排定間隔、資料擷取延遲時間和內容擴充管道。

規則類型和複雜度

偵測規則分為幾種類別，延遲狀況各不相同：

單一事件規則

單一事件規則會在連續串流引擎上近乎即時執行，偵測延遲時間最短。這些規則會評估個別事件，不會聯結外部資料集、資料表或多重事件比對時間範圍。

複雜的單一事件規則

這類規則會評估單一事件，但會納入額外的資料依附元件：

  • 設有時間範圍的單一事件規則：包含 match 區段的單一事件規則 (例如評估單一事件是否在時間範圍內符合條件)。資料擷取時，這些規則會透過連續串流引擎近乎即時評估。
  • 參照單一事件規則：單一事件規則會比較事件屬性和參照清單或資料表。

多事件規則

多重事件規則會在指定的比對時間範圍內，比對兩項以上的 UDM 事件條件，並在排定的批次間隔執行。

  • 標準多事件規則：在時間範圍內彙整多個事件，並以 10 分鐘或 1 小時為間隔執行 (如果時間範圍超過 48 小時，則為 match_window / 10)。
  • 情境感知規則：使用情境感知分析，將事件資料與 UDM 實體事件 (例如 user_context 或 asset_context) 建立關聯。由於情境感知規則會使用多個資料動態饋給，因此對擷取時間較為敏感。詳情請參閱「在規則中使用情境豐富的資料」。

規則執行頻率

設定的執行頻率會決定查詢引擎評估事件時間區塊的頻率：

  • 近乎即時：持續評估單一事件規則 (標準和時間範圍)。
  • 10 分鐘頻率：適用於比對回溯期少於 60 分鐘的多事件規則。
  • 1 小時頻率：比對時間範圍為 48 小時以內的多重事件規則，預設間隔為 1 小時。
  • match_window / 10 頻率：系統會為比對時間範圍超過 48 小時的多事件規則自動指派頻率 (例如，比對時間範圍為 100 小時時，每 10 小時執行一次；比對時間範圍為 10 天時，每 24 小時執行一次)。

比對時間範圍長度

如果是多事件規則，比對時間範圍長度會定義彙整事件所需的觀察期。完整時間範圍結束後，系統才會顯示偵測結果。

記錄擷取延遲

「擷取延遲」是指從事件在來源發生，到 Google SecOps 接收並剖析記錄之間經過的時間。

如果事件在該時段的初始排定評估時間後抵達，就會錯過第一次執行。系統會在後續的自動背景執行作業 (補正執行作業) 中擷取延遲抵達的資料，這些作業會在主要執行作業後約 4 小時 (如果選擇使用豐富度完整性，則為 30 小時) 執行。

  • 範例：規則會在 30 分鐘的時間範圍內，將事件 A (事件時間為上午 9:03) 和事件 B (事件時間為上午 9:05) 相互關聯。如果事件 A 在上午 10:05 送達 (延遲一小時)，就會錯過上午 9:00 至 9:30 區塊的初始執行作業。系統會在主要執行作業後約 4 小時 (下午 2 點左右) 進行後續的校正執行作業，重新評估封鎖狀態，並在事件發生後約 5 小時產生偵測結果。

時區差異

根據預設，Google SecOps 會將記錄時間戳記解讀為世界標準時間。如果記錄來源省略明確的時區偏移量，系統會將時間戳記視為世界標準時間，即使立即收到記錄，記錄仍可能顯示為延遲抵達。

  • 範例：活動發生於美國東部時間上午 10:00 (世界標準時間 15:00)，並在世界標準時間 15:05 抵達 Google SecOps，但沒有時區中繼資料。系統會將時間戳記解讀為世界標準時間 10:00，因此會產生 5 小時的擷取延遲，並將規則評估作業延後至背景的修正執行作業。

解決方法：如要解決時區差異問題，請按照下列步驟操作：

  • 設定記錄來源，在事件時間戳記中加入明確的世界標準時間時區偏移量。
  • 請與支援團隊聯絡，為特定擷取動態饋給設定時區覆寫。
  • 使用 BindPlane 處理器，在擷取記錄前將記錄主體時間戳記正規化為 UTC。詳情請參閱「使用 BindPlane 修改記錄主體時間戳記」。

情境式彙整與資料充實

Google SecOps 會從次要來源新增身分、資產和威脅中繼資料，進而擴充 UDM 事件。如果情境資訊延遲提供，偵測時間可能會延長。

別名和增補機制

別名和擴充功能會將原始指標與機構脈絡資料建立關聯：

  • 別名：識別並連結不同資料來源中同一實體的不同 ID (例如將 DHCP 記錄中的 IP 位址對應至 MAC 位址和主機名稱，如 alex-macbook，或將使用者 ID 對應至員工職稱)。
  • 擴充：使用別名內容填入正規化的 UDM 事件欄位 (例如，原始事件中只有 IP 位址時，填入 $udm.event.principal.hostname)。

支援的擴充類型包括資產、使用者、程序、檔案雜湊中繼資料、地理位置和雲端資源。詳情請參閱「UDM 擴充和別名總覽」。

重新擴充 UDM 事件

系統會隨著脈絡來源演進，持續更新歷來事件：

  • 基礎資料變更：在擷取資料後，系統最多可能需要 24 小時才會更新歷來事件，因為這段時間內會收到新的比對內容資料。
  • 擴充系統更新：實體中繼資料、IP 位址地理位置或 VirusTotal 威脅情報更新時，規則引擎會重新評估歷來的封鎖 (通常是在排定的修正執行或重新處理期間)，並產生具有更新情境的偵測結果。
  • 延遲的內容資料：如果內容資料 (例如主機名稱) 在事件記錄檔建立後一天才送達，系統會重新擴充 UDM 事件，後續的校正作業會評估擴充後的記錄。
  • 內容修改：如果強化更新作業變更了事件屬性 (例如將 IP 地理位置從 USA 更新為 Canada)，符合更新值的規則會在後續重新評估期間觸發偵測。

實體脈絡圖 (ECG) 處理

實體脈絡圖 (ECG) 會將入侵指標 (IOC) 和企業資產圖資料相互關聯。由於心電圖管道採用批次處理 (視資料量而定，可能需要 30 小時或數天)，因此在圖形關係完全計算完畢後，參照 graph.entity 欄位的規則才會產生偵測結果。

過往規則執行作業和 RetroHunt

依據歷來資料執行規則時，系統只會在所選時間範圍的追溯搜尋掃描完成後，才產生偵測結果。

  • 追溯性擴充工作流程：
    1. 下午 1:00 收到事件，但 ip_address = 10.0.0.5 (主機名稱不明)。
    2. 下午 2:30，系統收到連結 10.0.0.5 和 workstation-123 的 DHCP 記錄。
    3. 別名管道會使用 principal.hostname = workstation-123 更新下午 1:00 的歷史事件。
    4. 後續規則重播會評估經過擴充的主機名稱，並顯示在初始執行期間未觸發的偵測結果。

參照清單

查詢參照清單的規則會在執行時，根據最新版本的清單進行評估。更新參照清單後，排定的規則可能會對先前擷取的記錄進行回溯偵測。

不存在規則

為避免誤判，系統會在評估檢查不存在條件 (例如 !$e 或 #e=0) 的規則前，先導入至少一小時的緩衝期，確保所有相關記錄都有時間送達。

資料處理和結算限制

評估偵測延遲時，請注意下列系統行為：

  • 強化處理：內容強化功能最多可在初始擷取後 24 小時內，更新歷來 UDM 事件。
  • 調整週期：多事件規則會在主要執行後約 4 小時 (可選擇 30 小時)，自動重新執行，以擷取稍晚抵達的資料。詳情請參閱「瞭解規則重播和 MTTD」。
  • 偵測限制：如要瞭解平台容量和節流限制，請參閱「瞭解偵測限制」。

排解規則偵測延遲問題

如要診斷規則產生延遲偵測結果的原因，請在 Google SecOps 控制台中檢查下列啟發式方法和管道階段：

  • 查看規則中繼資料和時間表：在「規則」資訊主頁中，查看「規則名稱」、「規則類型」和「規則時間表」欄，找出規則的執行引擎和基準評估頻率。
  • 比較事件時間與擷取時間：在「Detections」分頁中找出偵測結果，然後比較事件時間戳記與擷取時間戳記。如果事件時間與擷取時間的差距超過 30 分鐘，表示延遲是由來源或收集期間的記錄傳送延遲所造成。如果偵測結果是根據延遲超過 30 分鐘才送達的事件資料、自動執行的修正作業、重新處理的管道或回溯搜尋產生，則「偵測類型」欄會顯示 圖示。
  • 查看內容來源依附元件：檢查規則是否參照principal擴充功能、UDM 別名或graph.entity欄位。內容管道會以非同步方式處理，並可能在後續的校正執行期間顯示偵測結果。
  • 確認頻率和比對時間範圍是否相容：確認設定的執行頻率符合比對時間範圍大小 (例如，確保比對時間範圍為 15 分鐘的規則排定為 10 分鐘或 1 小時)。
  • 檢查資料動態饋給是否中斷：查看擷取記錄和動態饋給管理資訊主頁，確認擷取作業是否延遲，或來源是否暫時中斷。

縮短偵測延遲時間的訣竅

如要盡量縮短環境中的偵測延遲時間，請套用下列最佳化技術：

  • 最佳化規則執行頻率：
    • 單一事件規則 (標準和視窗) 請使用「近乎即時」。
    • 如果多事件規則的相符時間範圍少於 60 分鐘，請設定 10 分鐘的排程。
    • 如果規則的相符時間範圍介於 1 到 48 小時，且需要快速發出快訊，請使用「1 小時」。
  • 調整比對時間範圍長度：將比對時間範圍設為擷取相關威脅行為所需的最短時間。
  • 消除記錄檔傳送瓶頸：確保轉送器和收集器立即傳送事件資料，避免記錄檔錯過初始執行時間範圍。
  • 驗證時區設定：請確認記錄來源提供明確的 UTC 偏移量，以免出現 5 小時以上的資料擷取延遲。
  • 稽核內容和不存在條件：只有在偵測邏輯需要時，才使用內容豐富的欄位和不存在條件 (!$e)，因為這些條件會導入刻意緩衝期。

後續步驟

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

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