統一資料模型總覽

支援的國家/地區：

本文概要說明統合式資料模型 (UDM)。如要進一步瞭解 UDM 欄位 (包括各欄位的說明)，請參閱 UDM 欄位清單。如要進一步瞭解剖析器對應，請參閱「剖析器對應的重要 UDM 欄位」。

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

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

UDM 的優點包括：

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

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

UDM 結構

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

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

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

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"

範例：搜尋網路資料

以下範例會搜尋網路資料，找出具有 target.port 的 RDP 事件，且 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 為 marketing) 相關聯的使用者 (metadata.event_type 為 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

  • 擴充功能

    事件資料模型

    圖：事件資料模型

「metadata」(中繼資料) 區段會儲存時間戳記、定義 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 的資料，這是指事件發生時的格林威治標準時間時間戳記。值必須使用下列其中一個標準編碼：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 使用指南。

主體、目標、src、中介、觀察者和 about 屬性

principal、target、src、intermediary 和 observer 屬性會說明與活動相關的資產。每個物件都會儲存活動的相關資訊，這些資訊是原始原始記錄所記錄的內容。這可能是執行活動的裝置或使用者，也可能是活動的目標裝置或使用者。也可能說明觀察到該活動的安全裝置，例如電子郵件 Proxy 或網路路由器。

最常使用的屬性包括：

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

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

輔助欄位包括：

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

主要屬性

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

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

下列 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)。
  • 電子郵件安全 Proxy 防火牆偵測到兩個受感染的附件 (security_result.category = SOFTWARE_MALICIOUS)，並隔離和清除 (security_result.action = QUARANTINE or security_result.action = ALLOW_WITH_MODIFICATION) 這些附件，然後轉寄已清除的電子郵件。
  • SSO 系統允許登入 (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 專業人員尋求答案。