瞭解規則偵測延遲

支援的國家/地區：

本文說明 Google Security Operations 中的規則偵測延遲情形，找出造成延遲的因素，概述疑難排解方法，並建議盡可能縮短延遲時間的技術。

偵測規則

偵測規則會檢查一般和實體通用資料模型 (UDM) 事件 (即經過正規化的原始記錄)，並根據規則規格產生偵測結果。實體 UDM 事件通常包含內容資訊，例如使用者或資產詳細資料。規則也會根據先前產生的偵測項目生成偵測結果。

預期和非預期的延遲

偵測時間可能會因處理延遲而有所不同。有些規則會近乎即時觸發，有些則可能需要幾分鐘或幾小時才能完成。規則類型、執行頻率和偵測產生方法等因素都會影響這些延遲。本文將探討這些和其他延遲因素。

我們將延遲分為「預期」或「無法預測」。

  • 預期延遲：這些延遲是由擷取程序，以及您在設定偵測規則時所做的設定選擇所造成。舉例來說，建立偵測所需的時間就是其中一個因素。這些延遲時間取決於已知的結構性因素，例如規則類型、執行頻率、偵測生成方法、已知限制和其他可預測的因素。
    如要盡量縮短延遲時間，請按照本文說明變更或調整偵測規則設定。
    詳情請參閱縮短延遲時間的訣竅。

  • 無法預測的延遲：這類延遲是由許多因素造成，包括事件資料延遲送達 Google SecOps、Google SecOps 服務中處理管道的暫時性緩慢、重新擴充，以及其他資料處理延遲。

分析規則偵測延遲

如要分析規則偵測延遲，請找出規則及其周遭因素的相關資訊：

  1. 在 Google SecOps 控制台中，依序前往「Detection」(偵測) >「Rules and detections」(規則和偵測)。

    規則資訊主頁會顯示規則中繼資料，例如 Rule name、Rule type 和 Run frequency。

    詳情請參閱「在規則資訊主頁中查看規則」。

  2. 在規則資訊主頁中，使用搜尋功能找出偵測延遲時間過長的規則。

  3. 在任何特定規則執行期間，有幾項因素可能會影響偵測延遲。Rule type、Run frequency、Event type、Event time 和 Ingested time 等維度是瞭解特定偵測作業可能延遲的原因時，很有用的啟發式方法。

  4. 請參閱下列主題，瞭解這些因素如何影響規則偵測延遲：

偵測產生方法

瞭解系統如何建立規則偵測，以及偵測產生方法如何影響偵測延遲。

系統會透過下列方式產生規則偵測結果：

  1. 串流引擎

    Streaming Engine 管道速度很快，通常延遲時間不到五分鐘。系統會處理單一事件規則，這些規則沒有相符部分，且沒有外部資料集，例如參照清單或資料表。

  2. 查詢引擎

    查詢引擎會依下列方式處理規則：

    • 複雜的單一事件規則：

      • 參照參照清單或資料表的單一事件規則。
      • 單一事件規則 (設有時間範圍)：使用簡單條件的相符時間範圍。例如「事件數 > 0 的事件」。系統擷取新資料並提供規則處理時，這些規則會以高頻率 (近乎即時) 查詢速率執行。

    • 多事件規則：這類規則會根據您設定的排程，查詢事件時間區塊的資料 (10 分鐘、每小時、每天)。
      舉例來說，如果是 10 分鐘的排程，規則會在 5 到 8 小時和 24 到 48 小時後，重新查詢事件時間區塊，具體時間取決於上游處理時間表。

  3. 依據歷來資料執行規則

    詳情請參閱「回溯搜尋」。

  4. 重新擴充 UDM 事件

    詳情請參閱「重新擴充 UDM 事件」和「實體內容圖表處理」。

已知限制

以下是造成規則偵測延遲的一些標準限制：

  • 有時，擴充作業可能會比預期更久。重新處理擴充功能會導致後續規則執行作業重新評估資料。系統會多次執行資料擴充作業，且事件最多會在事件時間後 24 小時內更新。
  • 多事件規則通常會加入主要事件發生時間後數小時才傳送的脈絡資料。如果這類脈絡資料的延遲時間過長，可能會導致重新擴充處理程序和規則重播相互影響，進而延遲偵測時間。Google SecOps 會使用這項功能處理極晚抵達的資料，但偵測視窗 (事件時間區塊) 和快訊建立時間之間會出現大範圍的時間間隔。
  • 情境感知規則會依據資產和身分別名等擴充來源，或實體情境圖表。由於這些規則依賴多個事件來源，因此更容易發生高延遲。
  • 系統會在首次執行規則後的 5 到 8 小時，以及 24 到 48 小時內，重新執行規則。這兩項規則重播會根據重新處理管道的執行時間觸發。
  • 如需其他偵測限制，請參閱「瞭解偵測限制」一文。

排解規則偵測延遲問題

透過排除程序，排解規則偵測延遲問題。

請按照建議做法調查及排解規則偵測延遲問題：

  1. 檢查是否有明顯延遲：

    判斷是否有任何擷取延遲：

    1. 在 Google SecOps 控制台中，依序前往「Detection」(偵測) >「Rules and detections」(規則和偵測)。

    2. 在規則資訊主頁中搜尋要分析的規則。

    3. 比較 Event time 和 Ingested time。

      舉例來說，如果特定規則偵測的 Event time 和 Ingested time 之間存在巨大差距，您可能可以將偵測延遲歸因於預期延遲。

  2. 查看內容來源收集時間：

    檢查內容來源的收集時間。

    情境感知規則可包含下列情境來源。查看收取時間：

    • 從 UDM 擴充功能衍生的欄位。
    • 包含 principal 欄位的事件。

    • 參照 graph.entity 欄位的規則。

      使用 graph.entity 語法參照實體內容圖 (ECG) 的規則，可能會導致延遲時間特別長。舉例來說，心電圖管道會產生脈絡資料，而這項程序可能需要 30 小時，有時甚至長達 8 天，具體時間取決於資料類型。

    詳情請參閱「資料處理延遲」。

  3. 檢查規則的執行頻率和比對期設定：

    • 頻率：檢查規則的執行頻率。如果規則設定為較不頻繁地執行，偵測延遲時間自然會較長。
    • 比對時間範圍：如果規則設有比對時間範圍，最短延遲時間就是該時間範圍的長度。
    • 頻率和比對間隔的關係：請確認執行頻率與比對間隔相容。舉例來說，如果比對時間範圍為 5 分鐘，則 10 分鐘的執行頻率是可以接受的。不過，如果比對時間範圍超過 10 分鐘，請使用下一個可用的執行頻率 (1 小時)。

  4. 查看近期事件：

    找出可能導致資料動態饋給延遲或發生問題的近期事件。

縮短延遲時間的訣竅

如要更新偵測規則設定，請參閱「使用規則編輯器管理規則」。

請盡可能使用下列技術來縮短延遲時間：

  • 如果是對延遲時間較為敏感的規則，請使用最頻繁的執行選項：

    • 提高規則執行頻率：

      如要減少延遲，請根據規則類型和比對視窗，盡可能設定最高頻率：

      • 單一事件規則：使用「近乎即時」。
      • 如果多事件規則的相符時間範圍小於 60 分鐘，請使用 10 分鐘。
      • 比對時間範圍為 60 分鐘以上的規則：視情況使用 1 小時或 24 小時。

      詳情請參閱「設定執行頻率」。

    • 縮短比對視窗時間：

      縮短比對視窗不會直接影響延遲時間，但設定最短延遲時間可提高效率。

  • 避免資料延遲送達：

    延遲抵達的資料會錯過初始查詢，系統只會在 5 到 8 小時後重新查詢事件時間區塊時處理這類資料，導致嚴重延遲。準時資料通常會延遲約 20 分鐘。

導致規則偵測延遲的因素

規則類型、執行頻率和 Google SecOps 的擷取速度，是造成規則偵測延遲的主要因素。

下列因素會導致規則偵測延遲。

規則類型

規則主要分為兩類：

單一事件規則

由於系統會採用串流方法，近乎即時地執行單一事件規則，因此請盡可能使用這類規則，以減少延遲。

這些規則會偵測單一事件，且不會使用參照清單、資料表、比對視窗，或使用者和實體行為分析 (UEBA)。這些規則會以串流方式近乎即時地執行，偵測延遲時間最短。

複雜的單一事件規則

這些規則包含比對期或參照清單，因此更容易發生偵測延遲：

  • 以時間範圍為準的單一事件規則

    這類規則屬於單一事件規則，包含比對時間範圍，且延遲時間通常會比其他單一事件規則稍長。比對視窗通常是指規則檢查一或多個事件的一段時間。

  • 參考單一事件規則

    這些是包含參照清單或資料表的單一事件規則。

多事件規則

多事件規則會依排程執行，因此排程執行之間的時間間隔會導致延遲時間較長。

  • 多重事件規則

    這類規則會檢查兩項以上的 UDM 事件條件。通常會設有比對視窗和多項條件。

  • 情境感知規則

    情境感知規則可協助您將其他實體和偵測情境資料加入事件。

    • 這類規則包含兩個以上的資料來源，其中至少一個條件是 UDM 實體事件 (UDM 事件屬於內容類型，例如 user_context)。
    • 情境感知規則對延遲抵達的資料最為敏感。
    • 情境感知規則通常會有最長的延遲時間，因為系統必須先生成必要的內容資料，例如實體內容圖表 中的資料。
    • 詳情請參閱「在規則中使用情境豐富的資料」。

進一步瞭解單一事件和多重事件規則的差異。

規則執行頻率

規則執行頻率會直接影響偵測延遲。

  • 近乎即時：系統會更頻繁地執行規則，以處理即時資料。這項設定僅適用於單一事件規則。
  • 其他頻率：如果是其他規則類型，您可以設定下列頻率：
    • 如果比對時間範圍小於 60 分鐘，10 分鐘的頻率上限即為有效。
    • 如果比對時間範圍不到 48 小時，則 1 小時和 24 小時的頻率皆有效。
    • 24 小時頻率適用於所有比對回溯期 >= 48 小時。

可能的解決方法：如要加快偵測速度，請縮短執行頻率。縮短比對視窗不會直接影響延遲時間，但設定最短延遲時間可提高效率。

比對時間範圍

如果規則有比對時間範圍，系統必須等待整個時間範圍結束，因此時間範圍的長度會決定最短的偵測延遲時間。

擷取延遲

擷取延遲是指事件發生後，Google SecOps 擷取資料所需的時間。

如果資料延遲抵達，就會錯過初始查詢時間範圍。後續的歷史記錄處理查詢會擷取這項資料，但可能會延遲 5 到 8 小時。

舉例來說，規則會尋找 30 分鐘內的兩個事件，而事件 A (事件時間為上午 9:03) 和事件 B (事件時間為上午 9:05) 符合這項條件。如果事件 A 在上午 10:05 送達 (延遲 1 小時)，就會錯過上午 9:00 至 9:30 區塊的初始查詢。如果後續查詢在下午 2 點到 5 點之間進行，就會產生偵測結果，導致延遲 5 到 8 小時。

疑難排解：確認您在事件發生後立即將資料傳送至 Google SecOps。查看偵測結果時，請仔細檢查 UDM 事件和擷取時間戳記。

時區問題

Google SecOps SIEM 的預設時區為世界標準時間。如果記錄未明確定義時區，系統會將其解讀為世界標準時間。如果解讀錯誤，系統可能會將記錄視為延遲抵達，導致偵測延遲，即使系統是即時收到記錄也一樣。

舉例來說，記錄的事件時間為美東時間上午 10:00 (世界標準時間下午 3:00)，但抵達時間為世界標準時間下午 3:05，且缺少時區。如果記錄缺少時區，系統會將事件時間解讀為世界標準時間 10:00。系統接著會計算出解讀的事件時間 (世界標準時間 10:00) 與實際擷取時間 (世界標準時間 15:05) 之間有 5 小時的延遲。由於規則會優先處理即時擷取的資料，因此計算出的延遲會導致偵測延遲。

解決方法：如果原始資料的事件時間戳記位於非世界標準時間的時區，請嘗試下列其中一種做法：

  • 更新原始資料的活動時區。
  • 如果無法在記錄來源更新時區，請與支援團隊聯絡，以覆寫時區。
  • 或者，您也可以使用 BindPlane 處理器修正時間戳記，並將格式設為世界標準時間，或新增適當的時區指標。詳情請參閱「使用 BindPlane 修改記錄主體時間戳記」。

內容比對彙整

如果多重事件規則使用 UEBA 或實體內容圖表欄位等情境資料，延遲時間可能會較長。Google SecOps 必須先生成內容比對資料。

充實系統

Google SecOps 會從其他來源新增背景資訊，擴充 UDM 事件。這項程序通常會在 30 分鐘內完成。如果延遲將這類增補資料新增至 UDM 事件，可能會增加偵測時間。

如要檢查規則是否正在評估經過擴充的欄位，請查看事件檢視器。如果規則評估的是經過擴充的欄位，偵測作業可能會延遲。

詳情請參閱「資料擴充」。

別名和充實資料

別名和擴充是 Google SecOps 安全性資料擴充程序中的兩個步驟，可將關聯和情境資料新增至事件記錄。別名會找出連線，擴充則會使用連線資料填入 UDM 欄位。這個程序填入的欄位稱為「別名欄位」或「擴充欄位」。

  • 別名：這是指找出並連結同一實體的不同名稱或 ID 的程序。並找出描述指標的其他背景資訊資料。舉例來說，別名可將單一 hostname (例如 alex-macbook) 連結至其他相關指標，例如 IP addresses 和 MAC addresses (來自 DHCP 記錄)。別名也可以將 user ID (例如 alex) 連接到使用者的 job title 和 employment status (來自使用者環境資料)。
  • 擴充：這個程序會使用別名程序收集的資訊，為 UDM 事件新增背景資訊。 舉例來說，當新事件只包含 IP address 時，擴充程序會使用別名資料找出相關聯的 hostname (例如 alex-macbook)，並填入 $udm.event.principal.hostname 欄位。

Google SecOps 支援多種實體類型的別名和擴充功能，包括資產 (例如主機名稱、IP 位址、MAC)、使用者、程序、檔案雜湊中繼資料、地理位置和雲端資源。詳情請參閱「UDM 擴充和別名總覽」。

重新擴充 UDM 事件

  • 基礎資料變更：如果基礎資料在系統擷取事件後發生變更，系統會重新處理歷來資料，並在 24 小時內更新事件。

  • 擴充系統更新：如果擴充系統更新實體或程序中繼資料、IP 位址地理位置或 VirusTotal 指標，規則引擎會在 24 到 48 小時後重新評估這些區塊，以擷取更新內容。
    舉例來說，上午 9:03 的事件有 entity.asset.hostname = hostnameA，但沒有 IP 位址。上午 8:55 的 DHCP 記錄顯示 hostnameA = IP 1.2.3.4。規則引擎會在上午 9:10 執行，但規則不相符。在該時間範圍內，擴充處理管道會將 hostnameA 與 1.2.3.4 相互關聯，並更新 UDM 事件。現在規則相符，系統會建立偵測結果。

  • 延遲傳送的內容資料：如果您在初始記錄後一天傳送內容資料 (例如 hostname)，系統會重新擴充 UDM 事件。尋找這項重新豐富資料的規則會再次執行，並建立偵測結果。這項功能可確保系統即使在脈絡延遲的情況下，仍能建立偵測結果。

  • 豐富化資料變更：豐富化資料變更可能會導致規則在稍後相符，即使一開始不相符也一樣。
    舉例來說，上午 9:03 的活動有 entity.ip_geo_artifact.country_or_region = USA。規則引擎會在上午 9:10 執行，查詢上午 9:00 至 10:00 的資料，但規則不相符。稍後，加強處理程序會將地理位置更新為加拿大。規則再次執行時，現在會相符，系統也會建立偵測結果。

實體背景資訊圖表處理

系統會產生並將實體內容圖 (ECG) 資訊新增至記錄檔資料，以提供內容，例如遭入侵指標 (IOC) 或資產內容資料。由於 ECG 管道主要依賴批次處理，實體內容資訊通常只會在規則執行後建立偵測結果時更新。

懷舊狩獵

使用回溯搜尋功能依據歷來資料執行規則時，系統只會在回溯搜尋程序完成後建立偵測結果。這個程序可能需要大量時間，導致偵測延遲。

追溯更新程序範例：

  1. 初始事件：事件會在下午 1 點抵達，並包含 ip_address = 10.0.0.5。目前 hostname 不明。
  2. 別名來源抵達：下午 2:30 (超過一小時後)，系統收到下午 1:00 的 DHCP 記錄，將 10.0.0.5 連結至 workstation-123。
  3. 追溯擴充：別名系統會處理這個新連結。系統會回溯更新下午 1:00 的 UDM 事件，並在先前空白的 $udm.event.principal.hostname 欄位中填入 workstation-123 值。
  4. 偵測：後續規則重播會看到經過擴充的值 (workstation-123)，並觸發先前錯過的偵測。

注意：您無法區分即時偵測規則和回溯搜尋偵測規則的延遲監控指標。為避免偵測延遲監控指標發生偏差，請勿使用即時規則模擬回溯搜尋規則。最佳做法是建立專屬的偵測規則，並以回溯搜尋規則的形式執行。

參照清單

規則執行作業一律會使用參照清單的最新版本。排程規則再次執行時，系統會根據更新的參照清單內容建立新的偵測結果。這些偵測結果可能會延遲顯示，因為系統是根據參考清單更新前擷取的資料進行偵測。

如要縮短偵測延遲時間，請執行下列操作：

  • 事件發生後，請立即將記錄資料傳送至 Google SecOps。
  • 請檢查稽核規則，判斷是否要使用不存在的資料或情境豐富的資料。
  • 設定較小的執行頻率。

不存在規則

系統會等待至少一小時，才會執行檢查不存在的規則 (例如包含 !$e 或 #e=0 的規則)，確保資料有時間送達。

資料處理延遲

即使系統已完成初始偵測，仍可能會繼續處理資料，進而產生新的或更新的偵測結果。詳情請參閱「觸發規則重播的時機」。

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