搜尋的最佳做法

支援語言：

本文說明在 Google Security Operations 中使用「搜尋」功能的最佳做法。如果搜尋查詢的建構方式不當，可能會需要大量運算資源。效能也會因 Google SecOps 執行個體中的資料大小和複雜度而異。

在查詢中使用特定篩選器，盡可能提升速度和效能

如要提升搜尋效能，最有效的方法就是使用特定且經過最佳化的統合式資料模型 (UDM) 欄位建構查詢。這些欄位經過最佳化處理，可快速擷取資料，確保搜尋作業能快速執行，並減少運算資源用量。

下列各節列出高成效 UDM 欄位，可用於查詢中的篩選條件。

主要欄位

  • principal.asset.hostname
  • principal.asset.ip
  • principal.asset.mac
  • principal.file.md5
  • principal.file.sha1
  • principal.file.sha256
  • principal.hostname
  • principal.ip
  • principal.mac
  • principal.process.file.md5
  • principal.process.file.sha1
  • principal.process.file.sha256
  • principal.process.parent_process.file.md5
  • principal.process.parent_process.file.sha1
  • principal.process.parent_process.file.sha256
  • principal.user.email_addresses
  • principal.user.product_object_id
  • principal.user.userid
  • principal.user.windows_sid

來源欄位

  • source.user.userid
  • src.asset.hostname
  • src.hostname
  • src.ip

目標欄位

  • target.asset.hostname
  • target.file.md5
  • target.file.sha1
  • target.file.sha256
  • target.hostname
  • target.ip
  • target.process.file.md5
  • target.process.file.sha1
  • target.process.file.sha256
  • target.user.email_addresses
  • target.user.product_object_id
  • target.user.userid
  • target.user.windows_sid

額外欄位

  • about.file.md5
  • about.file.sha1
  • about.file.sha256
  • intermediary.hostname
  • intermediary.ip
  • network.dns.questions.name
  • network.email.from
  • network.email.to
  • observer.hostname
  • observer.ip

如何查詢實體和比對內容資料

如果您使用 metadata.log_type = "<LOG_TYPE>" 搜尋實體或內容記錄類型 (例如 AZURE_AD_CONTEXT 或 WORKSPACE_USERS)，即使原始記錄顯示在「原始記錄搜尋」中，搜尋也不會傳回任何結果。這是因為 UDM 搜尋只會查詢 UDM 事件記錄。

如要搜尋實體和比對內容資料，請使用 graph 語法：

  • 如要搜尋實體或脈絡記錄類型，請查詢 graph 中繼資料欄位。例如：

    graph.metadata.event_metadata.log_type = "<LOG_TYPE>"

  • 如要搜尋實體欄位，請使用前置字串 graph.entity.noun.field。例如：

    graph.entity.user.email_addresses = "foo_email"

詳情請參閱「搜尋實體比對內容資料」。

建構成效良好的搜尋查詢

撰寫最佳化查詢是提高速度的關鍵，可盡量減少安全資料的資源耗用量。所有查詢條件都必須嚴格遵守以下基本結構：

udm-field operator value

例如：principal.hostname = "win-server"

由於 Google SecOps 可以在搜尋期間擷取大量資料，因此縮短時間範圍並縮小查詢範圍，有助於提升搜尋效能。

在搜尋查詢中使用規則運算式

建構 UDM 搜尋查詢時，您可以使用標準邏輯和比較運算子來建構複雜的運算式：

  • 邏輯運算子：使用 AND、OR 和 NOT 組合條件。如果省略兩個條件之間的運算子，系統會假設為 AND。
  • 運算子優先順序：使用括號 () 覆寫預設優先順序。括號內最多可使用 169 個邏輯運算子 (OR、AND、NOT)。
  • 比較運算子：視 UDM 欄位類型 (字串、整數、時間戳記) 而定，欄位運算子可能包括：=、!=、>=、>、<、<=

Google SecOps 使用 RE2 規則運算式引擎。

或者，如要有效率地搜尋大量值，可以使用參照清單。

使用 nocase 做為搜尋修飾符

您可以在字串比較條件中附加 nocase 修飾符，讓搜尋忽略大小寫。

舉例來說，下列搜尋會忽略大小寫，並比對所有含有 tim.smith 的組合 (不論大小寫)：

target.user.userid = "TIM.SMITH" nocase

避免在列舉欄位中使用規則運算式

搜尋列舉欄位 (具有預先定義值範圍的欄位) 時，無法使用規則運算式，例如 metadata.event_type 或 network.ip_protocol

以下範例是無效的搜尋： metadata.event_type = /NETWORK_*/

以下範例則是有效搜尋： (metadata.event_type = "NETWORK_CONNECTION" 或 metadata.event_type = "NETWORK_DHCP")

在「事件」欄位中使用任何運算子

在搜尋中，部分 UDM 欄位 (例如 principal.ip 或 target.file.md5) 會標示為「重複」，因為這些欄位可在單一事件中保留值或訊息類型清單。根據預設，系統一律會使用 any 運算子處理重複欄位 (無法指定 all)。

使用 any 運算子時，如果重複欄位中的任何值符合條件，述詞的評估結果就會是 true。舉例來說，如果您搜尋 principal.ip != "1.2.3.4"，且搜尋結果中的活動同時包含 principal.ip = "1.2.3.4" 和 principal.ip = "5.6.7.8"，系統就會產生比對結果。這樣一來，搜尋範圍就會擴大，包含符合任一運算子的結果，而非符合所有運算子的結果。

系統會個別處理重複欄位中的每個元素。如果在搜尋結果的事件中找到重複欄位，系統會評估該欄位中的每個元素。這可能會導致非預期的行為，特別是使用 != 運算子搜尋時。

使用 any 運算子時，如果重複欄位中的任何值符合條件，述詞的評估結果就會是 true。

使用 Unix 紀元時間做為時間戳記，或使用 YARA-L 函式轉換日期

時間戳記欄位會使用 Unix 紀元時間 (自 1970 年 1 月 1 日星期四 00:00:00 UTC 以來經過的總秒數) 比對，您也可以使用 YARA-L 函式轉換日期。

搜尋特定時間戳記時，下列 (以紀元時間表示) 為有效值：

metadata.ingested_timestamp.seconds = 1660784400

下列時間戳記無效：

metadata.ingested_timestamp = "2022-08-18T01:00:00Z"

搜尋特定時間戳記時，下列項目 (使用 YARA-L 函式進行日期轉換) 有效：

metadata.event_type = "NETWORK_CONNECTION"
timestamp.get_date(metadata.ingested_timestamp.seconds) = "2026-03-15"

下列 YARA-L 範例會使用 timestamp 函式檢查擷取時間範圍：

metadata.event_type = "NETWORK_CONNECTION"
$date = timestamp.get_date(metadata.ingested_timestamp.seconds)
$date > "2026-03-15" AND $date < "2026-03-17"

如何查詢時間戳記較舊的新擷取資料

除非指定要查詢的事件時間範圍，否則無法搜尋時間戳記較舊的新擷取事件。這是因為時間範圍是以已剖析事件的時間戳記為準，而非原始記錄事件的擷取時間戳記。

如要搜尋具有較舊事件時間戳記的已擷取記錄 UDM 事件，可以使用「不限時間」選項，搜尋及查詢超過 metadata.ingested_timestamp 的資料。

從篩選器中排除的欄位

下列欄位刻意排除在搜尋篩選器之外：

  • metadata.id
  • metadata.product_log_id
  • *.timestamp

雖然這些欄位包含重要的中繼資料，但其獨特值會導致統計資料出現高基數和變異，進而對搜尋效能造成負面影響。

疑難排解

如果收到一般錯誤訊息，例如「錯誤：搜尋發生錯誤，無法載入資料」，請按照下列步驟解決問題。如果錯誤持續發生，請聯絡客戶支援團隊。

  • 從其他網路連線至 Google SecOps。舉例來說，您可以使用雲端 VM 找出任何網路問題。
  • 請確認貴機構的防火牆、Proxy 設定或政策允許 Chronicle API 呼叫。
  • 確認搜尋 API 呼叫未設定任何資料限制，因為搜尋可能會傳回大型資料集。
  • 搜尋查詢可以非同步執行，可能需要較長時間才能傳回資料。您可以在搜尋記錄中查看先前執行的搜尋，並選取這些搜尋來查看結果。

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