搜尋的最佳做法

支援的國家/地區：

本文說明在 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_sids

來源欄位

  • 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

建構成效良好的搜尋查詢

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

udm-field operator value

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

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

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

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

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

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

使用 nocase 做為搜尋修飾符

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

舉例來說，下列搜尋無效：

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 Epoch 時間

系統會使用 Unix 紀元時間 (自 1970 年 1 月 1 日星期四 00:00:00 UTC 起經過的總秒數)，比對時間戳記欄位。

搜尋特定時間戳記時，下列 (以 Epoch 時間為準) 為有效值：

metadata.ingested_timestamp.seconds = 1660784400

下列時間戳記無效：

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

從篩選器中排除欄位

搜尋篩選器刻意排除下列欄位。雖然這些屬性包含重要的中繼資料，但高度獨特的值可能會導致不必要的搜尋詳細資料，並降低查詢引擎的整體效率和效能：

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

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