了解规则检测延迟

支持的语言：

Google SecOps SIEM

本文档介绍了 Google Security Operations 中的规则检测延迟，确定了促成因素，概述了问题排查方法，并建议了尽可能减少延迟的技术。

检测规则

检测规则会检查常规实体通用数据模型 (UDM) 事件（即标准化原始日志），以根据规则的规范生成检测结果。实体 UDM 事件通常包含用户或资产详细信息等上下文信息。规则还会根据之前生成的检测结果生成检测结果。

预期延迟和未预测到的延迟

检测时间可能会因处理延迟而有所延迟。虽然有些规则会近乎实时地触发，但其他规则可能需要几分钟或几小时才能完成。规则类型、运行频率和检测生成方法等因素会影响这些延迟。本文档将探讨这些因素以及其他延迟因素。

我们将延迟分为预期延迟和未预测延迟。

• 预期延迟时间：这些延迟时间是由提取过程以及您在设置检测规则时做出的配置选择造成的。例如，创建检测所用的时间就是一个因素。这些延迟取决于已知的结构性因素，例如规则类型、运行频率、检测生成方法、已知限制和其他可预测的因素。
  您可以按照本文档中的说明更改或调整检测规则配置，以最大限度地缩短这些延迟时间。
  如需了解详情，请参阅缩短延迟时间的提示。

• 无法预测的延迟：这些是规则特定或事件特定的延迟，由多种因素造成，包括事件数据到达 Google SecOps 的延迟、Google SecOps 服务中处理流水线的暂时性缓慢、重新丰富以及其他数据处理延迟。

分析规则检测延迟时间

如需分析规则检测延迟，请查找有关规则及其周围因素的信息：

1. 在 Google SecOps 控制台中，依次前往检测 > 规则和检测。

   “规则”信息中心会显示规则元数据，例如 Rule name、Rule type 和 Run frequency。

   如需了解详情，请参阅在“规则”信息中心内查看规则。

2. 在“规则”信息中心中，点击规则名称可查看特定规则的检测历史记录和其他详细信息。

3. 对于任何特定的规则执行，有多种因素可能会影响检测延迟。Rule type、Run frequency、Event type、Event time 和 Ingested time 等维度是了解特定检测为何延迟的良好启发式方法。

检测类型列中的 图标表示检测结果是根据延迟超过 30 分钟的事件数据、规则重新处理运行或回溯搜索生成的。此图标也会显示在 Google SecOps 的提醒页面上。

1. 请熟悉以下主题，了解这些因素如何影响规则检测延迟：

   • 检测生成方法
   • 已知限制
   • 导致规则检测延迟的因素

检测生成方法

了解系统如何创建规则检测，以了解检测生成方法如何影响检测延迟。

系统会通过以下方式生成规则检测：

1. Streaming Engine

   Streaming Engine 是一种专用流式传输流水线，以低延迟（通常延迟不到 5 分钟）运行。它会评估标准单事件规则，这些规则不包含匹配部分、不包含外部数据集（例如参考列表或数据表），也不包含 UEBA 函数。

2. 查询引擎

   查询引擎可评估复杂的单事件规则和多事件规则：

   • 复杂的单事件规则：

     • 包含参考列表或数据表的单事件规则：评估单个事件并针对参考列表或数据表执行查找的规则。
     • 窗口化单事件规则：使用匹配窗口和简单存在性条件（例如 $e、#e > 0 或 #e >= 1）评估单个事件的规则。
     • 虽然复杂的单事件规则使用查询引擎而非流式传输引擎，但它们会按照高频近乎实时时间表在提取新数据时运行。这样可实现接近流式传输引擎典型延迟时间的更低延迟。在标准查询执行期间，系统会重新评估迟到的数据和丰富的数据，而无需多个事件校正间隔。

   • 多事件规则：这些规则会根据您设置的时间表，按事件时间（10 分钟、每小时、每天）块查询数据。 对于迟到的数据，重新查询的时间取决于调度类型。

     • 对于默认时间表，重新查询会在事件时间后大约 5 小时和 24 小时进行。
     • 可自定义的安排提供不同的结算时间。 如需了解详情，请参阅了解规则重放和 MTTD。

3. 针对历史数据运行的规则

   如需了解详情，请参阅回溯性搜索。

4. 重新丰富 UDM 事件

   如需了解详情，请参阅 UDM 事件的重新丰富和实体上下文图处理。

已知限制

以下是一些会导致规则检测延迟的标准限制：

• 富集延迟有时可能会超出预期。丰富处理重新运行会导致后续规则运行重新评估数据。系统会多次运行丰富化，丰富化可以在事件被提取后最多 24 小时内更新 UDM 事件。

• 多事件规则：

  • 对于采用默认时间表的多事件规则，系统会在事件时间后大约 5 小时和 24 小时重新执行规则。

  • 具有可自定义时间表的多事件规则具有不同的结算时间。

  系统会触发这些规则重放来处理延迟到达的数据。

• 情境感知规则是指依赖于资产和身份别名化或实体上下文图等丰富来源的规则。由于这些规则依赖于多个事件源，因此更容易受到高延迟的影响。

• 系统会在初始规则执行后的 5 到 8 小时内重新执行规则，并在 24 到 48 小时内再次重新执行规则。这两个单独的规则重放会根据重新处理流水线的执行时间触发。

• 如需了解其他检测限制，请参阅了解检测限制。

排查规则检测延迟问题

通过排除法排查规则检测延迟问题。

请按照以下建议的方法调查和排查规则检测延迟问题：

1. 检查是否存在明显的延迟：

   确定是否存在任何提取延迟：

   1. 在 Google SecOps 控制台中，依次前往检测 > 规则和检测。

   2. 在规则信息中心内搜索要分析的规则。

   3. 将 Event time 与 Ingested time 进行比较。

      例如，对于特定规则检测，如果 Event time 和 Ingested time 之间存在较大差距，您很可能可以将检测延迟归因于预期延迟。如果 Ingestion time 比 Event time 晚 30 分钟以上，则会在检测类型列中显示 图标。

2. 查看上下文来源收集时间：

   检查上下文来源的收集时间。

   情境感知规则可以包含以下情境来源。检查其收集时间：

   • 从 UDM 丰富化派生的字段。
   • 包含 principal 字段的事件。

   • 引用 graph.entity 字段的规则。

     使用 graph.entity 语法引用实体上下文图 (ECG) 的规则可能会导致延迟时间过长。例如，心电图流水线会生成情境数据，此过程可能需要 30 小时，在某些情况下甚至需要长达 8 天，具体取决于数据类型。

   如需了解详情，请参阅数据处理延迟。

3. 检查规则的运行频率和匹配时间范围配置：

   • 频率：检查规则的运行频率。如果规则配置为以较低的频率运行，自然会产生更长的检测延迟。
   • 匹配窗口：如果规则具有匹配窗口，则最短延迟时间为该窗口的持续时间。
   • 频次与匹配窗口的关系：确保运行频次与匹配窗口兼容。例如，对于匹配时长不足 60 分钟的实验，系统支持 10 分钟（近乎实时）的运行频率。对于 60 分钟或更长时间（最长 48 小时）的匹配窗口期，请使用 1 小时。对于超过 48 小时的匹配窗口，请使用“每天”。

4. 查看近期事件：

   查看近期是否有任何可能导致数据 Feed 延迟或出现问题的突发事件。

缩短延迟的技巧

如需更新检测规则配置，请参阅使用规则编辑器管理规则。

尽可能使用以下方法来缩短延迟时间：

• 对于对延迟时间敏感的规则，请使用最频繁的运行选项：

  • 提高规则频次：

    为了减少延迟，请根据规则类型和匹配窗口配置尽可能高的频次：

    • 对于所有单事件规则：使用近乎实时。
    • 对于匹配窗口小于 60 分钟的多事件规则：请使用近乎实时（10 分钟）。
    • 对于匹配窗口为 60 分钟或更长的多事件规则：请根据需要使用每小时或每天。

    如需了解详情，请参阅设置运行频率。

  • 缩短配对窗口期：

    缩短匹配窗口不会直接影响延迟时间，但可以通过设置最短延迟时间来提高效率。

• 避免延迟到达的数据：

  迟到的数据会错过初始查询，系统只有在 5 到 8 小时后重新查询其事件时间块时才会处理这些数据，从而导致严重延迟。准点数据通常会有大约 20 分钟的延迟。

导致规则检测延迟的因素

规则类型、运行频率和 Google SecOps 的提取速度是导致规则检测延迟的关键因素。

以下因素会导致规则检测延迟。

规则类型

规则分为两大类：

单事件规则

标准单事件规则可检测单个事件，无需外部数据查找、匹配窗口或用户和实体行为分析 (UEBA)。这些规则使用专用流式传输引擎以近乎实时的方式执行，可实现最低的检测延迟时间（通常不到 5 分钟）。

注意： 您可以使用 suppression_window 选项对单事件规则应用提醒抑制。

复杂的单事件规则

复杂的单事件规则会评估单个事件，但会纳入参考列表、数据表或简单的匹配窗口。它们使用查询引擎（而非 Streaming Engine）执行，但会以近乎实时的低延迟时间表进行调度，与 Streaming Engine 类似：

• 参考列表和数据表单事件规则：

  这些单事件规则会针对参考列表或数据表执行查找，而无需多事件匹配窗口。

• 窗口化单事件规则：

  这些单事件规则包含一个匹配窗口，其中包含简单的事件计数条件（例如 $e、#e > 0 或 #e >= 1）。

多事件规则

多事件规则按预定时间执行，因此由于预定运行之间的时间间隔，导致延迟时间较长。

• 多事件规则

  这些规则会检查两个或多个 UDM 事件条件。它们通常具有匹配窗口和多个条件。

• 情境感知规则

  情境感知规则可帮助您将其他实体和检测情境数据添加到事件中。

  • 这些规则包含两个或更多数据源，其中至少一个条件是 UDM 实体事件（其中 UDM 事件属于上下文类型，例如 user_context）。
  • 情境感知规则对延迟到达的数据最为敏感。
  • 情境感知规则的延迟时间通常最长，因为系统必须先生成必要的情境数据，例如实体上下文图 中的数据。
  • 如需了解详情，请参阅在规则中使用上下文丰富的数据。

详细了解单一事件规则和多个事件规则之间的区别。

规则运行频率

规则运行频率会直接影响检测延迟。

• 近乎实时：在提取事件时，规则以最短的延迟时间执行。适用范围：
  • 所有单事件规则（标准单事件规则、包含参考列表或数据表的规则，以及窗口化单事件规则）。
  • 匹配窗口期小于 60 分钟的多事件规则。
• 其他频次：对于其他规则配置，您可以设置以下频次：
  • 10 分钟的频次适用于时长不足 60 分钟的匹配窗口期。
  • 1 小时和每日频次的有效匹配窗口期最长为 48 小时。
  • 每日频次适用于所有超过 48 小时的匹配窗口期。

可能的解决方法：如需更快地检测到问题，请缩短运行频率。缩短匹配窗口不会直接影响延迟时间，但可以通过设置最短延迟时间来提高效率。

匹配窗口

如果规则具有匹配窗口，则窗口的持续时间决定了最短检测延迟时间，因为系统必须等待整个窗口期结束。

提取延迟

数据注入延迟是指 Google SecOps 在事件发生后注入数据所用的时间。

如果数据到达较晚，则会错过初始查询窗口。后续的历史处理查询会提取该数据，但可能会导致 5 到 8 小时的延迟。

例如：事件 A（事件时间为上午 9:03）和事件 B（事件时间为上午 9:05）属于一项规则，该规则旨在查找 30 分钟内的两个事件。如果事件 A 在上午 10:05 到达（晚了 1 小时），则会错过 9:00-9:30 时间段的初始查询。后续查询在下午 2 点到 5 点之间进行，然后生成检测结果，导致延迟 5 到 8 小时。

问题排查：验证您是否在事件发生后立即将数据发送到 Google SecOps。查看检测结果时，请仔细检查 UDM 事件和提取时间戳。

时区问题

Google SecOps SIEM 的默认时区为世界协调时间 (UTC)。如果日志未明确包含时区定义，系统会将其解读为世界协调时间 (UTC)。如果解读不正确，系统可能会将这些日志视为迟到日志，从而导致检测延迟，即使系统实时收到这些日志也是如此。

例如，某个日志的事件时间为美国东部时间上午 10:00（世界协调时间下午 15:00），该日志在世界协调时间下午 15:05 到达，但缺少时区信息。如果日志缺少时区，系统会将事件时间解读为 10:00 UTC。然后，系统会计算出解读后的事件时间（10:00 UTC）与实际提取时间（15:05 UTC）之间存在 5 小时的延迟。这种计算出的延迟会触发检测延迟，因为规则会根据实时提取情况确定处理优先级。

解决方法：如果原始数据的事件时间戳采用的是 UTC 以外的时区，请尝试以下方法之一：

• 更新原始数据的活动时区。
• 如果您无法在日志源处更新时区，请与支持团队联系以覆盖时区。
• 或者，使用 BindPlane 处理器更正时间戳并将其格式设置为 UTC，或添加相应的时区指示符。如需了解详情，请参阅使用 BindPlane 修改日志正文时间戳。

上下文联接

使用情境数据（例如 UEBA 或实体情境图字段）的多事件规则可能会出现更长的延迟。Google SecOps 必须先生成情境数据。

丰富化系统

Google SecOps 通过添加来自其他来源的上下文数据来丰富 UDM 事件。此过程通常会在 30 分钟内完成。如果延迟将这些丰富的数据添加到 UDM 事件中，可能会增加检测时间。

如需检查规则是否在评估富化字段，请查看事件查看器。如果规则正在评估富化字段，检测可能会延迟。

如需了解详情，请参阅数据丰富化。

别名和丰富情报

别名化和丰富化是 Google SecOps 安全数据丰富化流程中的两个步骤，用于将情境数据与事件记录相关联并添加到事件记录中。别名化用于查找连接，而丰富化则用于使用这些连接的数据填充 UDM 字段。此过程填充的字段称为“别名化字段”或“丰富字段”。

• 别名化：这是指识别和关联同一实体的不同名称或标识符的过程。它会查找描述指标的其他情境数据。例如，别名化可以将单个 hostname（如 alex-macbook）与其他相关指示器（如其 IP addresses 和 MAC addresses [来自 DHCP 日志]）相关联。别名还可以将 user ID（例如 alex）与用户的 job title 和 employment status（来自用户情境数据）相关联。
• 丰富化：此过程使用从别名化收集的信息为 UDM 事件添加背景信息。 例如，当仅包含 IP address 的新事件到达时，丰富过程会使用别名数据来查找关联的 hostname（例如 alex-macbook），并填充 $udm.event.principal.hostname 字段。

Google SecOps 支持多种实体类型的别名和丰富功能，包括：资产（例如主机名、IP 地址、MAC）、用户、进程、文件哈希元数据、地理位置和云资源。如需了解详情，请参阅 UDM 扩充和别名设置概览。

重新丰富 UDM 事件

• 底层数据发生变化：如果底层数据在事件被提取后发生变化，系统会重新处理历史数据，并在提取后最多 24 小时内更新事件。

• 富集系统更新：如果富集系统更新了实体或进程元数据、IP 地理定位或 VirusTotal 指标，规则引擎会在 24 到 48 小时后重新评估这些块，以捕获这些更新。
  例如，上午 9:03 的活动具有 entity.asset.hostname = hostnameA，但没有 IP。上午 8:55 的 DHCP 日志显示 hostnameA = IP 1.2.3.4。规则引擎在上午 9:10 运行，但规则不匹配。富集处理流水线会将该时间窗口内的 hostnameA 与 1.2.3.4 相关联，从而更新 UDM 事件。现在，规则匹配，系统创建了检测结果。

• 延迟的情境数据：如果您在初始日志发送一天后发送情境数据（例如 hostname），系统会重新丰富 UDM 事件。查找此重新丰富的数据的规则随后会再次运行并创建检测。

• 丰富数据的变化：丰富数据的变化可能会导致规则在稍后匹配，即使最初未匹配也是如此。
  例如，上午 9:03 的活动具有 entity.ip_geo_artifact.country_or_region = USA。规则引擎在上午 9:10 运行，查询上午 9:00 至 10:00 的数据，但规则不匹配。之后，丰富化重新处理会将地理位置更新为加拿大。当规则再次运行时，它现在会匹配，系统会创建检测结果。

实体上下文图处理

系统会生成 实体上下文图 (ECG) 信息并将其添加到日志数据中，以提供上下文，例如，失陷指标 (IOC) 或资产情境数据。由于 ECG 流水线主要依赖于批处理，因此实体上下文信息通常仅在规则执行创建检测后才会更新。

追溯式搜寻

当您使用 Retrohunt 针对历史数据运行规则时，系统仅在 Retrohunt 流程完成后创建检测结果。此过程可能会耗费大量时间，从而导致检测延迟。

追溯更新流程示例：

1. 初始事件：下午 1:00 收到一个事件，其值为 ip_address = 10.0.0.5。目前，hostname 尚不清楚。
2. 别名来源到达：下午 2:30（一个多小时后），系统收到下午 1:00 的 DHCP 日志，将 10.0.0.5 关联到 workstation-123。
3. 追溯性扩充：别名系统会处理此新链接。它会追溯性地更新下午 1:00 的 UDM 事件，使用值 workstation-123 丰富之前为空的 $udm.event.principal.hostname 字段。
4. 检测：后续规则重放会看到丰富的值 (workstation-123)，并可以触发之前错过的检测。

参考列表

规则执行始终使用参考列表的最新版本。当已安排的规则再次运行时，系统可以根据更新后的参考列表内容创建新的检测结果。这些检测结果可能会延迟显示，因为它们基于参考列表更新之前提取的数据。

如需缩短检测延迟时间，请执行以下操作：

• 在事件发生后立即将日志数据发送到 Google SecOps。
• 查看审核规则，以确定是使用不存在的数据还是使用情境丰富的数据。
• 配置较低的运行频率。

不存在规则

系统会等待至少一小时，然后再执行检查不存在的规则（例如包含 !$e 或 #e=0 的规则），以确保数据有时间到达。

数据处理延迟

即使在创建初始检测结果后，系统也可能会继续处理数据，从而可能会生成新的检测结果或更新检测结果。如需了解详情，请参阅规则重放的触发时机。

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