统一数据模型概览

支持以下语言：

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

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

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

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 登录

以下搜索列出了 Microsoft Windows 4624 成功登录事件， 以及事件的生成时间（仅根据以下两个 UDM 字段显示）：

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：命令行。

示例：搜索与特定部门关联的成功用户登录

以下示例会按用户 (metadata.event_type) 搜索登录信息 USER_LOGIN）与营销部门 (target.user.department) 相关联 marketing）。虽然 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
  • 观察者
  • 中转
  • 关于
  • network
  • security_result

  • 扩展程序

    事件数据 模型

    图：事件数据模型

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

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

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

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

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

about 和 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 字段 list 文档。

metadata.event_type 值决定了 和选填字段必须包含在 UDM 记录中。有关 要针对每种事件类型包含哪些字段，请参阅 UDM 用法 指南。

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

principal、target、src intermediary 和 observer 属性描述资产 事件的相关方每个存储区中涉及的对象 活动（由原始原始日志记录）。可以是设备或 执行操作的用户，也就是 活动。它还可以描述观察到活动的安保设备，例如电子邮件代理或网络路由器。

最常用的属性包括：

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

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

辅助字段有：

  • intermediary：在事件中充当中介的任何对象。这可能包括代理服务器和邮件服务器等对象。
  • observer：不直接与 相关流量这可能是漏洞扫描程序或数据包 Sniffer 设备。
  • 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 地址 端口号和主机名它还包含供应商专用资产标识符 （由第三方安全服务提供商生成的唯一标识符） 产品。

目标属性

表示事件引用的目标设备，或 目标设备。例如，在从设备 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，则 UDM 事件的 src 部分中将指定文件 A 和机器 X。

中间属性

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

观察者属性

表示一种不是直接中介，而是 用于观察和报告相关事件。这可能包括 Sniffer 或基于网络的漏洞扫描程序。

“简介”属性

它存储了与非 如 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.category = AUTH_VIOLATION) 已被屏蔽 (security_result.action = BLOCK)。
  • 恶意软件沙盒在将文件发送 (security_result.action = ALLOW) 给用户收件箱中的用户五分钟后，在文件附件中检测到间谍软件 (security_result.category = 软件_MALICIOUS)。

广告网络属性

网络属性会存储有关网络相关事件的数据以及有关 协议。这包括发送和接收的电子邮件以及 HTTP 请求等活动。

扩展程序属性

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

UDM 实体的结构

UDM 实体记录用于存储组织内任何实体的相关信息。 如果 metadata.entity_type 为 USER，则记录会在 entity.user 属性下存储与用户相关的信息。如果 metadata.entity_type 为 ASSET，则记录会存储有关资产的信息，例如工作站、笔记本电脑、手机和虚拟机。

实体数据 模型

图：事件数据模型

元数据字段

本部分包含 UDM 实体中的必填字段，例如：

  • collection_timestamp：日期和记录收集时间。
  • entity_type：实体的类型，如资产、用户和资源。

实体属性

entity 属性下的字段存储有关特定 实体，例如主机名和 IP 地址（如果是资产）或 windows_sid 和 电子邮件地址。请注意，字段名称为“entity”，但字段类型为 Noun。名词是一种常用的数据结构 同时提供实体和事件中的信息

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

关系属性

关系属性下的字段存储有关 主要实体相关。例如，如果主要实体是“用户” 并获得了一台笔记本电脑。笔记本电脑是一个相关实体。 关于笔记本电脑的信息会存储为“实体”录制 metadata.entity_type = ASSET。用户的相关信息会存储为“实体”记录，其中 metadata.entity_type = USER。

用户实体记录还捕获了用户与 笔记本电脑，使用“关系”下的字段属性。relation.relationship 字段用于存储用户与笔记本电脑的关系，具体而言，表示用户拥有笔记本电脑。由于笔记本电脑是一种设备，因此 relation.entity_type 字段会存储值 ASSET。

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

Relation.direction 字段存储了关系的方向 具体是指用户和笔记本电脑之间的关系， 是双向还是单向