了解规则重放和 MTTD

支持平台：

Google SecOps SIEM

本文档介绍了规则重放 （也称为清理运行 或补全运行 ）如何处理延迟到达的数据和上下文更新，以及这些重放如何影响平均检测时间 (MTTD) 指标。

规则重放

Google Security Operations 会处理大量安全数据。为了确保依赖于上下文数据或关联数据的规则能够准确检测，规则引擎会自动运行规则重放 流程。

规则重放流程会处理以下类别的规则：

单事件规则：当 UDM 丰富流程更新之前评估过的事件时，系统会重放这些规则。如需了解有关包含数据表的规则的例外情况，请参阅本文档后面的延迟到达的数据场景。
窗口化单事件 (WSE) 规则和包含数据表的单事件规则：这些规则具有用于处理延迟到达的数据的独特调度机制，与标准单事件规则和多事件规则都不同。
多事件规则：这些规则会按时间表执行，处理事件时间块。它们会以不同的时间间隔重复重新评估同一时间块，以捕获延迟的丰富更新，例如匹配的用户或资产情境数据或失陷指标 (IOC)。确切的时间取决于时间表配置。

规则重放触发器

系统会重新评估（重新运行）规则，以确保捕获检测，即使数据在初始规则执行后到达或更新也是如此。这种延迟到达的数据包括以下类别：

延迟到达的源事件：原始日志或 UDM 事件本身到达 Google SecOps 的时间明显晚于事件的实际时间戳。
延迟到达的丰富数据：与事件相关的上下文数据（例如用户、资产、威胁情报）在系统首次处理事件后可用，或者系统会更新这些数据。这种情况通常是因为实体上下文图 (ECG)等丰富流水线会批量处理数据或依赖于外部数据源。
追溯性 UDM 丰富更新：延迟到达的源数据（例如更新主机名的 DHCP 记录）会触发对 UDM 事件字段的更改。在其检测逻辑中使用别名字段（丰富字段）（例如 $udm.event.principal.hostname）的规则可能会在源数据延迟时触发重放。这种延迟到达会追溯性地更新这些字段值。

系统会根据规则类型和延迟数据的性质以不同的方式触发规则重放。目标是在检测及时性和数据完整性之间取得平衡。

系统如何按规则类型处理延迟到达的数据

规则类型及其配置决定了延迟到达的数据可以在哪个时间窗口内触发规则重新评估。

单事件规则（不含匹配窗口或数据表）：
- 延迟的源事件：无论事件的时间戳在到达系统时有多旧，这些规则通常都会处理事件。系统不会对延迟的源事件的初始处理施加严格的截止窗口。
- 延迟的丰富：如果之前评估过的事件的丰富数据到达或发生更新，系统会根据具有新上下文的事件重新评估这些单事件规则。这种情况可能会在初始事件发生后数小时甚至数天发生。
窗口化单事件 (WSE) 规则和包含数据表的单事件规则：
- 这些规则不遵循与其他单事件规则相同的延迟数据处理方式，也不遵循多事件规则的补全时间表。
- 它们具有以下行为：
  - 截止：这些规则不会处理在事件时间戳后 7 天或更长时间提取的事件。
  - 延迟到达的数据（<7 天）：系统会处理延迟到达时间少于 7 天的事件，但延迟时间可能会更长。
  - 延迟到达的源事件：如果数据在事件时间戳后 7 天或更长时间到达 Google SecOps，WSE 规则将不会处理这些事件。
  - 上下文更新：如果事件的上下文延迟到达，或者事件被追溯性地丰富，系统会自动根据丰富后的事件重新评估规则。即使初始评估未产生检测，此规则重放也可能会触发新的检测。
  - 延迟的丰富：如果 UDM 事件因丰富而更新（这可能会在提取后 7 天内发生），系统会根据更新后的事件重新评估这些规则。但是，与其他规则类型不同，对数据表内容的更新不会触发系统自动重新评估这些规则的过往事件。
  - 回溯期：这些规则使用大约 7 天的回溯期来重新评估事件。如果事件的丰富数据在此 7 天窗口内到达，系统将重新评估该规则。
多事件规则：
- 多事件规则会按时间表运行，并重新评估时间块以考虑延迟数据。规则的时间表决定了有效的截止窗口：
  - 主要运行：系统会在事件时间加上任何配置的结算延迟时间（例如 T + 1 小时）运行首次评估。
  - 补全运行 1：系统会在主要运行后大约 4 小时运行首次补全运行。这样，系统就可以包含延迟到达的事件。
  - 补全运行 2（条件性）：如果您开启了确保丰富完整性，系统会在主要运行后大约 30 小时运行最终补全运行。这会将系统处理延迟到达的数据和上下文丰富的时间窗口延长至大约 30 小时。
  - 截止影响：最终补全运行决定了包含延迟数据的有效截止时间。这通常发生在主要运行后大约 4 小时（如果您启用确保丰富完整性 ，则发生在主要运行后大约 30 小时）。对于给定时间窗口，在此窗口的最终补全运行之后到达的事件或丰富将不会被此规则处理。
注意：这些窗口是典型的，但各种系统因素和处理延迟可能会影响确切的时间。这些时间仅供参考。如需详细了解运行时间表，请参阅了解规则运行调度和为规则配置自定义时间表。

延迟到达的数据场景示例

场景 1：延迟的源事件 - 单事件规则
- Google SecOps 会提取时间戳为 3 天前的事件。标准单事件规则会将此事件作为新数据进行处理。
场景 2：延迟的丰富 - 单事件规则
- 系统昨天处理了一个登录事件。今天，系统会提取并丰富相关用户的新信息（例如部门变更）。系统会根据具有更新后的用户上下文的登录事件重新评估单事件规则。
场景 3：延迟的源事件 - 多事件规则（默认 4 小时补全）
- 对于使用默认设置调度的多事件规则，事件会在其事件时间戳后 3 小时到达。该事件错过了初始主要运行（T + 1 小时），但系统会在 4 小时补全运行期间处理该事件。
场景 4：延迟的源事件 - 多事件规则（不含丰富完整性）
- 您配置了一个主要运行偏移时间为 1 小时的多事件规则，但未启用确保丰富完整性 。事件会在其时间戳后 6 小时到达。
- 此事件错过了主要运行（T + 1 小时）和首次补全运行（T + 4 小时）。系统不会在该时间窗口内处理此事件，因为它是在最终补全运行之后到达的。
场景 5：延迟的丰富 - 多事件规则（含丰富完整性）
- 多事件规则的偏移时间为 1 小时，并且您启用了确保丰富完整性 。事件的丰富数据会在事件时间戳后 28 小时到达。
- 系统会在大约 T + 31 小时的第二次补全运行期间使用此延迟的丰富重新评估规则。
场景 6：延迟的源事件 - 包含匹配窗口的多事件规则
- 多事件规则的 match 窗口为 48 小时，并且时间表启用了确保丰富完整性 （最终补全大约在 T + 30 小时）。事件会在其时间戳后 36 小时到达。即使事件时间在规则相对于其他事件的匹配窗口内，此事件也不会被处理，因为它是在最终补全运行之后到达的。截止时间基于相对于补全时间表的到达时间，而不仅仅是匹配窗口。
场景 7：延迟的源事件 - 窗口化单事件规则
- 如果时间戳为 8 天前的源事件延迟到达，它可能会超出 WSE 规则的 7 天回溯期，并且可能不会被处理。

对时间指标的影响

当检测结果来自规则重放时，系统会使用以下术语：

提醒的检测窗口 或事件时间戳 是指原始恶意活动的时间。
创建时间 是指系统创建检测的时间，该时间可能会晚很多，有时会晚数小时或数天。
检测延迟时间 是指事件时间戳 与检测的创建时间 之间的时差。

时间轴增量和 MTTD

初始事件时间戳与检测创建之间经过的时间直接影响 MTTD 计算。

流水线 / 时间表阶段	评估时间	对 MTTD 衡量的影响
单事件规则（流式传输）	持续（到达后 <5 分钟）	实时检测代表真实的平台速度，对 MTTD 的影响最小。
多事件规则（主要运行）	到达后 1 到 2 小时（加上配置的结算延迟时间）	包括聚合多事件关联状态所需的不可避免的批量缓冲窗口。
多事件规则（补全运行）	主要运行后 4 小时或 30 小时	包含延迟丰富数据的辅助（重放）运行会导致此时间相对于事件时间戳显示较晚或延迟。此增量会对 MTTD 计算产生负面影响。

衡量 MTTD 的最佳实践

MTTD 用于量化从初始破坏到有效检测到威胁的时间。当您分析由规则重放触发的检测时，请应用以下最佳实践来保持准确的 MTTD 指标。

Google SecOps 提供了多个用户可查询的指标，以便准确衡量 MTTD。如需详细了解这些指标，请参阅信息中心页面的 YARA-L 2.0 查询示例。

图标在 检测类型 列中用于标识由延迟到达时间超过 30 分钟的事件数据、自动补全运行、重新处理流水线或追溯性搜索生成的检测。此图标也会显示在 Google SecOps 的提醒页面上。

优先使用实时检测系统

如需获得最快的检测速度，请使用单事件规则。这些规则以“近乎实时”模式运行，通常延迟时间不到 5 分钟。这还支持更全面地使用复合检测。

考虑多事件规则中的规则重放

多事件规则由于其调度的运行频率而固有地会产生更高的延迟时间。当您衡量多事件规则的检测的 MTTD 时，请注意自动规则重放会提高覆盖率和准确性。这些重放通常会捕获需要延迟上下文的威胁，这会增加这些检测的报告延迟时间。

对于关键的、时间敏感的提醒：使用单事件规则或运行频率最短的多事件规则。缩短匹配窗口不会直接影响延迟时间，但可以通过设置最小延迟时间来提高效率。
对于复杂的、长时间的关联（UEBA、多阶段攻击）：这些规则依赖于广泛的上下文联接或引用列表，这些列表可能会异步更新。它们可能会因延迟到达的上下文数据或事件数据而出现高延迟时间，但它们的好处是提供较高保真度的检测，而不是绝对速度。

优化规则以减少对延迟丰富的依赖

为了优化检测速度并最大限度地减少追溯性丰富运行的影响，请考虑尽可能在规则逻辑中使用非别名字段 （下游丰富流水线不处理的字段）。

后续步骤

如需探索相关的调度概念和配置工作流，请参阅以下文档：

了解规则运行调度：了解 Google SecOps 如何将规则配置映射到持续流式传输和调度的批量查询引擎。
为规则配置自定义时间表：为多事件规则自定义运行频率、结算延迟时间和补全丰富完整性。
了解规则检测延迟时间：诊断和解决提取和处理流水线中预期和未预测的延迟时间。
使用规则编辑器管理规则：在 Google SecOps 中创建、修改和管理自定义检测规则。