UDM 概览

支持的平台：

Google SecOps SIEM

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

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

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

UDM 的部分优势包括：

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

注意： Google SecOps 规则引擎使用相同的 UDM 字段名称。您可以在创建规则时使用这些相同的字段名称。

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

UDM 结构

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

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

• principal：事件中发起 activity 的实体。 还包括引用来源 (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）。每种事件类型还需要使用与原始事件关联的信息填充一组其他字段和值。如需详细了解每种事件类型应包含哪些字段，请参阅每种 UDM 事件类型的必需字段和可选字段。 以下示例说明了如何使用 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 事件必须指定以下一个或多个名词：

主体：表示执行操作的实体或发起事件中所述活动的设备。主体必须至少包含一项机器详细信息（主机名、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（以及其他名词）都可以引用同一台机器上的操作者。例如，如果进程 A (principal) 在机器 X 上运行，并处理也在机器 X 上运行的进程 B (target)，则您需要在各自的块中描述这两个进程。

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

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

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

• 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) 到用户收件箱五分钟后，恶意软件沙盒在文件附件中检测到间谍软件 (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 实体：环境中资产、用户和资源等元素的上下文表示形式。它从事实来源数据源中获取。

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

注意： 名词是指属性的类型。主体、目标、来源、中介、观察者和关于是存储数据的字段名称。

图：事件数据模型

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

图：实体数据模型

UDM 事件的结构

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

• 元数据
• 主体
• 目标
• src
• observer
• 中介
• 关于
• 网络
• 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) 的偏移量为 -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：执行 activity 的对象。
• src：启动 activity 的对象（如果与委托人不同）。
• 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 将机器 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 是资产，则记录会存储有关资产的信息，例如工作站、笔记本电脑、手机和虚拟机。

图：事件数据模型

元数据字段

此部分包含 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，字段类型为名词。Noun 是一种常用的数据结构。relation.entity 属性下的字段用于存储有关笔记本电脑的信息。

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

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