UDM 概览

支持范围：

Google SecOps SIEM

本文档简要介绍了统一数据模型 (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：事件经过的系统，例如代理服务器或 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）。对于每种事件类型，您还需要使用与原始事件相关的信息填充一组其他字段和值。 如需详细了解每种事件类型应包含哪些字段，请参阅每种事件类型的必填字段和可选字段。

以下示例说明了如何使用 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 - 年、月、日、小时、分钟、秒与世界协调时间 (UTC) 的时差。相对于 UTC 的偏移量为 8 小时，表示太平洋标准时间。

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

指定名词（实体）

为每个 UDM 事件定义一个或多个名词。名词表示参与者或实体，例如执行活动的用户、操作的目标或观察事件的安全设备（例如电子邮件代理或路由器）。名词也表示网址或附件等对象。

注意： 对于 UDM 事件，主机名字段有 256 个字符数限制（例如 principal.hostname 或 target.hostname）。映射超出此限制的原始日志（来自 ArcSight 等来源）会导致验证失败和日志被丢弃。这并非特定于个别解析器。

UDM 事件必须指定以下一个或多个名词：

principal：表示发起事件中所述活动的操作实体或设备。主账号必须至少包含一个机器详细信息（主机名、MAC、IP、端口、产品专用标识符，例如 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" }
}

此示例提供了有关设备和事件中主要操作者的详细信息。它还包含供应商专属资产标识符（来自 Sophos），这是由第三方安全产品生成的唯一 ID。

target：表示事件引用的设备或对象。在从设备 A 到设备 B 的防火墙连接中，A 是主账号，B 是目标。对于进程 C 注入进程 D 的进程注入，C 是主体，D 是目标。

UDM 中的主账号与目标

以下示例展示了如何填充目标的字段：

target {
   ip: "198.51.100.31"
   port: 80
}

在 target 块中添加任何其他可用信息，例如主机名、其他 IP 或 MAC 地址以及专有资产标识符。

principal 和 target（以及其他名词）都可以引用同一台机器上的操作者。例如，如果机器 X 上运行的进程 A (principal) 作用于同样在机器 X 上运行的进程 B (target)，则您需要在各自的块中描述这两个进程。

• src：表示正在执行操作的来源对象及其上下文，例如其所在的机器。例如，如果用户 U 将机器 A 上的文件 A 复制到机器 Y 上的文件 B，则在 src 块中指定文件 A 和机器 X。

• intermediary：包含处理过事件中所述活动的一个或多个设备的详细信息。这包括代理服务器和 SMTP 中继等设备的信息。

• observer：表示并非直接中介，但会监控和报告活动的设备。这包括数据包嗅探器或基于网络的漏洞扫描器等设备。

• 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)。

• 在系统将电子邮件递送 (ALLOW) 到用户收件箱 5 分钟后，恶意软件沙盒在文件附件中检测到间谍软件 (SOFTWARE_MALICIOUS)。

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 为 3389 且 principal.ip 为 35.235.240.5 的 RDP 事件。它还包含网络部分中的 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 事件：存储环境中发生的操作的数据。原始事件日志描述了设备（例如防火墙和 Web 代理）记录的操作。
• UDM 实体：环境中资产、用户和资源等元素的上下文表示。它是从可信来源数据源获取的。

以下是事件数据模型和实体数据模型的两个简要直观表示。

注意 ：术语“名词”描述的是属性的类型。术语 principal、target、src、intermediary、observer 和 about 是存储数据的字段名称。

图：事件数据模型

注意 ：术语“名词”描述的是属性的类型。术语“资产”“用户”和“资源”是存储数据的字段名称。

图：实体数据模型

UDM 事件的结构

UDM 事件包含多个部分，每个部分存储单个记录的数据子集。这些部分包括：

• 元数据
• 主体
• 目标
• src
• 观测者
• 中介
• 关于
• 网络
• security_result

• 扩展程序

  

  图：事件数据模型

metadata 部分存储时间戳、定义 event_type 并描述设备。

principal、target、src、observer 和 intermediary 区段存储有关事件中涉及的对象的信息。对象可以是设备、用户或进程。在大多数情况下，只会使用这些部分中的一部分。存储数据的字段由事件类型以及每个对象在事件中扮演的角色决定。

network 部分存储与网络活动相关的信息，例如电子邮件和网络相关通信。

• 电子邮件数据：to、from、cc、bcc 和其他电子邮件字段中的信息。
• HTTP 数据：例如 method、referral_url 和 useragent。

security_result 部分存储安全产品（例如防病毒产品）记录的操作或分类。

about 和 extensions 部分会存储其他部分未捕获的其他供应商特定事件信息。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（年、月、日、小时、分钟、秒以及与世界协调时间 [UTC] 的偏移量）指定时间戳。与世界协调时间 (UTC) 的偏移量为负 8 小时，表示 PST。

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

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

您也可以使用纪元格式指定该值。

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 和 about 属性

principal、target、src、intermediary 和 observer 属性描述了事件中涉及的资产。每个存储空间都包含原始原始日志记录的活动中涉及的对象的相关信息。这可能是执行活动或作为活动目标的设备或用户。它还可能描述观察到活动的安全性设备，例如电子邮件代理或网络路由器。

最常用的属性包括：

• principal：执行活动的对象。
• src：发起活动的对象（如果与主账号不同）。
• target：操作对象。

每种事件类型都要求至少有一个字段包含数据。

辅助字段包括：

• intermediary：在事件中充当中介的任何对象。这可能包括代理服务器和邮件服务器等对象。
• observer：不直接与相关流量交互的任何对象。这可能是漏洞扫描器或数据包嗅探器设备。
• about：在事件中发挥作用且可选的任何其他对象。

主账号属性

表示发起活动的操作实体或设备。主账号必须至少包含一个机器详细信息（主机名、MAC 地址、IP 地址、产品专用标识符，例如 CrowdStrike 机器 GUID）或用户详细信息（例如用户名），并可选择包含进程详细信息。不得包含以下任何字段：电子邮件、文件、注册表项或值。

如果事件发生在单台机器上，则该机器仅在 principal 属性中描述。该机器不需要在 target 或 src 属性中进行描述。

注意 ：安全设备可能会记录事件，但不会在主属性中进行描述。它将在 observer 或 intermediary 属性中进行描述。如果安全软件（例如 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 的供应商专用资产标识符，这是由第三方安全产品生成的唯一标识符。

目标属性

表示事件引用的目标设备或目标设备上的对象。例如，在从设备 A 到设备 B 的防火墙连接中，设备 A 被捕获为主体，设备 B 被捕获为目标。

对于进程 C 向目标进程 D 进行的进程注入，进程 C 是主体，进程 D 是目标。

图：主账号与目标

以下示例说明了如何填充目标字段。

target {
   ip: "192.0.2.31"
   port: 80
}

如果原始原始日志中提供了更多信息（例如主机名、其他 IP 地址、MAC 地址和专有资产标识符），则这些信息也应包含在目标和主账号字段中。

principal 和 target 都可以表示同一台机器上的操作者。例如，在机器 X 上运行的进程 A（主体）可以作用于同样在机器 X 上运行的进程 B（目标）。

src 属性

表示参与者正在处理的源对象，以及源对象的设备或进程上下文（源对象所在的机器）。例如，如果用户 U 将机器 A 上的文件 A 复制到机器 Y 上的文件 B，则 UDM 事件的 src 部分中将指定文件 A 和机器 X。

中介属性

表示有关处理事件中所述活动的一个或多个中间设备的详细信息。这可能包括代理服务器和 SMTP 中继服务器等设备的详细信息。

observer 属性

表示观察者设备，它不是直接中介，但会观察并报告相关事件。这可能包括数据包嗅探器或基于网络的漏洞扫描器。

about 属性

此字段用于存储事件引用的对象的详细信息，这些对象在 principal、src、target、intermediary 或 observer 字段中没有描述。例如，它可以捕获以下内容：

• 邮件附件。
• 邮件正文中嵌入的域名、网址或 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) 了这些附件，然后转发了清理后的电子邮件。
• 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，但字段类型为 Noun。名词是一种常用的数据结构，用于在实体和事件中存储信息。

• 如果 metadata.entity_type 为 USER，则数据存储在 entity.user 属性下。
• 如果 metadata.entity_type 为 ASSET，则数据存储在 entity.asset 属性下。

关系属性

关系属性下的字段存储与主实体相关的其他实体的信息。例如，如果主要实体是用户，并且该用户已获得笔记本电脑。笔记本电脑是相关实体。 笔记本电脑的相关信息存储为 entity 记录，其中 metadata.entity_type = ASSET。用户信息存储为 entity 记录，其中 metadata.entity_type = USER。

用户实体记录还会使用 relation 属性下的字段来捕获用户与笔记本电脑之间的关系。relation.relationship 字段存储用户与笔记本电脑的关系，具体而言，用户拥有笔记本电脑。relation.entity_type 字段存储值 ASSET，因为笔记本电脑是设备。

relations.entity Attribute Store 下的字段存储有关笔记本电脑的信息，例如主机名和 MAC 地址。再次注意，字段名称为 entity，字段类型为名词。名词是一种常用的数据结构。 relation.entity Attribute Store 下的字段用于存储笔记本电脑的相关信息。

relation.direction 字段存储用户与笔记本电脑之间关系的方向性，具体而言，关系是双向还是单向。

需要更多帮助？获得社区成员和 Google SecOps 专业人士的解答。