統一資料模型總覽
本文概要說明統合式資料模型 (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 專業人員尋求答案。