Google SecOps 如何丰富事件和实体数据

本文档介绍了 Google Security Operations 如何丰富数据，以及存储数据的统一数据模型 (UDM) 字段。

为了能够进行安全调查，Google SecOps 会从不同来源提取情境数据，对这些数据进行分析，并提供客户环境中有关制品的其他情境信息。分析师可以在 Detection Engine 规则、调查搜索或报告中使用情境丰富的数据。

Google SecOps 会执行以下类型的丰富化：

• 通过使用实体图和合并来丰富实体。
• 计算每个实体的流行度统计信息，并使用该信息丰富每个实体，以指示实体在环境中的受欢迎程度。
• 计算特定实体类型首次出现在环境中的时间或最近一次出现在环境中的时间。
• 利用安全浏览威胁列表中的信息丰富实体。
• 使用地理定位数据丰富事件。
• 利用 WHOIS 数据丰富实体。
• 使用 VirusTotal 文件元数据丰富事件。
• 利用 VirusTotal 关系数据丰富实体。
• 提取和存储 Google Cloud 威胁情报数据。

来自 WHOIS、Google 安全浏览、GCTI 威胁情报、VirusTotal 元数据和 VirusTotal 关系链的丰富数据分别通过 entity_type、product_name 和 vendor_name 进行标识。创建使用此类丰富数据的规则时，建议您在规则中添加一个过滤器，用于标识要包含的特定丰富类型。此过滤条件有助于提高规则的性能。 例如，在联接 WHOIS 数据的规则的 events 部分中添加以下过滤字段。

$enrichment.graph.metadata.entity_type = "DOMAIN_NAME"
$enrichment.graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
$enrichment.graph.metadata.vendor_name = "WHOIS"

使用实体图和合并功能丰富实体

实体图可识别环境中的实体和资源之间的关系。 当来自不同来源的实体被提取到 Google SecOps 中时，实体图会根据实体之间的关系维护邻接表。实体图通过执行去重和合并来丰富上下文。

在去重期间，系统会消除冗余数据并形成间隔，以创建通用实体。例如，假设有两个实体 e1 和 e2，其时间戳分别为 t1 和 t2。实体 e1 和 e2 已去重，在去重期间不会使用不同的时间戳。在去重期间，系统不会使用以下字段：

• collected_timestamp
• creation_timestamp
• interval

在合并期间，系统会针对一天的时间间隔形成实体之间的关系。例如，假设实体记录 user A 有权访问某个 Cloud Storage 存储桶。存在另一条实体记录，其中 user A 拥有某部设备。合并后，这两个实体会合并为一个具有两个关系的实体 user A。一种关系是 user A 有权访问 Cloud Storage 存储桶，另一种关系是 user A 是设备的所有者。Google SecOps 在创建实体上下文数据时会执行为期 5 天的回溯。这会处理迟到的数据，并为实体上下文数据创建隐式存留时间。

Google SecOps 使用别名来丰富遥测数据，并使用实体图来丰富实体。检测引擎规则将合并的实体与丰富的遥测数据联接，以提供情境感知分析。

包含实体名词的事件被视为实体。以下是一些事件类型及其对应的实体类型：

• ASSET_CONTEXT 对应于 ASSET。
• RESOURCE_CONTEXT 对应于 RESOURCE。
• USER_CONTEXT 对应于 USER。
• GROUP_CONTEXT 对应于 GROUP。

实体图会使用威胁信息来区分上下文数据和入侵指标 (IOC)。

使用情境丰富的数据时，请考虑以下实体图行为：

• 请勿在实体中添加间隔，而是让实体图创建间隔。这是因为除非另有指定，否则系统会在去重期间生成间隔。
• 如果指定了时间间隔，则仅对相同事件进行去重，并保留最新的实体。
• 为确保实时规则和回溯搜索按预期运行，实体必须每天至少提取一次。
• 如果实体不是每天提取，而是每两天或更长时间提取一次，实时规则可能会按预期运行，但回溯搜索可能会丢失事件的上下文。
• 如果实体每天被多次提取，则系统会将该实体去重为单个实体。
• 如果某天的活动数据缺失，系统会暂时使用前一天的数据，以确保实时规则正常运行。

实体图还会合并具有相似标识符的事件，以获得整合的数据视图。系统会根据以下标识符列表进行合并：

• Asset
  • entity.asset.product_object_id
  • entity.asset.hostname
  • entity.asset.asset_id
  • entity.asset.mac
• User
  • entity.user.product_object_id
  • entity.user.userid
  • entity.user.windows_sid
  • entity.user.email_addresses
  • entity.user.employee_id
• Resource
  • entity.resource.product_object_id
  • entity.resource.name
• Group
  • entity.group.product_object_id
  • entity.group.email_addresses
  • entity.group.windows_sid

计算患病率统计信息

Google SecOps 会对现有数据和传入数据执行统计分析，并使用与普遍程度相关的指标来丰富实体上下文记录。

流行度是一个数值，用于指示实体的受欢迎程度。受欢迎程度由访问工件（例如网域、文件哈希或 IP 地址）的资产数量来定义。数字越大，实体越受欢迎。 例如，google.com 的普遍性值较高，因为用户经常访问它。如果某个网域的访问频率较低，其普及率值也会较低。较受欢迎的实体通常不太可能是恶意实体。

网域、IP 和文件（哈希）支持这些丰富的值。这些值会计算并存储在以下字段中。

每个实体的流行度统计信息每天都会更新。值存储在 Detection Engine 可以使用的单独实体情境中，但不会显示在 Google SecOps 调查视图和 UDM 搜索中。

创建 Detection Engine 规则时可以使用以下字段。

day_max 和 rolling_max 值的计算方式不同。这些字段的计算方式如下：

• day_max 的计算方式为相应制品在一天内的最高流行度得分，其中一天是指 12:00:00 AM - 11:59:59 PM UTC。
• rolling_max 的计算方式为：在过去 10 天的时间窗口内，制品每天的最高流行度得分（即 day_max）。
• day_count 用于计算 rolling_max，且始终为值 10。

针对网域计算时，day_max 与 day_max_sub_domains（以及 rolling_max 与 rolling_max_sub_domains）之间的区别如下：

• rolling_max 和 day_max 表示每天访问指定网域（不包括子网域）的唯一内部 IP 地址的数量。
• rolling_max_sub_domains 和 day_max_sub_domains 表示访问给定网域（包括子网域）的唯一内部 IP 地址的数量。

系统会根据新提取的实体数据计算普及率统计信息。系统不会对之前提取的数据进行回溯性计算。系统大约需要 36 小时来计算和存储统计信息。

计算实体的首次看到时间和最后一次看到时间

Google SecOps 会对传入的数据执行统计分析，并使用实体的首次发现时间和上次发现时间来丰富实体上下文记录。first_seen_time 字段存储实体首次出现在客户环境中的日期和时间。last_seen_time 字段存储最近一次观测的日期和时间。

由于多个指标（UDM 字段）可以标识资产或用户，因此首次发现时间是指在客户环境中首次发现标识用户或资产的任何指标的时间。

描述资产的所有 UDM 字段如下所示：

• entity.asset.hostname
• entity.asset.ip
• entity.asset.mac
• entity.asset.asset_id
• entity.asset.product_object_id

描述用户的所有 UDM 字段如下：

• entity.user.windows_sid
• entity.user.product_object_id
• entity.user.userid
• entity.user.employee_id
• entity.user.email_addresses

首次发现时间和最后一次发现时间可帮助分析师关联在首次发现网域、文件（哈希）、资产、用户或 IP 地址后发生的某些活动，或在最后一次发现网域、文件（哈希）或 IP 地址后停止发生的活动。

first_seen_time 和 last_seen_time 字段填充了描述网域、IP 地址和文件（哈希）的实体。对于描述用户或资产的实体，仅填充 first_seen_time 字段。对于描述其他类型的实体（例如群组或资源），系统不会计算这些值。

系统会针对所有命名空间中的每个实体计算统计信息。Google SecOps 不会计算各个命名空间内每个实体的统计信息。这些统计信息目前不会导出到 BigQuery 中的 Google SecOps events 架构。

丰富后的值会计算并存储在以下 UDM 字段中：

利用地理定位数据丰富事件

传入的日志数据可能包含没有相应位置信息的外部 IP 地址。当事件记录不在企业网络中的设备活动信息时，通常会发生这种情况。例如，云服务的登录事件将包含来源 IP 地址或客户端 IP 地址，该地址基于运营商 NAT 返回的设备的外部 IP 地址。

Google SecOps 可为外部 IP 地址提供地理位置丰富的数据，从而实现更强大的规则检测，并为调查提供更丰富的背景信息。例如，Google SecOps 可能会使用外部 IP 地址来丰富事件，添加有关国家/地区（例如美国）、特定州（例如阿拉斯加）以及 IP 地址所在的网络（例如 ASN 和运营商名称）的信息。

Google SecOps 会使用 Google 提供的位置信息数据来提供 IP 地址的大致地理位置和网络信息。您可以针对事件中的这些字段编写 Detection Engine 规则。丰富后的事件数据也会导出到 BigQuery，以便在 Google SecOps 信息中心和报告中使用。

以下 IP 地址未进行丰富处理：

• RFC 1918 专用 IP 地址空间，因为它们是企业网络的内部地址。
• RFC 5771 多播 IP 地址空间，因为多播地址不属于单个位置。
• IPv6 唯一本地地址。
• Google Cloud 个服务 IP 地址。例外情况是 Google Cloud Compute Engine 外部 IP 地址，这些地址会经过丰富处理。

Google SecOps 会使用地理位置数据来丰富以下 UDM 字段：

• principal
• target
• src
• observer

以下示例展示了会添加到 UDM 事件中的地理信息类型，该事件的 IP 地址标记为荷兰：

不一致

Google 专有的 IP 地理定位技术结合使用网络数据和其他输入内容及方法，为我们的用户提供 IP 地址位置和网络解析。 其他组织可能会使用不同的信号或方法，这有时可能会导致不同的结果。

如果您遇到 Google 提供的 IP 地理定位结果不一致的情况，请提交客户支持请求，以便我们进行调查，并在适当的情况下更正我们的记录。

利用安全浏览威胁列表中的信息丰富实体

Google SecOps 会从安全浏览功能中提取与文件哈希相关的数据。每个文件的数据都存储为一个实体，并提供有关该文件的其他上下文信息。分析师可以创建 Detection Engine 规则，针对此实体情境数据运行查询，以构建情境感知分析。

以下信息会与实体情境记录一起存储。

利用 WHOIS 数据丰富实体

Google SecOps 每天都会注入 WHOIS 数据。在注入传入的客户设备数据期间，Google SecOps 会根据 WHOIS 数据评估客户数据中的网域。如果找到匹配项，Google SecOps 会将相关的 WHOIS 数据与网域的实体记录一起存储。对于每个实体（其中 entity.metadata.entity_type = DOMAIN_NAME），Google SecOps 会使用 WHOIS 中的信息来扩充该实体。

Google SecOps 会将丰富后的 WHOIS 数据填充到实体记录中的以下字段：

• entity.domain.admin.attribute.labels
• entity.domain.audit_update_time
• entity.domain.billing.attribute.labels
• entity.domain.billing.office_address.country_or_region
• entity.domain.contact_email
• entity.domain.creation_time
• entity.domain.expiration_time
• entity.domain.iana_registrar_id
• entity.domain.name_server
• entity.domain.private_registration
• entity.domain.registrant.company_name
• entity.domain.registrant.office_address.state
• entity.domain.registrant.office_address.country_or_region
• entity.domain.registrant.email_addresses
• entity.domain.registrant.user_display_name
• entity.domain.registrar
• entity.domain.registry_data_raw_text
• entity.domain.status
• entity.domain.tech.attribute.labels
• entity.domain.update_time
• entity.domain.whois_record_raw_text
• entity.domain.whois_server
• entity.domain.zone

如需了解这些字段的说明，请参阅统一数据模型字段列表文档。

提取和存储 Google Cloud 威胁情报数据

Google SecOps 会从 Google Cloud 威胁情报 (GCTI) 数据源中提取数据，这些数据源可为您提供在调查环境中的活动时可使用的背景信息。您可以查询以下数据源：

• GCTI Tor 退出节点：已知 Tor 退出节点的 IP 地址。
• GCTI 良性二进制文件：属于操作系统原始分发版或通过官方操作系统补丁更新的文件。此数据源中排除了某些已被攻击者通过“借力打力”攻击中常见的活动滥用的官方操作系统二进制文件，例如专注于初始入口向量的二进制文件。

• GCTI 远程访问工具：恶意行为者经常使用的文件。 这些工具通常是合法应用，但有时会被滥用以远程连接到遭入侵的系统。

  这些情境数据以实体的形式存储在全局范围内。您可以使用检测引擎规则查询数据。在规则中添加以下 UDM 字段和值，以查询这些全局实体：

• graph.metadata.vendor_name = Google Cloud Threat Intelligence

• graph.metadata.product_name = GCTI Feed

在此文档中，占位符 <variable_name> 表示规则中用于标识 UDM 记录的唯一变量名称。

有时效性与无时效性 Google Cloud 威胁情报数据源

Google Cloud 威胁情报数据源分为有时限和无时限两种。

有时限的数据源的每个条目都关联着一个时间范围。这意味着，如果在第 1 天生成了检测结果，那么在未来的任何一天，回溯搜索都应针对第 1 天生成相同的检测结果。

无时限数据源不关联任何时间范围。这是因为只有最新的一组数据才应被考虑。无时限数据源通常用于预计不会更改的数据，例如文件哈希。如果在第 1 天未生成检测结果，则在第 2 天，由于添加了新条目，系统可能会在回溯搜索期间为第 1 天生成检测结果。

有关 Tor 退出节点 IP 地址的数据

Google SecOps 会注入并存储已知的 Tor 退出节点的 IP 地址。Tor 退出节点是流量离开 Tor 网络的点。从相应数据源提取的信息存储在以下 UDM 字段中。相应来源中的数据是定时数据。

有关良性操作系统文件的数据

Google SecOps 会从 GCTI 良性二进制文件数据源中提取并存储文件哈希。从相应数据源提取的信息存储在以下 UDM 字段中。相应来源中的数据没有时间限制。

有关远程访问工具的数据

远程访问工具包括已知远程访问工具（例如恶意行为者经常使用的 VNC 客户端）的文件哈希。这些工具通常是合法应用，但有时会被滥用，以远程连接到遭入侵的系统。从此数据源提取的信息存储在以下 UDM 字段中。相应来源中的数据没有时间限制。

使用 VirusTotal 文件元数据丰富事件

Google SecOps 会将文件哈希丰富为 UDM 事件，并在调查期间提供更多背景信息。在客户环境中，通过哈希别名化来丰富 UDM 事件。哈希别名功能可将所有类型的文件哈希组合在一起，并在搜索期间提供有关文件哈希的信息。

通过将 VirusTotal 文件元数据和关系丰富功能与 Google SecOps 集成，您可以识别恶意活动模式，并跟踪恶意软件在网络中的移动情况。

原始日志提供的文件信息有限。VirusTotal 会使用文件元数据丰富事件，以提供不良哈希的转储以及有关不良文件的元数据。元数据包括文件名、类型、导入的函数和标记等信息。您可以在 UDM 搜索和检测引擎中使用 YARA-L 来了解恶意文件事件，并在威胁搜寻过程中使用这些信息。一个使用情形示例是检测对原始文件的任何修改，然后导入文件元数据以进行威胁检测。

记录中会存储以下信息。 如需查看所有 UDM 字段的列表，请参阅统一数据模型字段列表。