瞭解規則偵測延遲

支援語言：

本文說明 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 等維度是瞭解特定偵測作業延遲原因的良好啟發式方法。

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

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

偵測產生方法

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

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

  1. 串流引擎

    串流引擎是專屬的串流管道，運作時延遲時間很短 (通常不到五分鐘)。這項功能會評估標準單一事件規則，這些規則不含相符區段、不含外部資料集 (例如參照清單或資料表)，且不含 UEBA 函式。

  2. 查詢引擎

    查詢引擎會評估複雜的單一事件和多重事件規則：

    • 複雜的單一事件規則：

      • 含有參照清單或資料表的單一事件規則：評估單一事件，並根據參照清單或資料表執行查閱作業的規則。
      • 單一事件規則 (設有時間範圍)：這類規則會評估單一事件，並設有比對時間範圍和簡單的存在條件 (例如 $e、#e > 0 或 #e >= 1)。
      • 複雜的單一事件規則會使用查詢引擎，而非串流引擎，但系統會在擷取新資料時，以高頻率的「近乎即時」排程執行這些規則。這樣可提供接近串流引擎一般延遲時間的較低延遲時間。在標準查詢執行期間，系統會重新評估稍後抵達的強化資料，無須多重事件的補償間隔。

    • 多事件規則：這類規則會根據您設定的排程，查詢一段時間內的事件時間資料 (10 分鐘、每小時、每天)。延遲抵達資料的重新查詢時間取決於排程類型。

      • 如果是預設時間表，系統會在事件時間後約 5 小時和 24 小時重新查詢。
      • 自訂時間表提供不同的結算時間。 詳情請參閱「瞭解規則重播和 MTTD」。

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

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

  4. 重新擴充 UDM 事件

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

已知限制

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

  • 有時，強化作業可能會比預期更久。重新處理擴充功能會導致後續規則執行作業重新評估資料。系統會多次執行擴充作業，且擴充作業最多會在事件擷取後 24 小時內更新 UDM 事件。

  • 多事件規則：

    • 如果多事件規則採用預設排程，系統會在事件發生後約 5 小時和 24 小時重新執行規則。

    • 可自訂排程的多事件規則有不同的結算時間。

    系統會觸發這些規則重播，以處理延遲送達的資料。

  • 情境感知規則會依據資產和身分別名，或實體情境圖表等擴充來源。由於這些規則依賴多個事件來源，因此更容易發生高延遲。

  • 系統會在首次執行規則後的 5 到 8 小時內，以及 24 到 48 小時內，重新執行規則。這兩項不同的規則重播會根據重新處理管道的執行時間觸發。

  • 如需其他偵測限制，請參閱「瞭解偵測限制」。

排解規則偵測延遲問題

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

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

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

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

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

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

    3. 比較 Event time 和 Ingested time。

      舉例來說，如果特定規則偵測的 Event time 和 Ingested time 之間存在巨大差距，您可能可以將偵測延遲歸因於預期延遲。如果 Ingestion time 比 Event time 晚超過 30 分鐘，系統會在「偵測類型」欄中套用 圖示。

  2. 查看脈絡來源收集時間：

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

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

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

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

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

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

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

    • 頻率：檢查規則的執行頻率。如果規則設定為較不頻繁地執行，偵測延遲時間自然會較長。
    • 比對時間範圍：如果規則有比對時間範圍，最短延遲時間就是該範圍的長度。
    • 頻率和比對視窗的關係：請確認執行頻率與比對視窗相容。舉例來說，如果比對時間範圍在 60 分鐘內，系統支援 10 分鐘 (近乎即時) 的執行頻率。如果比對時間範圍為 60 分鐘以上 (最長 48 小時)，請使用 1 小時。如要設定超過 48 小時的比對時間範圍，請使用「每日」。

  4. 查看近期事件：

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

縮短延遲時間的訣竅

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

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

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

    • 提高規則執行頻率：

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

      • 所有單一事件規則：使用「近乎即時」。
      • 如果多事件規則的比對時間範圍小於 60 分鐘，請使用「接近即時 (10 分鐘)」。
      • 對於比對時間範圍為 60 分鐘以上的多事件規則：請視需要使用「1 小時」或「每日」。

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

    • 縮短比對視窗時間：

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

  • 避免資料延遲送達：

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

導致規則偵測延遲的因素

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

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

規則類型

規則主要分為兩類：

單一事件規則

標準單一事件規則會偵測個別事件，不需外部資料查閱、比對時間範圍或使用者和實體行為分析 (UEBA)。這些規則會使用專屬串流引擎近乎即時執行，並達到最低偵測延遲時間 (通常少於五分鐘)。

複雜的單一事件規則

複雜的單一事件規則會評估個別事件，但會納入參照清單、資料表或簡單的相符時間範圍。這些查詢會使用查詢引擎而非串流引擎執行，但會以近乎即時的排程執行，延遲時間接近串流引擎：

  • 參考清單和資料表單一事件規則：

    這類單一事件規則會根據參照清單或資料表執行查詢，不需要多重事件比對視窗。

  • 設有時間範圍的單一事件規則：

    這些單一事件規則包含比對視窗，以及簡單的事件計數條件 (例如 $e、#e > 0 或 #e >= 1)。

多事件規則

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

  • 多重事件規則

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

  • 情境感知規則

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

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

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

規則執行頻率

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

  • 近乎即時：系統會在擷取事件時執行規則，延遲時間極短。適用於：
    • 所有單一事件規則 (標準單一事件、含參照清單或資料表的規則，以及含時間範圍的單一事件規則)。
    • 比對時間範圍不到 60 分鐘的多事件規則。
  • 其他頻率：如需其他規則設定，您可以設定下列頻率：
    • 如果比對時間範圍小於 60 分鐘，10 分鐘的頻率上限即為有效。
    • 如果比對時間範圍在 48 小時內，則可使用 1 小時和每日頻率。
    • 如果比對時間範圍超過 48 小時，則每日頻率有效。

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

比對時間範圍

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

擷取延遲

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

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

舉例來說，事件 A (事件時間為上午 9:03) 和事件 B (事件時間為上午 9:05) 屬於一項規則，該規則會尋找 30 分鐘內的兩個事件。如果事件 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:00 收到事件，其中包含 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 專業人員尋求解答。