了解规则检测延迟

支持的平台：

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 等维度可作为启发式方法，帮助您了解特定检测可能延迟的原因。

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

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

检测生成方法

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

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

1. Streaming Engine

   Streaming Engine 是一种快速流水线，通常以不到 5 分钟的延迟运行。它处理不含匹配部分且不含外部数据集（例如参考列表或数据表）的单事件规则。

2. 查询引擎

   查询引擎按如下方式处理规则：

   • 复杂的单事件规则：

     • 引用参考列表或数据表的单事件规则。
     • 使用包含简单条件的匹配窗口的窗口化单事件规则。例如，“事件数大于 0 的事件”。 这些规则以高频（实时）查询速率运行，因为新数据会被提取并可用于规则处理。

   • 多事件规则：这些规则会根据您设置的安排，在事件时间（10 分钟、每小时、每天）块内查询数据。
     例如，对于 10 分钟的安排，规则会在 5 到 8 小时后以及 24 到 48 小时后重新查询事件时间块，具体时间取决于上游处理时间表。

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

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

4. 重新丰富 UDM 事件

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

已知限制

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

• 富集延迟有时可能比预期时间要长。丰富功能重新处理会导致后续规则运行重新评估数据。系统会多次运行富集，最后一次运行发生在事件时间三天后。
• 多事件规则通常会联接在主要事件的事件时间之后数小时到达的情境数据。此类情境数据中的高延迟可能会导致重新丰富处理和规则重放相互作用，从而导致检测延迟。虽然 Google SecOps 使用此功能来处理极晚到达的数据，但检测窗口（事件时间块）与提醒的创建时间之间的时间跨度会显得非常大。
• 情境感知规则是指依赖于丰富来源（例如资产和身份别名或实体上下文图）的规则。由于这些规则依赖于多个事件来源，因此更容易受到延迟的影响。
• 系统会在首次执行规则后的 5 到 8 小时内重新执行规则，并在 24 到 48 小时内再次重新执行规则。这两个单独的规则重放会根据重新处理流水线的执行时间发生。

排查规则检测延迟问题

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

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

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

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

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

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

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

      例如，对于特定的规则检测，如果 Event time 和 Ingested time 之间存在较大差距，您很可能可以将检测延迟归因于预期延迟。

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

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

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

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

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

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

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

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

   • 频率：检查规则的运行频率。如果规则配置为以较低的频率运行，自然会产生更长的检测延迟。
   • 匹配窗口：如果规则具有匹配窗口，则最短延迟时间为该窗口的持续时间。
   • 频次与匹配范围的关系：确保运行频次与匹配范围兼容。例如，如果匹配窗口为 5 分钟，则 10 分钟的运行频率是可以接受的。不过，如果匹配窗口超过 10 分钟，请使用下一个可用的运行频率（1 小时）。

4. 查看近期事件：

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

缩短延迟的技巧

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

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

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

  • 提高规则执行频率：

    为减少延迟，请根据规则类型和匹配时间范围配置尽可能高的频次：

    • 对于单事件规则：请使用近乎实时。
    • 对于匹配窗口小于 60 分钟的多事件规则：使用 10 分钟。
    • 对于匹配窗口期为 60 分钟或更长时间的规则：请根据需要使用 1 小时或 24 小时。

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

  • 缩短匹配窗口时长：

    较小的匹配窗口效率更高。将 60 分钟的匹配时间窗口更改为 59 分钟，以启用 10 分钟处理。

• 避免出现迟到的数据：

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

导致规则检测延迟的因素

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

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

规则类型

• 单事件规则：

  由于单事件规则采用流式处理方法，因此可以近乎实时地执行，请尽可能使用它们来最大限度地减少延迟。

  • 简单的单事件规则

    这些规则可检测单个事件，不使用参考列表、数据表、匹配窗口或用户和实体行为分析 (UEBA)。这些规则以流式方式近乎实时地执行，检测延迟最短。

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

  • 复杂的单事件规则

    • 窗口单事件规则

      这些是包含匹配时间窗口的单事件规则，通常比其他单事件规则的延迟时间稍长。匹配窗口通常是指规则检查一个或多个事件的时间段。

    • 参考单事件规则

      这些是包含参考列表或数据表的单事件规则。

• 多事件规则：

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

  • 多事件规则

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

  • 情境感知规则

    情境感知规则可帮助您了解遥测中的行为模式以及这些模式中受影响实体的情境。

    • 这些规则包含两个或更多条件，但至少有一个条件是 UDM 实体事件（其中 UDM 事件的类型为 context，例如 user_context）。
    • 这些类型的规则的延迟时间较长，检测结果通常需要几天才能生成。
    • 情境感知规则通常延迟时间最长，因为系统必须先生成必要的上下文数据。

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

规则运行频率

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

• 近乎实时：规则会更频繁地针对实时数据执行，并持续运行。此设置仅适用于单事件规则。
• 其他频次：对于其他规则类型，您可以设置以下频次：
  • 10 分钟的频次适用于时长不足 60 分钟的比赛窗口。
  • 1 小时和 24 小时的频次适用于匹配窗口期不足 48 小时的规则。
  • 24 小时频次适用于所有匹配时间范围（大于或等于 48 小时）。

可能的解决方法：如需更快地检测到匹配项，请使用较短的运行频率和较小的匹配窗口。使用较短的匹配窗口期（不到 1 小时）可提高运行频率。

匹配窗口

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

提取延迟

注入延迟是指 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（世界协调时间 [UTC] 下午 3:00），到达时间为 UTC 下午 3:05，但缺少时区信息。如果日志缺少时区，系统会将事件时间解读为 10:00 UTC。然后，系统会计算出解读后的事件时间（世界协调时间 10:00）与实际提取时间（世界协调时间 15:05）之间存在 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 专业人士的解答。