统一数据模型概览
本文档简要介绍了统一数据模型 (UDM)。如需详细了解 UDM 字段（包括每个字段的说明），请参阅 UDM 字段列表。如需详细了解解析器映射，请参阅解析器映射的重要 UDM 字段。
UDM 是 Google Security Operations 标准数据结构，用于存储与从来源收到的数据相关的信息。它也称为架构。Google 安全运营团队会以两种格式存储收到的原始数据，即原始原始日志和结构化 UDM 记录。UDM 记录是原始日志的结构化表示。
如果指定的日志类型存在解析器，系统会使用原始日志创建 UDM 记录。客户还可以在使用 Ingestion API 将数据发送到 Google Security Operations 之前，将原始日志转换为结构化 UDM 格式。
UDM 的一些优势包括：
- 使用相同的语义存储来自不同供应商的相同类型的记录。
- 由于数据会标准化为标准 UDM 架构，因此更容易识别用户、主机和 IP 地址之间的关系。
- 由于规则可以跨平台使用，因此更易于编写规则。
- 更轻松地支持来自新设备的日志类型。
虽然您可以使用原始日志搜索功能搜索事件，但由于 UDM 搜索的具体性，其速度更快且精确度更高。
Google 安全运营团队会对其收集的所有事件使用 UDM 架构。UDM 包含数千个字段，用于描述和分类事件。例如，UDM 可以像处理网络通信事件一样轻松地处理端点进程事件。
UDM 结构
UDM 事件由多个部分组成。每个 UDM 事件中第一个找到的部分是元数据部分。它提供事件的基本说明，包括事件发生的时间戳和事件提取到 Google 安全运营中心的时间戳。其中还包括商品信息、版本和说明。提取解析器会根据预定义的事件类型对每个事件进行分类，而不依赖于特定产品日志。仅使用元数据字段，您就可以快速开始搜索数据。
除了元数据部分之外，其他部分还介绍了事件的其他方面。如果某个部分不必要，则不会包含该部分，从而节省内存。
principal：发起事件中活动的实体。 还包含引用来源 (src) 和目标 (target) 的部分。intermediary：事件经过的系统，例如代理服务器或 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 为 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 事件：存储在环境中发生的操作的数据。原始事件日志会描述设备记录的操作，例如防火墙和网络代理。这是 UDM 事件数据模型。
- UDM 实体：环境中资产、用户和资源等元素的上下文表示。它是从真相来源数据源获取的。这是 UDM 实体数据模型。
以下是事件数据模型和实体数据模型的两个概要视觉表示。
图：事件数据模型
图：实体数据模型
UDM 事件的结构
UDM 事件包含多个部分，每个部分都存储单个记录的数据子集。这些部分包括：
- 元数据
- 主账号
- 目标
- src
- observer
- 中介
- 关于
- 网络
- 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 安全运营团队会读取 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 小时，表示太平洋标准时间。
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：执行了 activity 的对象。src：发起 activity 的对象（如果不同于主账号）。target：要执行操作的对象。
每种事件类型都要求至少有一个字段包含数据。
辅助字段包括：
intermediary：在事件中充当中介的任何对象。这可能包括代理服务器和邮件服务器等对象。observer：与相关流量没有直接互动的任何对象。这可能是漏洞扫描器或数据包嗅探器设备。about：在事件中发挥作用的任何其他对象（可选）。
主要属性
表示发起活动的实体或设备。主账号必须至少包含一项机器详细信息（主机名、MAC 地址、IP 地址、CrowdStrike 机器 GUID 等标识符）或用户详细信息（例如用户名），还可以选择包含进程详情。不得包含以下任何字段：电子邮件、文件、注册表项或值。
如果事件发生在单个机器上，则只需在 principal 属性中描述该机器。该机器不需要在 target 或 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），这是第三方安全产品生成的唯一标识符。
目标属性
表示事件所引用的目标设备，或目标设备上的对象。例如，在从设备 A 到设备 B 的防火墙连接中，设备 A 会被捕获为正文，设备 B 会被捕获为目标。
对于通过进程 C 到目标进程 D 的进程注入，进程 C 是主进程，进程 D 是目标。
图：主图像与目标图像
以下示例展示了如何填充目标字段。
target {
ip: "192.0.2.31"
port: 80
}
如果原始原始日志中包含主机名、其他 IP 地址、MAC 地址和专有资源标识符等更多信息，这些信息也应包含在 target 和 principal 字段中。
principal 和 target 都可以代表同一台机器上的操作者。例如，在机器 X 上运行的进程 A（主账号）也可以在机器 X 上处理进程 B（目标）。
src 属性
表示参与者执行操作的源对象，以及源对象的设备或进程上下文（源对象所在的机器）。例如，如果用户 U 将机器 X 上的文件 A 复制到机器 Y 上的文件 B，则 UDM 事件的 src 部分中将指定文件 A 和机器 X。
intermediary 属性
表示有关处理事件中描述的一个或多个中间设备的详细信息。这可能包括有关代理服务器和 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 或 security_result.action = ALLOW_WITH_MODIFICATION) 这些附件，然后转发已消毒的电子邮件。
- SSO 系统允许被阻止 (security_result.action = BLOCK) 的登录 (security_result.category = AUTH_VIOLATION)。
- 恶意软件沙盒在将文件发送 (security_result.action = ALLOW) 给用户收件箱中的用户五分钟后，在文件附件中检测到间谍软件 (security_result.category = 软件_MALICIOUS)。
network 属性
网络属性用于存储与网络相关的事件数据以及子消息中的协议详细信息。这包括发送和接收的电子邮件以及 HTTP 请求等活动。
extensions 属性
此属性下的字段会存储原始原始日志中捕获的事件的其他元数据。其中可能包含有关漏洞的信息或其他身份验证相关信息。
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 属性下。
relation 属性
关系属性下的字段用于存储与主实体相关的其他实体的信息。例如，如果主要实体是“用户”，并且用户已获配笔记本电脑。笔记本电脑是相关实体。笔记本电脑的相关信息会存储为“实体”记录，其中 metadata.entity_type 的值为 ASSET。用户的相关信息会存储为“实体”记录，其中 metadata.entity_type = USER。
用户实体记录还会使用“relation”属性下的字段捕获用户与笔记本电脑之间的关系。relation.relationship 字段用于存储用户与笔记本电脑的关系，具体而言，该字段表示用户拥有笔记本电脑。由于笔记本电脑是一种设备，因此 relation.entity_type 字段会存储值 ASSET。
relations.entity 属性下的字段存储笔记本电脑的相关信息，例如主机名和 MAC 地址。再次请注意，字段名称为“entity”，字段类型为 Noun。名词是一种常用的数据结构。relation.entity 属性下的字段存储笔记本电脑的相关信息。
relation.direction 字段用于存储用户与笔记本电脑之间关系的方向性，具体而言，是双向还是单向。
需要更多帮助？向社区成员和 Google SecOps 专业人士寻求解答。