UDM 搜尋與規則結果的比較

支援的國家/地區：

在 Google Security Operations 中調查安全遙測資料時，您可能會發現 Unified Data Model (UDM) 搜尋查詢傳回的事件計數，與即時 YARA-L 2.0 偵測規則產生的偵測結果有所不同。

雖然搜尋查詢和偵測規則都使用 UDM，且共用核心 YARA-L 2.0 語法，但兩者在不同的執行引擎上執行，評估不同時間範圍內的資料，且處理重複欄位和重複資料的方式也不同。

以下各節說明搜尋結果與偵測規則快訊的差異，以及如何在調查期間比對結果計數。

主要差異摘要

下表比較 UDM 搜尋查詢與即時 YARA-L 2.0 偵測規則的行為：

屬性 UDM 搜尋和統計查詢 YARA-L 2.0 偵測規則
執行模式 在搜尋時，針對編入索引的過往記錄執行臨時查詢。 持續評估串流擷取的資料或排定的重播。
支援的區段 篩選陳述式、選用 match、outcome、選用 dedup、order 和 limit。不會使用 events、condition 或 option 區段。 meta、events、選用 match、outcome、condition (必要) 和選用 option。
回溯期 每次執行搜尋時，最多可掃描過去 90 天的已建立索引資料。 持續評估擷取的事件。多事件規則會在設定的 match 視窗內評估 (除非使用 Retrohunt 執行，否則最長為 24 小時)。
結果列數上限 每次執行統計搜尋時，最多可傳回 10,000 列。 系統不會限制一段時間內產生的偵測結果數量，但每個偵測結果在使用者介面中，最多會根據每個相符變數取樣 10 個基礎事件。
重複欄位 (any) 重複欄位會隱含使用 any 評估行為。如果陣列中的任何元素符合運算式，條件即為相符。 重複欄位會解除巢狀，變成個別資料列。如要比對任何項目，多值重複欄位必須明確指定 any 運算子。
時間範圍匯總 avg()、stddev()、max() 和 sum() 等函式不需要 outcome 區段中的 window. 前置字元。 outcome 中的統計和排序函式需要 window. 前置字元 (例如 window.avg()) 才能繫結至 match 視窗。
時間精細程度 (by** 與 over)** 支援依時間精細程度 (by <duration> 或 over every <duration>，例如 by 1h) 分組的滾動視窗。不支援滑動視窗關聯 (over 搭配 before 或 after)。 支援跳躍 (over <duration>)、滾動 (by <duration>) 和滑動 (over <duration> before/after $pivot) 關聯時間範圍。
重複資料刪除行為 除非定義明確的 dedup 區段，否則會傳回所有相符的事件或分組統計資料列。 自動刪除相鄰視窗中具有相同 match 變數的偵測結果，避免出現大量快訊。
剖析器和結構定義版本 使用搜尋執行時有效的剖析器正規化和結構定義表示法評估資料。 在事件擷取時，對剖析器有效版本產生的事件表示法進行運算。

重複欄位和取消巢狀結構的行為

UDM 搜尋傳回的相符事件數量多於 YARA-L 偵測規則，最常見的原因是重複欄位 (例如 principal.ip、target.file.md5 和 security_result.action 等陣列) 的評估方式。如需語法詳細資料，請參閱「重複欄位」。

  • UDM 搜尋：重複欄位會隱含使用 any 語意。如果您篩選 principal.ip = "10.0.0.1"，搜尋結果會傳回 principal.ip 陣列中任何位置出現 "10.0.0.1" 的事件。
  • YARA-L 偵測規則：重複欄位會取消巢狀結構，成為個別的評估資料列。撰寫偵測規則條件時，如果沒有明確的 any 量詞語法，針對多值重複欄位的等式檢查行為可能與搜尋不同。

含有明確 any 運算子的事件條件範例

如要確保偵測規則與 UDM 搜尋的重複欄位條件相符，請在事件條件中使用明確的 any 運算子：

events:
  // Match if any IP in the repeated array equals the target IP
  any $e.principal.ip = "10.0.0.1"

視窗匯總和語法差異

將 YARA-L 2.0 統計查詢從搜尋功能遷移至偵測規則時，請調整 outcome 和 match 區段中的語法：

  • window. 前置字元：在 UDM 搜尋中，可以直接呼叫 $avg_bytes = avg(network.sent_bytes) 等統計函式。在 YARA-L 偵測規則中，統計函式 (avg、stddev、percentile 和 variance) 和排序函式 (first 和 last) 需要 window. 前置字元 (例如 window.avg($e.network.sent_bytes))，才能將計算結果繫結至規則的 match 視窗。基本匯總函式 (max、min、sum 和 count) 不需前置字元。詳情請參閱「結果區段語法」。
  • 事件變數：偵測規則需要將事件指派給事件變數 (例如 $e.metadata.event_type = "NETWORK_CONNECTION")，而 UDM 搜尋會直接參照 UDM 欄位，不使用變數前置字元 (metadata.event_type = "NETWORK_CONNECTION")。
  • 滑動事件視窗：偵測規則支援複雜的滑動關聯視窗 ($e1.metadata.event_timestamp.seconds > $e2.metadata.event_timestamp.seconds)，而 UDM 搜尋則會依固定時間間隔 (by 1h 或 over every 1d) 將資料集分組。詳情請參閱「視窗邏輯」。

重複項目和警示抑制

UDM 搜尋會回報所選時間範圍內每個相符的事件或匯總值。相較之下，即時偵測引擎會自動去重複和取樣：

  • 完全相符的變數：如果偵測規則在相鄰的時間範圍內，針對相同的 match 變數組合 (例如相同的 $hostname 和 $user) 觸發多次，規則引擎就會抑制重複的快訊，避免分析師疲乏。詳情請參閱「在搜尋和資訊主頁中使用重複資料刪除功能」。
  • 測試規則與直播引擎：在規則編輯器中手動執行測試規則時，使用的重複資料刪除限制比直播引擎寬鬆。測試規則時，系統可能會根據歷來資料顯示較高的偵測次數，但實際擷取這些事件時，產生的即時快訊可能較少。

回溯期和擷取延遲

  • 擷取延遲：UDM 搜尋統計匯總作業會對已建立索引的記錄資料執行。最近擷取的事件可能會有短暫的索引延遲，才會顯示在匯總搜尋查詢中。
  • 歷來擷取時間範圍：多重事件偵測規則會評估時間範圍內的串流資料。如果事件的擷取順序有誤，或是在發生時間戳記後超過 24 小時才送達，即時多重事件規則可能不會產生偵測結果。如要根據新規則或更新規則掃描舊的歷史資料，請執行回溯搜尋工作。如需操作說明，請參閱「針對歷來資料執行規則」。
  • 剖析器隨時間變更：如果剖析器經過更新或修正，UDM 搜尋中的歷來掃描作業會立即反映更新後的常態化結果。即時規則偵測結果會反映擷取記錄時的確切剖析狀態。

調查期間的數量對帳

如果發現 UDM 搜尋查詢與偵測規則之間有差異，請按照下列步驟調整結果：

  1. 檢查重複欄位：確認事件條件是否篩選重複欄位，並確保規則在適當位置明確使用 any。
  2. 對齊時間範圍：請確認搜尋查詢的時間範圍符合規則偵測期間的開始和結束時間戳記。
  3. 考量重複資料刪除：請注意，搜尋次數代表原始事件量或未抑制的分組，而偵測次數則反映不重複 match 鍵的重複資料刪除警報。
  4. 驗證剖析器版本：如果舊事件在搜尋結果中顯示的 UDM 欄位值與舊快訊不同，請檢查自原始事件擷取以來，是否發生剖析器更新。

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