UDM 搜尋與規則結果的比較

支援語言：

Google SecOps SIEM

在 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 搜尋查詢與偵測規則之間有差異，請按照下列步驟調整結果：

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

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