统一数据模型概览

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

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

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

UDM 的部分优势包括：

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

虽然您可以使用原始日志搜索来搜索事件，但由于其特异性，UDM 搜索的速度更快且精确度更高。

Google Security Operations 针对其收集的所有事件使用 UDM 架构。UDM 包含数千个用于描述和分类事件的字段。例如，UDM 可以像处理网络通信事件一样轻松地处理端点处理事件。

UDM 结构

UDM 活动由多个部分组成。每个 UDM 事件中的第一个部分都是元数据部分。它提供事件的基本说明，包括事件发生时的时间戳以及事件被提取到 Google Security Operations 中的时间戳。还包括产品信息、版本和说明提取解析器根据预定义的事件类型（独立于特定商品日志）对每个事件进行分类。只需使用元数据字段，您就可以快速开始搜索数据。

除元数据部分之外，其他部分还包含事件的其他方面。如果某个部分不是必需的，则不会将其包含在内，从而节省内存。

  • principal：发起事件中的 activity 的实体。还包含引用源 (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 在网络数据中搜索 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 事件：存储环境中发生的操作的数据。原始事件日志会按设备（如防火墙和 Web 代理）记录的原样描述操作。这是 UDM 事件数据模型。
  • UDM 实体：您的环境中的资产、用户和资源等元素的上下文表示法。它从可信来源数据源获取。这是 UDM 实体数据模型。

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

事件数据模型

图：事件数据模型

实体数据模型

图：实体数据模型

UDM 事件的结构

UDM 事件包含多个部分，每个部分针对单条记录存储一部分数据。这三个部分包括：

  • 元数据
  • 主账号
  • 目标
  • src
  • 观察者
  • 中转
  • about
  • 您的VPC网络与本地网络之间的网络连接
  • security_result

  • 扩展程序

    事件数据模型

    图：事件数据模型

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

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

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

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

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

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

每个 UDM 事件都会存储一个原始原始日志事件的值。根据事件类型，某些属性是必需属性，其他属性则是可选的。必需属性和可选属性由 metadata.event_type 值决定。收到日志后，Google Security Operations 会读取 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) 的偏移量为零，表示太平洋标准时间。

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 使用指南。

主账号、目标、src、中介、观察者和 about 属性

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

最常用的属性包括：

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

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

辅助字段有：

  • intermediary：充当事件中的中间方的任何对象。这可能包括代理服务器和邮件服务器等对象。
  • observer：不与相关流量直接交互的任何对象。这可能是漏洞扫描程序或数据包嗅探器设备。
  • about：在事件中扮演了角色的任何其他对象，可选。

主要属性

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

如果事件发生在单台机器上，则该机器仅在主属性中描述。无需在 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 地址和专有资产标识符），也应该包含在目标和主账号字段中。

主账号和目标都可以代表同一台机器上的参与者。例如，在机器 X 上运行的进程 A（主帐号）也可以对机器 X 上的进程 B（目标）执行操作。

src 属性

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

中间属性

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

观察者属性

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

“简介”属性

此存储空间用于存储事件引用的对象（未在主账号、src、目标、中间或观察者字段中描述）的详细信息。例如，它可以捕获以下内容：

  • 电子邮件文件附件。
  • 内嵌在电子邮件正文中的网域、网址或 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.category = AUTH_VIOLATION)，但登录被阻止 (security_result.action = BLOCK)。
  • 恶意软件沙盒在将文件 (security_result.action = ALLOW) 发送给用户 5 分钟后，在附件中检测到间谍软件 (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。

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

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

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