UDM 總覽

支援的國家/地區：

Google SecOps SIEM

本文將概略說明 Unified Data Model (UDM)。如要進一步瞭解 UDM 欄位 (包括各欄位的說明)，請參閱 UDM 欄位清單。如要進一步瞭解剖析器對應，請參閱「剖析器對應的重要 UDM 欄位」。

UDM 是 Google Security Operations 的標準資料結構，用於儲存從來源接收的資料相關資訊。也稱為「結構定義」。 Google SecOps 會以兩種格式儲存收到的原始資料：原始記錄和結構化 UDM 記錄。UDM 記錄是原始記錄的結構化表示法。

如果指定記錄類型有剖析器，系統會使用原始記錄建立 UDM 記錄。客戶也可以先將原始記錄轉換為結構化 UDM 格式，再使用 Ingestion API 將資料傳送至 Google SecOps。

UDM 的優點包括：

• 使用相同的語意，儲存來自不同供應商的相同類型記錄。
• 資料會正規化為標準 UDM 結構定義，因此更容易識別使用者、主機和 IP 位址之間的關係。
• 規則可獨立於平台，因此更容易編寫。
• 更輕鬆支援新裝置的記錄類型。

注意： Google SecOps 規則引擎使用相同的 UDM 欄位名稱。建立規則時，您可以使用這些相同的欄位名稱。

雖然您可以使用原始記錄搜尋功能搜尋事件，但 UDM 搜尋功能更具體，因此速度更快且更準確。Google SecOps 會收集原始記錄資料，並將事件記錄詳細資料儲存在 UDM 結構定義中。UDM 提供數千個欄位的完整架構，可用於說明及分類各種事件類型，例如端點程序事件和網路通訊事件。

UDM 結構

UDM 事件由多個部分組成。每個 UDM 事件的第一個部分都是中繼資料部分。這份記錄會提供事件的基本說明，包括事件發生時間戳記，以及事件擷取至 Google SecOps 的時間戳記。還包括產品資訊、版本和說明。無論是哪個產品記錄，擷取剖析器都會根據預先定義的事件類型分類每個事件。光是使用中繼資料欄位，您就能快速開始搜尋資料。

除了中繼資料部分，其他部分也會說明活動的其他層面。如果某個區段不必要，系統就不會納入，以節省記憶體。

• principal：在事件中發起活動的實體。也包含參照來源 (src) 和目的地 (target) 的章節。
• intermediary：事件傳送時經過的系統，例如 Proxy 伺服器或 SMTP 轉發服務。
• observer：被動監控流量的系統，例如封包監聽器。

設定 UDM 事件格式

如要格式化 UDM 事件，以便傳送至 Google，請完成下列步驟：

1. 指定事件類型：您選取的事件類型會決定必須一併納入事件的欄位。
2. 指定事件時間戳記。
3. 指定名詞 (實體)：每個事件都必須包含至少一個名詞，用來描述參與事件的裝置或使用者。
4. 選用：指定安全性結果：提供安全性系統發現的風險和威脅詳細資料，指定安全性結果。請列出您採取哪些具體行動來降低這些風險和威脅。
5. 使用 UDM 事件欄位填寫其餘必要和選填的事件資訊。

指定事件類型

以 UDM 格式提交的任何事件，最重要的值就是事件類型，可使用 Metadata.event_type 的其中一個可能值指定。包括 PROCESS_OPEN、FILE_CREATION、USER_CREATION、NETWORK_DNS 等值 (如需完整清單，請參閱 Metadata.event_type。每種事件類型都需要填入一組其他欄位和值，並提供與原始事件相關的資訊。 如要瞭解各事件類型應納入哪些欄位，請參閱「各 UDM 事件類型的必填和選填欄位」。以下範例說明如何使用 Proto3 文字標記，將 PROCESS_OPEN 指定為事件類型：

metadata {
    event_type: PROCESS_OPEN
}

指定事件時間戳記

使用 Metadata.event_timestamp 提交 UDM 格式的任何事件時，都必須指定格林威治標準時間 (GMT) 時間戳記。戳記必須使用下列其中一種標準編碼：

• 如果是 JSON，請使用 RFC 3339
• Proto3 時間戳記

以下範例說明如何使用 RFC 3339 格式指定時間戳記。以這個範例來說，yyyy-mm-ddThh:mm:ss+hh:mm 代表年、月、日、時、分、秒，以及與世界標準時間的時差。與世界標準時間的時差為 -8 小時，表示太平洋標準時間。

metadata {
  event_timestamp: "2019-09-10T20:32:31-08:00"
}

指定名詞 (實體)

為每個 UDM 事件定義一或多個名詞。名詞代表參與者或實體，例如執行活動的使用者、動作目標，或是觀察事件的安全裝置 (例如電子郵件 Proxy 或路由器)。名詞也代表網址或附件等物件。

注意： 對於 UDM 事件，主機名稱欄位有 256 個字元的限制 (例如 principal.hostname 或 target.hostname)。如果對應的原始記錄 (來自 ArcSight 等來源) 超過此限制，就會導致驗證失敗並捨棄記錄。這並非專屬於個別剖析器。

UDM 事件必須指定下列一或多個名詞：

主體：代表執行實體或發起事件所描述活動的裝置。主體必須至少包含一項機器詳細資料 (主機名稱、MAC、IP、連接埠、產品專屬 ID，例如 CrowdStrike 機器 GUID) 或使用者詳細資料 (例如使用者名稱)，並視需要包含程序詳細資料。不得包含下列任何欄位：電子郵件、檔案、登錄機碼或值。

如果所有活動都發生在單一機器上，請只在 principal 區塊中描述該機器。請勿在 target 或 src 中重複提供機器詳細資料。

注意： 請勿在 principal 欄位中描述安全裝置，即使這些裝置是事件的來源也一樣。請改用 observer 或 intermediary 欄位。如果安全防護軟體在發起活動的同一部裝置上執行 (例如 Windows 端點上的 EDR 代理程式)，該裝置仍是主體。

以下範例說明如何填入 principal 欄位：

principal {
  hostname: "jane_win10"
  asset_id: "Sophos.AV:C070123456-ABCDE"
      ip: "10.0.2.10"
      port: 60671
      user {  userid: "john.smith" }
}

這個範例提供裝置和使用者詳細資料，使用者是事件中的主要參與者。其中也包含供應商專屬資產 ID (來自 Sophos)，這是由第三方安全產品產生的專屬 ID。

目標：代表事件參照的裝置或物件。在從裝置 A 到裝置 B 的防火牆連線中，A 是主體，B 是目標。如果程序 C 插入程序 D，則 C 是主體，D 是目標。

UDM 中的主體與目標

以下範例說明如何填入目標的欄位：

target {
   ip: "198.51.100.31"
   port: 80
}

在 target 區塊中加入任何其他可用資訊，例如主機名稱、其他 IP 或 MAC 位址，以及專屬資產 ID。

主體和目標 (以及其他名詞) 都可以參照同一部電腦上的參與者。舉例來說，如果機器 X 上執行的程序 A (主體) 對機器 X 上的程序 B (目標) 採取行動，您可以在各自的區塊中描述這兩個程序。

• src：代表要執行的來源物件及其環境，例如所在的機器。舉例來說，如果使用者 U 將機器 X 上的檔案 A 複製到機器 Y 上的檔案 B，請在 src 區塊中指定檔案 A 和機器 X。

• 中介：包含一或多個處理事件所描述活動的裝置詳細資料。包括裝置資訊，例如 Proxy 伺服器和 SMTP 轉發服務。

• 觀察者：代表並非直接中介的裝置，但會監控及回報活動。包括封包監聽器或網路安全漏洞掃描程式等裝置。

• about：儲存事件參照的任何物件詳細資料，這些物件不符合 participant、src、target、intermediary 或 observer。您可以使用這項功能追蹤下列項目：

  • 電子郵件檔案附件
  • 電子郵件內文內嵌的網域/網址/IP
  • 在 PROCESS_LAUNCH 事件期間載入的 DLL

UDM 事件的實體區段包含事件中描述的各種參與者 (裝置、使用者、物件，例如網址、檔案等) 相關資訊。填寫名詞欄位時，Google Security Operations UDM 有強制性規定。如要瞭解這些規定，請參閱「各 UDM 事件類型的必要和選用欄位」。必須填入的實體欄位組合會因事件類型而異。

指定安全性結果

您可以選擇填入 SecurityResult 欄位，指定安全性結果，包括安全性系統發現的安全性風險和威脅詳細資料，以及為減輕這些風險和威脅而採取的行動。以下列舉幾種需要填入 SecurityResult 欄位的安全事件類型：

• 電子郵件安全代理防火牆偵測到兩個受感染的附件 (SOFTWARE_MALICIOUS)。系統已隔離並清除這些郵件 (QUARANTINE、ALLOW_WITH_MODIFICATION)，然後轉寄清除後的電子郵件。

• SSO 系統促成登入嘗試，但導致 AUTH_VIOLATION 並遭到封鎖 (BLOCK)。

• 系統將電子郵件傳送到使用者收件匣五分鐘後，惡意軟體沙箱在檔案附件中偵測到間諜軟體 (SOFTWARE_MALICIOUS)。(ALLOW)

UDM 搜尋範例

本節提供 UDM 搜尋範例，說明 UDM 搜尋的基本語法、功能和用途。

範例：搜尋成功的 Microsoft Windows 4624 登入

下列搜尋會根據兩個 UDM 欄位，列出 Microsoft Windows 4624 成功登入事件，以及事件的產生時間：

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624"

範例：搜尋所有登入成功的記錄

以下搜尋會列出所有登入成功的事件，不論供應商或應用程式為何：

metadata.event_type = "USER_LOGIN" AND security_result.action = "ALLOW" AND target.user.userid != "SYSTEM" AND target.user.userid != /.*$/

範例：搜尋使用者登入成功的記錄

以下範例說明如何搜尋 userid "fkolzig"，並判斷具有這個使用者 ID 的使用者何時成功登入。您可以使用目標部分完成這項搜尋。目標部分包含描述目標的子章節和欄位。舉例來說，這個案例中的目標是使用者，且具有多個相關聯的屬性，但目標也可能是檔案、登錄設定或資產。這個範例會使用 target.user.userid 欄位搜尋 "fkolzig"。

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624" AND target.user.userid = "fkolzig"

範例：搜尋網路資料

以下範例會搜尋 RDP 事件的網路資料，其中 target.port 為 3389，principal.ip 為 35.235.240.5。此外，還包括網路部分的 UDM 欄位，以及資料方向 (network.direction)。

metadata.product_event_type = "3" AND target.port = 3389 AND network.direction = "OUTBOUND" and principal.ip = "35.235.240.5"

範例：搜尋特定程序

如要檢查伺服器上建立的程序，請搜尋 net.exe 指令的執行個體，並在預期路徑中搜尋這個特定檔案。您要搜尋的欄位是 target.process.file.full_path。如要進行這項搜尋，請在 target.process.command_line 欄位中加入發出的特定指令。您也可以在「關於」部分新增欄位，也就是 Microsoft Sysmon 事件代碼 1 (ProcessCreate) 的說明。

以下是 UDM 搜尋：

metadata.product_event_type = "1" AND target.process.file.full_path = "C:\Windows\System32\net.exe"

您也可以視需要新增下列 UDM 搜尋欄位：

• principal.user.userid：識別發出指令的使用者。
• principal.process.file.md5：找出 MD5 雜湊。
• principal.process.command_line：指令列。

範例：搜尋與特定部門相關聯的使用者登入成功記錄

以下範例會搜尋與企業行銷部門 (target.user.department is marketing) 相關聯的使用者 (metadata.event_type is USER_LOGIN) 登入記錄。雖然 target.user.department 與使用者登入事件沒有直接關聯，但仍會出現在系統擷取的使用者 LDAP 資料中。

metadata.event_type = "USER_LOGIN" AND target.user.department = "Marketing"

邏輯物件：事件和實體

UDM 結構定義會說明儲存資料的所有可用屬性。每筆 UDM 記錄都會指出是否描述事件或實體。資料會儲存在不同欄位，視記錄是描述事件還是實體而定，以及 metadata.event_type 或 metadata.entity_type 欄位中設定的值。

• UDM 事件：儲存環境中發生的動作資料。原始事件記錄會說明裝置 (例如防火牆和網頁 Proxy) 記錄的動作。
• UDM 實體：環境中資產、使用者和資源等元素的脈絡表示法。這項資訊來自單一事實來源資料來源。

以下是事件資料模型和實體資料模型的兩個高層級視覺化表示法。

注意： 名詞是指屬性類型。主體、目標、來源、中介、觀察者和關於是儲存資料的欄位名稱。

圖：事件資料模型

注意： 名詞是指屬性類型。「資產」、「使用者」和「資源」是儲存資料的欄位名稱。

圖：實體資料模型

UDM 事件的結構

UDM 事件包含多個區段，每個區段都會儲存單一記錄的資料子集。這些區段包括：

• 中繼資料
• 主體
• 目標
• src
• 觀察者
• 中介
• 關於
• 網路
• security_result

• 額外資訊

  

  圖：事件資料模型

中繼資料部分會儲存時間戳記、定義 event_type，並說明裝置。

principal、target、src、observer 和 intermediary 區段會儲存事件中物件的相關資訊。物件可以是裝置、使用者或程序。在多數情況下，只會使用這些區段的部分內容。儲存資料的欄位取決於事件類型，以及每個物件在事件中扮演的角色。

「網路」部分會儲存與網路活動相關的資訊，例如電子郵件和網路相關通訊。

• 電子郵件資料：to、from、cc、bcc 和其他電子郵件欄位中的資訊。
• HTTP 資料：例如 method、referral_url 和 useragent。

security_result 區段會儲存安全防護產品 (例如防毒產品) 記錄的動作或分類。

「關於」和「擴充功能」部分會儲存其他部分未擷取的供應商專屬事件資訊。extensions 區段是一組任意形式的鍵/值組合。

每個 UDM 事件都會儲存一個原始原始記錄事件的值。視事件類型而定，部分屬性為必填，其餘的則是選填屬性。必要屬性和選用屬性取決於 metadata.event_type 值。Google SecOps 會讀取 metadata.event_type，並在收到記錄後，執行該事件類型專屬的欄位驗證。

如果 UDM 記錄的某個部分 (例如擴充功能部分) 未儲存任何資料，該部分就不會顯示在 UDM 記錄中。

中繼資料欄位

本節說明 UDM 事件中必須填寫的欄位。

event_timestamp 欄位

UDM 事件必須包含 metadata.event_timestamp 的資料，這是事件發生時的 GMT 時間戳記。這個值必須使用下列其中一個標準編碼：RFC 3339 或 Proto3 時間戳記。

下列範例說明如何使用 RFC 3339 格式指定時間戳記，yyyy-mm-ddThh:mm:ss+hh:mm (年、月、日、時、分、秒，以及與世界標準時間的時差)。與世界標準時間的時差為 -8 小時，表示為太平洋標準時間。

metadata {
  "event_timestamp": "2019-09-10T20:32:31-08:00"
}

metadata {
  event_timestamp: "2021-02-23T04:00:00.000Z"
}

您也可以使用 Epoch 格式指定值。

metadata {
event_timestamp: {
  "seconds": 1588180305
 }
}

event_type 欄位

UDM 事件中最重要的欄位是 metadata.event_type。 這個值會識別執行的動作類型，與供應商、產品或平台無關。例如 PROCESS_OPEN、FILE_CREATION、USER_CREATION 和 NETWORK_DNS。如需完整清單，請參閱 UDM 欄位清單文件。

metadata.event_type 值會決定 UDM 記錄中必須包含哪些額外必填和選填欄位。如要瞭解每種事件類型應加入哪些欄位，請參閱 UDM 使用指南。

主體、目標、來源、中介、觀察者和相關屬性

principal、target、src、intermediary 和 observer 屬性會說明事件中涉及的資產。原始原始記錄所記錄的活動中涉及的物件，其各自的商店資訊。這可能是執行活動的裝置或使用者，也可能是活動的目標裝置或使用者。也可能描述觀察到該活動的安全裝置，例如電子郵件 Proxy 或網路路由器。

最常用的屬性如下：

• principal：執行活動的物件。
• src：啟動活動的物件 (如果與主體不同)。
• target：受影響的物件。

每種事件類型都必須至少有一個欄位包含資料。

輔助欄位如下：

• intermediary：在事件中擔任中介角色的任何物件。這可能包括 Proxy 伺服器和郵件伺服器等物件。
• observer：任何不會直接與有問題流量互動的物件。這可能是安全漏洞掃描器或封包監聽裝置。
• about：在事件中扮演任何其他角色的物件，為選用項目。

主要屬性

代表執行活動的實體或發起活動的裝置。主體必須至少包含一項機器詳細資料 (主機名稱、MAC 位址、IP 位址、產品專屬 ID (例如 CrowdStrike 機器 GUID)) 或使用者詳細資料 (例如使用者名稱)，並視需要包含程序詳細資料。不得包含下列任何欄位：電子郵件、檔案、登錄機碼或值。

如果事件發生在單一電腦上，則該電腦只會在主體屬性中說明。機器不需要在 target 或 src 屬性中說明。

注意： 安全裝置可能會記錄事件，但不會在主體屬性中說明。這項屬性會顯示在觀察者或中介屬性中。如果安全性軟體 (例如 Carbon Black) 在活動來源裝置上執行 (例如偵測到惡意軟體的 Windows 端點)，則 Windows 裝置就是主體。

下列 JSON 程式碼片段說明如何填入 principal 屬性。

"principal": {
  "hostname": "jane_win10",
  "asset_id" : "Sophos.AV:C070123456-ABCDE",
    "ip" : "10.10.2.10",
    "port" : 60671,
    "user": {  "userid" : "john.smith" }
}

這項屬性會說明事件中主要行為者 (裝置和使用者) 的所有已知資訊。這個範例包含裝置的 IP 位址、通訊埠號碼和主機名稱。其中也包括 Sophos 的廠商專屬資產 ID，這是由第三方安全產品產生的專屬 ID。

目標屬性

代表事件參照的目標裝置，或目標裝置上的物件。舉例來說，在從裝置 A 到裝置 B 的防火牆連線中，裝置 A 會擷取為主體，裝置 B 則會擷取為目標。

如果程序 C 將程序注入目標程序 D，則程序 C 是主體，程序 D 是目標。

圖：本金與目標金額比較

以下範例說明如何填入目標欄位。

target {
   ip: "192.0.2.31"
   port: 80
}

如果原始原始記錄中提供更多資訊，例如主機名稱、其他 IP 位址、MAC 位址和專有資產 ID，也應納入目標和主體欄位。

主體和目標都可以在同一部電腦上代表行為者。舉例來說，在機器 X 上執行的程序 A (主體) 可以對機器 X 上的程序 B (目標) 採取行動。

src 屬性

代表參與者正在處理的來源物件，以及來源物件的裝置或程序環境 (來源物件所在的機器)。舉例來說，如果使用者 U 將機器 X 上的檔案 A 複製到機器 Y 上的檔案 B，則 UDM 事件的 src 部分會指定檔案 A 和機器 X。

中介屬性

代表處理活動的一或多個中繼裝置的詳細資料，活動中會說明這些裝置。這可能包括裝置詳細資料，例如 Proxy 伺服器和 SMTP 中繼伺服器。

觀察者屬性

代表觀察裝置，這類裝置並非直接中介裝置，但會觀察並回報相關事件。這可能包括封包監聽器或網路型漏洞掃描器。

關於屬性

這個欄位會儲存事件參照的物件詳細資料，這些物件並未在主體、src、目標、中介或觀察者欄位中說明。舉例來說，這項功能可以擷取下列資訊：

• 電子郵件附件。
• 電子郵件內文中嵌入的網域、網址或 IP 位址。
• 在 PROCESS_LAUNCH 事件期間載入的 DLL。

security_result 屬性

本節包含安全系統發現的安全風險和威脅，以及為減輕這些風險和威脅而採取的行動。

以下是會儲存在 security_result 屬性中的資訊類型：

• 電子郵件安全防護代理伺服器偵測到網路釣魚攻擊 (security_result.category = MAIL_PHISHING)，並封鎖該電子郵件 (security_result.action = BLOCK)。
• 電子郵件安全防護代理伺服器防火牆偵測到兩個受感染的附件 (security_result.category = SOFTWARE_MALICIOUS)，並隔離和清除這些附件 (security_result.action = QUARANTINE or security_result.action = ALLOW_WITH_MODIFICATION)，然後轉寄已清除感染的電子郵件。
• 單一登入系統允許登入 (security_result.category = AUTH_VIOLATION)， 但登入遭封鎖 (security_result.action = BLOCK)。
• 惡意軟體沙箱在檔案附件傳送至使用者收件匣五分鐘後 (security_result.action = ALLOW)，偵測到該附件含有間諜軟體 (security_result.category = SOFTWARE_MALICIOUS)。

網路屬性

網路屬性會儲存網路相關事件的資料，以及子訊息中通訊協定的詳細資料。包括傳送和接收電子郵件，以及 HTTP 要求等活動。

擴充功能屬性

這個屬性下的欄位會儲存原始原始記錄中擷取的事件其他中繼資料。可能包含有關安全漏洞的資訊，或與驗證相關的其他資訊。

UDM 實體的結構

UDM 實體記錄會儲存機構內任何實體的相關資訊。 如果 metadata.entity_type 為 USER，記錄會儲存 entity.user 屬性下的使用者相關資訊。如果 metadata.entity_type 是 ASSET，記錄會儲存資產的相關資訊，例如工作站、筆電、手機和虛擬機器。

圖：事件資料模型

中繼資料欄位

這個部分包含 UDM 實體中必要的欄位，例如：

• collection_timestamp：收集記錄的日期和時間。
• entity_type：實體類型，例如資產、使用者和資源。

實體屬性

實體屬性下的欄位會儲存特定實體的相關資訊，例如資產的主機名稱和 IP 位址，或是使用者的 windows_sid 和電子郵件地址。請注意，欄位名稱為 entity，但欄位類型為名詞。名詞是常用的資料結構，可同時儲存實體和事件中的資訊。

• 如果 metadata.entity_type 是 USER，資料會儲存在 entity.user 屬性下。
• 如果 metadata.entity_type 是 ASSET，資料會儲存在 entity.asset 屬性下。

關係屬性

關係屬性下的欄位會儲存與主要實體相關的其他實體資訊。舉例來說，如果主要實體是使用者，且該使用者已獲發筆電，筆電是相關實體。 筆電的相關資訊會儲存為 entity 記錄，且 metadata.entity_type = ASSET。系統會將使用者資訊儲存為 metadata.entity_type = USER 的entity記錄。

使用者實體記錄也會使用 relation 屬性下的欄位，擷取使用者與筆電之間的關係。relation.relationship 欄位會儲存使用者與筆電的關係，具體來說，就是使用者擁有筆電。relation.entity_type 欄位會儲存 ASSET 值，因為筆電是裝置。

relations.entity 屬性下的欄位會儲存筆電的相關資訊，例如主機名稱和 MAC 位址。請再次注意，欄位名稱為 entity，欄位類型為名詞。名詞是常用的資料結構。「relation.entity」屬性下的欄位會儲存筆電的相關資訊。

relation.direction 欄位會儲存使用者與筆電之間的關係方向，具體來說，就是關係是雙向還是單向。

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