擴充
強化功能會使用下列方法，為統合式資料模型 (UDM) 指標或事件新增背景資訊：
- 識別描述指標的別名實體，通常是 UDM 欄位。
- 根據已識別的別名或實體，在 UDM 訊息中填入其他詳細資料。
- 將 GeoIP 和 VirusTotal 等全域擴充資料新增至 UDM 事件。
瞭解擴充邏輯模式
Google SecOps 會根據擴充類型，對資料套用不同的邏輯模式。請參閱下表瞭解這些模式，以便排解問題，並說明特定欄位為何會填入、合併或覆寫資料。
| 邏輯模式 | 說明 | 適用的擴充功能 |
|---|---|---|
| 初賽 | 嚴格遵循優先順序清單。管道只會查詢序列中找到的第一個可用值。 | 構件 (檔案雜湊) |
| 已合併 | 同時收集及合併多個欄位的資料，建立單一「黃金」實體記錄。 | 資產、使用者 |
| 條件式備用廣告 | 只有在缺少優先順序較高的 ID 時，才會使用特定欄位進行擴充。 | 資產 (ip 地址) |
| 對應及覆寫 | 使用專屬 ID (PSPI) 解析實體。來自擴充來源的別名資料會取代現有的剖析資料。 |
程序 |
素材資源強化
為豐富資產內容，管道會評估多個 UDM 欄位，找出專屬資產。與構件擴充 (只會挑選一個) 不同，資產擴充功能會合併多個 ID 的內容，建立完整的資產設定檔。
資產的邏輯是累加而非互斥，特定備援情境除外。請使用下列詳細資料進行說明：
- 邏輯類型：合併或備援。除非符合備援條件 (例如
asset_id檢查)，否則管道會從所有可用欄位收集資料，建立單一「實體」檢視畫面。 - 欄位對應：
- 主機名稱、MAC 和
asset_id：視為主要 ID。所有這些欄位的別名結果會合併，產生最終的強化資產設定檔。 - IP 位址：只有在
asset_id無法使用時，才會納入擴充查詢。
- 主機名稱、MAC 和
對於每個資產事件，管道會從 principal、src 和 target 實體中擷取下列 UDM 欄位：
| UDM 欄位 | 指標類型 | 邏輯 / 優先順序 |
|---|---|---|
hostname |
主機名稱 | 已合併：系統會合併這些欄位的別名結果，產生最終的強化資產記錄。 |
asset_id |
PRODUCT_SPECIFIC_ID | 已合併：用於整合資產內容的主要 ID。 |
mac |
MAC | 已合併：與其他 ID 一起使用，以解析資產。 |
ip |
IP | 備援：僅在 asset_id 無法使用時，才會納入擴充查詢。 |
使用者資訊擴充
使用者擴充功能會尋找特定 ID，藉此解析身分資料。與構件擴充類似，這個管道會使用偏好的順序，判斷要將哪個 ID 做為查閱的主鍵。
針對每個使用者事件，管道會從 principal、src 和 target 中擷取下列 UDM 欄位：
| UDM 欄位 | 指標類型 | 邏輯或優先順序 |
|---|---|---|
user.email_addresses |
電子郵件 | 最高優先順序：管道會先嘗試根據使用者的主要或次要電子郵件地址進行擴充。 |
user.windows_sid |
WINDOWS_SID | 第二優先：如果沒有電子郵件地址，管道會使用 Windows 安全性識別碼 (SID)。 |
user.userid |
USER_ID | 第三優先順序：僅在缺少電子郵件和 SID 時使用，通常會對應至本機或應用程式專屬 ID。 |
user.employee_id |
EMPLOYEE_ID | 最低優先順序：解決使用者身分的最終備援方式。 |
管道會針對每個指標執行下列動作：
- 擷取使用者實體清單。舉例來說，
principal.email_address和principal.userid的實體可能相同，也可能不同。 - 系統會按照優先順序，從最高優先順序的指標類型中選擇別名，優先順序如下：
WINDOWS_SID、EMAIL、USERNAME、EMPLOYEE_ID和PRODUCT_OBJECT_ID。 - 系統會填入
noun.user，其中包含有效間隔與事件時間相交的實體。
程序擴增
程序擴充功能著重於提供執行事件的顯示狀態。 管道會擷取程序詳細資料，並交叉參照檔案信譽和父項與子項的關係，藉此擴充資料。
使用程序擴充功能，將產品專屬程序 ID (product_specific_process_id) 或 PSPI 對應至實際程序，並擷取父項程序的詳細資料。這項程序會使用 EDR 事件批次類型。
| UDM 實體 | 欄位來源 | 邏輯或優先順序 |
|---|---|---|
| 主要實體 |
principal、src、target |
擷取：管道會從這些頂層實體擷取 PSPI，以啟動查詢。 |
| 父項程序 |
principal.process.parent_process, src.process.parent_process, target.process.parent_process
|
對應：PSPI 會透過程序別名擷取父項程序的詳細資料。 |
| 資料合併 |
noun.process (例如 principal.process)
|
覆寫規則：別名欄位的優先順序最高。如果同一欄位同時存在已剖析資料和別名資料，管道會以別名資料取代已剖析資料。 |
管道會使用程序別名從 PSPI 識別實際程序，並擷取父項程序的相關資訊。然後將這項資料合併至經過擴充的訊息中，對應的 noun.process 欄位。
程序別名的 EDR 索引欄位
程序啟動時，系統會收集中繼資料 (例如指令列、檔案雜湊和父項程序詳細資料)。電腦上執行的 EDR 軟體會指派廠商專屬的程序 UUID。
下表列出程序啟動事件期間建立索引的欄位：
| UDM 欄位 | 指標類型 |
|---|---|
| target.product_specific_process_id | PROCESS_ID |
| target.process | 整個程序，而不只是指標 |
除了正規化事件中的 target.process 欄位，Google SecOps 還會收集並建立父項程序資訊的索引。
構件強化
構件擴充功能會新增來自 VirusTotal 的檔案雜湊中繼資料，以及 IP 位址的地理位置資料。如果是檔案雜湊值，管道會在優先順序清單中找到第一個值時停止；但如果是 IP 位址，則會平行處理所有項目。針對每個 UDM 事件，管道會從 principal、src 和 target 實體中擷取並查詢下列構件指標的內容資料，其中擴充行為會因指標類型而異：
| 指標類型 | 擷取邏輯 | 優先順序 / 運算順序 |
|---|---|---|
| 檔案雜湊 | 初賽 |
管道會依下列順序搜尋雜湊，並只挑選第一個可查詢 VirusTotal 的雜湊：
|
| IP 位址 | 平行 (重複) | 每個公開或可轉送的 IP 位址都會視為獨立項目。系統不會依偏好順序處理 IP 位址，每個 IP 位址都會收到各自的擴充結果。 |
管道會使用 UNIX 紀元和事件時數，定義檔案構件查詢的時間範圍。如有地理位置資料，管道會根據地理位置資料的來源，覆寫 principal、src 和 target 實體的下列 UDM 欄位：
artifact.ipartifact.locationartifact.network(僅限資料包含 IP 網路環境時)location(僅限原始資料未包含這個欄位的情況)
如果管道找到檔案雜湊中繼資料，會視指標來源將該中繼資料新增至檔案或 process.file 欄位。如果現有值與新資料不重疊，管道會保留這些值。
IP 地理位置資訊擴充
地理別名功能會提供外部 IP 位址的地理位置資料。針對 UDM 事件 principal、target 或 src 欄位中的每個未別名化的 IP 位址，系統會建立 ip_geo_artifact 子通訊協定緩衝區，其中包含相關聯的位置和 ASN 資訊。
地理別名不會使用回溯或快取功能。由於事件數量龐大，Google SecOps 會在記憶體中維護索引。
使用 VirusTotal 檔案中繼資料充實事件內容
Google SecOps 會將檔案雜湊值擴充為 UDM 事件，並在調查期間提供額外背景資訊。雜湊別名會結合所有類型的檔案雜湊，並在搜尋期間提供檔案雜湊的相關資訊，藉此擴充 UDM 事件。
Google SecOps 整合 VirusTotal 檔案中繼資料和關係擴充功能，可識別惡意活動模式，並追蹤網路中的惡意軟體活動。
原始記錄檔提供的檔案資訊有限。VirusTotal 會提供檔案中繼資料，包括惡意雜湊和檔案的詳細資料，藉此擴充事件資訊。中繼資料包含檔案名稱、類型、匯入的函式和標記等資訊。您可以在 UDM 搜尋和偵測引擎中使用 YARA-L，瞭解惡意檔案事件，以及在威脅搜尋期間使用這項資訊。舉例來說，您可以偵測原始檔案的修改內容，並使用檔案中繼資料偵測威脅。
系統會將下列資訊與記錄一併儲存。 如需所有 UDM 欄位的清單，請參閱「整合式資料模型欄位清單」。
| 資料類型 | UDM 欄位 |
|---|---|
| sha-256 | ( principal | target | src | observer ).file.sha256 |
| md5 | ( principal | target | src | observer ).file.md5 |
| sha-1 | ( principal | target | src | observer ).file.sha1 |
| 大小 | ( principal | target | src | observer ).file.size |
| ssdeep | ( principal | target | src | observer ).file.ssdeep |
| vhash | ( principal | target | src | observer ).file.vhash |
| authentihash | ( principal | target | src | observer ).file.authentihash |
| PE 檔案中繼資料 Imphash | ( principal | target | src | observer ).file.pe_file.imphash |
| security_result.threat_verdict | ( principal | target | src | observer ).(process | file).security_result.threat_verdict |
| security_result.severity | ( principal | target | src | observer ).(process | file).security_result.severity |
| last_modification_time | ( principal | target | src | observer ).file.last_modification_time |
| first_seen_time | ( principal | target | src | observer ).file.first_seen_time |
| last_seen_time | ( principal | target | src | observer ).file.last_seen_time |
| last_analysis_time | ( principal | target | src | observer ).file.last_analysis_time |
| exif_info.original_file | ( principal | target | src | observer ).file.exif_info.original_file |
| exif_info.product | ( principal | target | src | observer ).file.exif_info.product |
| exif_info.company | ( principal | target | src | observer ).file.exif_info.company |
| exif_info.file_description | ( principal | target | src | observer ).file.exif_info.file_description |
| signature_info.codesign.id | ( principal | target | src | observer ).file.signature_info.codesign.id |
| signature_info.sigcheck.verfied | ( principal | target | src | observer ).file.signature_info.sigcheck.verified |
| signature_info.sigcheck.verification_message | ( principal | target | src | observer ).file.signature_info.sigcheck.verification_message |
| signature_info.sigcheck.signers.name | ( principal | target | src | observer ).file.signature_info.sigcheck.signers.name |
| signature_info.sigcheck.status | ( principal | target | src | observer ).file.signature_info.sigcheck.signers.status |
| signature_info.sigcheck.valid_usage | ( principal | target | src | observer ).file.signature_info.sigcheck.signers.valid_usage |
| signature_info.sigcheck.cert_issuer | ( principal | target | src | observer ).file.signature_info.sigcheck.signers.cert_issuer |
| file_type | ( principal | target | src | observer ).file.file_type |
排解強化功能問題
如果您發現 UDM 事件缺少預期的擴充資料，請參考下列建議解決問題。
一般擴充功能
如果部分事件完全沒有經過擴充，可能是因為 Google SecOps 優先考量傳送速度。在第一次傳送時，可能會有少數事件 (不到 1%) 略過擴充程序。如要解決這個問題，請稍候幾分鐘再返回查看。系統會自動重新處理這些事件。如果一小時後仍未顯示擴充資訊，請確認記錄來源是否已正確剖析為 UDM。
構件擴充 (首次比對邏輯)
如果您的事件有 MD5 和 SHA256 雜湊，但您只能看到 SHA256 的 VirusTotal 中繼資料，這是先比對邏輯。管道找到優先順序最高的雜湊 (sha256) 後就會停止，如果存在 SHA256，就不會查詢 VirusTotal 的 MD5。
如果系統顯示 principal.ip 的地理位置，但未顯示 target.ip 的地理位置，平行邏輯會將每個 IP 視為獨立項目。如果其中一個 IP 是內部或私人 IP (無法路由傳送)，另一個是公開 IP，則只有公開 IP 會收到地理位置資訊。
素材資源強化 (合併和備用邏輯)
如果 IP 位址欄位未顯示資產的擴充資料，表示這是條件式備援邏輯。只有在缺少 asset_id (PSID) 時，系統才會將 IP 用於查詢擴充資訊。如果存在 asset_id，系統會依據該值，並忽略特定查詢的 IP，避免出現多餘或衝突的資料。
使用者擴充功能 (偏好順序)
如果Department欄位顯示 "IT"，但本機記錄顯示 "Security"，表示使用者擴充功能偏好剖析的欄位，而非別名欄位。如果原始記錄是使用 "IT" 剖析，強化管道就不會以身分來源 (例如 Okta 或 AD) 的 "Security" 值覆寫。
流程擴充 (對應和覆寫)
如果您在原始記錄中看到程序名稱，但在 UDM 搜尋中，該名稱已替換為其他名稱，表示這是覆寫邏輯。程序擴充功能會優先處理別名欄位。如果 PSPI 查詢從 EDR 環境傳回更準確的程序名稱，就會完全取代原始剖析值。
後續步驟
如要瞭解如何搭配使用強化資料和其他 Google SecOps 功能，請參閱下列文章：
還有其他問題嗎？向社群成員和 Google SecOps 專業人員尋求答案。