此页面由 Cloud Translation API 翻译。

统一数据模型概览

支持的语言：

Google SecOps SIEM

本文档简要介绍了统一数据模型 (UDM)。如需详细了解 UDM 字段（包括每个字段的说明），请参阅 UDM 字段列表。如需详细了解解析器映射，请参阅用于解析器映射的重要 UDM 字段。

UDM 是 Google Security Operations 标准数据结构，用于存储从来源接收的数据的相关信息。它也称为架构。 Google SecOps 会以两种格式存储收到的原始数据：原始原始日志和结构化 UDM 记录。UDM 记录是原始日志的结构化表示形式。

如果存在指定日志类型的解析器，则使用原始日志创建 UDM 记录。客户还可以使用 Ingestion API 将原始日志转换为结构化 UDM 格式，然后再将数据发送到 Google SecOps。

UDM 的部分优势包括：

使用相同的语义存储来自不同供应商的相同类型的记录。
由于数据已标准化为标准 UDM 架构，因此更容易识别用户、主机和 IP 地址之间的关系。
规则可以独立于平台，因此更易于编写。
更轻松地支持来自新设备的日志类型。

虽然您可以通过原始日志搜索来搜索事件，但由于 UDM 搜索具有特定性，因此速度更快，精确度更高。Google SecOps 会收集原始日志数据，并将事件日志详细信息存储在 UDM 架构中。UDM 提供了一个包含数千个字段的全面框架，用于描述和分类各种事件类型，例如端点进程事件和网络通信事件。

UDM 结构

UDM 事件由多个部分组成。每个 UDM 事件中都会包含元数据部分。它提供事件的基本说明，包括事件发生的时间戳和事件提取到 Google SecOps 中的时间戳。还包括商品信息、版本和说明。提取解析器会根据预定义的事件类型对每个事件进行分类，而与具体的产品日志无关。仅使用元数据字段，您就可以快速开始搜索数据。

除了元数据部分之外，其他部分还介绍了事件的其他方面。如果某个部分不必要，则不会包含该部分，从而节省内存。

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 实体：环境中资产、用户和资源等元素的上下文表示形式。它从 source of truth 数据源中获取。

以下是事件数据模型和实体数据模型的两个高级别直观表示形式。

活动数据模型

图：事件数据模型

实体数据模型

图：实体数据模型

UDM 事件的结构

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

元数据
主账号
目标
src
观察者
中介
关于
网络
security_result
扩展程序

图：事件数据模型

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

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

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

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

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

关于和扩展程序部分存储了其他部分未捕获的其他特定于供应商的事件信息。扩展程序部分是一组自由格式的键值对。

每个 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 小时，表示太平洋标准时间。

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：启动 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 地址和专有资产标识符，这些信息也应包含在目标字段和正文字段中。

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

src 属性

表示参与者执行操作的源对象，以及源对象的设备或进程上下文（源对象所在的机器）。例如，如果用户 U 将机器 X 上的文件 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.action = BLOCK) 的登录 (security_result.category = AUTH_VIOLATION)。
恶意软件沙盒在将文件发送 (security_result.action = ALLOW) 给用户收件箱中的用户五分钟后，在文件附件中检测到间谍软件 (security_result.category = SOFTWARE_MALICIOUS)。

网络属性

网络属性用于存储与网络相关的事件的数据以及子消息中有关协议的详细信息。这包括发送和接收的电子邮件以及 HTTP 请求等活动。

extensions 属性

此属性下的字段用于存储原始原始日志中捕获的事件的其他元数据。它可以包含有关漏洞的信息或其他与身份验证相关的信息。

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 属性下。

关联属性

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

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

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

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