情境感知數據分析總覽

支援的國家/地區：

在 Google SecOps 帳戶中，您可以將遙測資料、實體背景資訊、關係和安全漏洞視為單一偵測結果。這項功能提供實體脈絡化功能，可協助您瞭解遙測中的行為模式，以及受這些模式影響的實體脈絡。

範例：

  • 顯示嘗試暴力登入的帳戶權限。
  • 資產代管的資料重要性，該資產也是對外網路活動的來源。

客戶能運用這類脈絡化資訊進行偵測篩選、優先處理啟發式快訊、分類及調查。

安全分析師和偵測工程師通常會根據事件遙測的基本模式 (外送網路連線) 建立偵測機制，為分析師建立大量偵測機制以進行分類。分析師會嘗試拼湊出觸發警報的原因，以及威脅的嚴重程度。

情境感知分析會在偵測規則編寫和執行工作流程中，更早納入進階擴充功能，讓您提供下列額外功能：

  • 在偵測執行階段 (而非人工分類階段)，提供相關背景資訊，以利根據啟發式方法計算偵測結果的情境風險評分
  • 減少花費在分類和手動整合資訊的時間，這些資訊來自不同的 IT 安全系統 (EDR 控制台、防火牆或 Proxy 記錄、CMDB 和 IAM 環境、弱點掃描結果)
  • 讓分析師和偵測工程師篩除整個叢集的威脅，這些威脅可能屬於預期情況，或對企業幾乎沒有危險 (例如在沙箱環境中測試惡意軟體、在沒有機密資料或存取權的開發網路中出現的異常活動和漏洞等)

編寫情境感知分析的規則

您可以使用偵測引擎規則，在 Google SecOps 帳戶中搜尋實體內容資料。

如要搜尋實體內容資料，請完成下列步驟：

  1. 使用 UDM 或實體指定來源。

    $eventname.[<source>].field1.field2 如為實體情境，<source> 為「graph」。如果是 UDM 事件，<source> 為 'udm'。如果省略，<source> 預設為 udm。

  2. 指定實體資料：

    $e1.graph.entity.hostname = "my-hostname"

    $e1.graph.entity.relations.relationship = "OWNS"

  3. 指定 UDM 事件資料。下列陳述式是等效的。

    $e1.udm.principal.asset_id = "my_asset_id"

    $e1.principal.asset_id = "my_asset_id"

您可以為實體環境建立許多與 UDM 事件相同的規則類型，包括：

  • 多個事件規則

    規則不可能只使用實體。

  • 比較實體內容與其他實體內容

  • 比較實體內容與 UDM 事件

  • 實體內容中的重複欄位

  • 橫拉窗

  • 計算偵測項目的風險分數

與 UDM 事件不同，實體內容沒有特定時間戳記。每個實體內容記錄都有時間間隔 (entity.metadata.interval)，實體內容在此間隔內有效。這個時間間隔可能不是一天，可以是任何長度。

只有在 UDM 事件的時間戳記位於實體背景資訊記錄的時間間隔內，系統才會將 UDM 事件與實體背景資訊記錄建立關聯。如未符合這項條件，系統就不會評估 UDM 和實體是否偵測到威脅。偵測引擎會隱含地強制執行這項操作，您不需要在規則中將其指定為條件。

  • 將 UDM 事件與具有視窗化的實體內容進行比較時，實體內容代表指定視窗的常數值。
  • 如果相鄰的日期範圍內實體內容的值有所變更，Google SecOps 會嘗試比對所有實體內容值，並傳回找到的所有相符項目。

規則範例

以管理員環境搜尋實體

下列規則會搜尋也與管理員權限相關的實體。系統會尋找具備管理員權限的使用者嘗試登入或登出系統的時間。

rule LoginLogout {
  meta:
  events:
    ($log_inout.metadata.event_type = "USER_LOGIN" or  $log_inout.metadata.event_type = "USER_LOGOUT")
    $log_inout.principal.user.user_display_name = $user

    $context.graph.entity.user.user_display_name = $user
    $context.graph.entity.resource.attribute.roles.type = "ADMINISTRATOR"

  match:
    $user over 2m

  condition:
    $log_inout and $context
}

滑動視窗範例

以下是有效的滑動視窗範例。

rule Detection {
  meta:
  events:
    $e1.graph.entity.hostname = $host
    $e2.udm.principal.hostname = $host

  match:
    // Using e2 (a UDM event) as a pivot.
    $host over 3h after $e2

  condition:
    $e1 and $e2
}

無效的滑動視窗範例

下列滑動視窗範例無效。實體內容無法做為滑動視窗的樞紐。

rule Detection {
  meta:
  events:
    $e1.graph.entity.hostname = $host
    $e2.udm.principal.hostname = $host

  match:
    // Attempting to use $e1 (an entity context) as a pivot. Invalid.
    $host over 3h after $e1

  condition:
    $e1 and $e2
}

使用結果部分的登入範例

下列範例使用 outcome 區段計算偵測項目的風險分數。

rule Detection {
  meta:
  events:
    $auth.metadata.event_type = "USER_LOGIN"
    $auth.metadata.vendor_name = "Acme"
    $auth.metadata.product_name = "Acme SSO"
    $auth.target.user.userid = $user
    $auth.metadata.event_timestamp.seconds >
       $context.graph.entity.user.termination_date.seconds

    $context.graph.metadata.vendor_name = "Microsoft"
    $context.graph.metadata.product_name = "Azure Active Directory"
    $context.graph.metadata.entity_type = "USER"
    $context.graph.entity.user.userid = $user
    $context.graph.entity.user.termination_date.seconds > 0

  match:
    $user over 15m

  outcome:
    $risk_score = max(
        if ( $auth.metadata.event_type = "USER_LOGIN", 50) +
        if (
            $context.graph.entity.user.title = "Remote" nocase or
            $context.graph.entity.user.title = "Temp" nocase or
            $context.graph.entity.user.title = "Vendor" nocase, 40) +
        if ( $context.graph.entity.user.title = "Legal" nocase, 10)
    )

  condition:
    $auth and $context
}

可疑程序啟動示例

以下範例會根據儲存為實體內容的 IOC 內容資料，評估 UDM 事件處理程序資料。

rule ProcessLaunch {
  meta:
  events:
    $ioc.graph.metadata.vendor_name = "ACME"
    $ioc.graph.metadata.product_name = "IOCs"
    $ioc.graph.metadata.entity_type = "FILE"
    $ioc.graph.entity.file.sha256 = $hash

    $process.metadata.event_type = "PROCESS_LAUNCH"
    $process.principal.hostname = $hostname
    (
        not $process.target.process.file.sha256 = "" and
        $process.target.process.file.sha256 = $hash
    )

  match:
    $hash over 15m

  condition:
    $ioc and $process
}

實體內容的其他限定符

如要建立使用實體內容的事件變數，您必須在事件名稱後方提供 <source>。<source> 必須為 graph。

下列模式是指實體內容：

  • $e.graph.entity.hostname

請注意，有兩種等效方法可參照 UDM 事件：

  • $u.udm.principal.asset_id
  • $u.principal.asset_id

您可以在規則文字中混搭使用所有這些限定詞。您也可以為同一事件使用不同的限定詞。

結果區段

偵測引擎支援 outcome 區段，可從規則中衍生更多資訊。系統會根據每項偵測結果評估 outcome 區段中定義的邏輯。如果規則產生 N 個偵測結果，每個偵測結果可能會導致不同的結果。

如需使用 outcome 區段的規則範例，請參閱這篇文章。

如要瞭解 outcome 區段的詳細用法和語法，請參閱結果部分。

結果部分和偵測重複資料 / 偵測分組

對於含有相符部分的規則，請注意，系統會「依」相符變數「分組」偵測結果。這樣一來，系統會將偵測結果去重複，針對每組不重複的相符變數和時間範圍，傳回一列資料。

執行這項去重複作業時，系統會忽略結果變數。因此，如果兩次偵測的相符變數和時間範圍值相同，但結果變數值不同，系統會將這兩次偵測結果重複計算，只顯示一次偵測結果。舉例來說，如果資料延遲抵達，就可能會導致系統建立偵測結果。以下是說明這個情況的範例。

rule ExampleOutcomeRule {
  ...
  match:
    $hostname over <some window>
  outcome:
    $risk_score = <some logic here>
  ...
}

這項規則會產生下列相符項目：

偵測 1： hostname: test-hostname time window: [t1, t2] risk_score: 10

偵測 2： 主機名稱：test-hostname 時間範圍：[t1, t2] 風險分數：73

由於「偵測 1」和「偵測 2」的相符變數和時間範圍相同，因此系統會將這兩項偵測結果重複資料刪除，即使結果變數 risk_score 不同，您也只會看到一項偵測結果。

後續步驟

如要瞭解 Google SecOps 如何擷取背景資料並擴充實體，請參閱「Google SecOps 如何擴充事件和實體資料」一文。

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