了解规则重放和 MTTD

支持的平台：

Google SecOps SIEM

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

规则重放

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

规则重放流程会处理以下两类不同的规则：

单事件规则：当 UDM 丰富化流程更新之前评估过的事件时，系统会重新执行单事件规则。
多事件规则：多事件规则会按照您选择的时间表执行，并处理事件时间块。这些规则会在不同时间间隔内反复重新评估同一时间段，以捕获后期丰富更新，例如匹配用户或资产情境数据或失陷指标 (IOC)。
例如，规则可能会至少运行两次或三次（在 5-8 小时后运行一次，然后在 24-48 小时后再次运行），以考虑延迟到达的事件和情境数据。

当相关情境数据到达时，或者当情境数据的处理时间晚于初始事件数据时，系统会重新评估（重新运行）规则。

重放的常见原因包括：

延迟到达的丰富数据：数据丰富流水线（例如实体上下文图 [ECG]）通常会批量处理数据。如果 UDM 事件在其相关背景数据（例如资产信息或用户背景信息）到达之前到达，则初始规则执行可能会漏掉检测。
追溯性 UDM 丰富更新：如果规则在其检测逻辑中使用别名字段（丰富字段）（例如 $udm.event.principal.hostname），则当源数据（例如 DHCP 记录）延迟时，可能会触发重放。这种延迟到达会追溯性地更新这些字段值。后续的规则重放会使用这些新丰富的值，从而可能会触发之前漏掉的检测。

如果检测结果是规则重放的结果，我们会使用以下术语：

由于数据延迟到达而导致的重新丰富，或上下文来源更新（例如实体上下文图 [ECG]）的延迟通常会导致检测延迟时间较长。

这种时间差可能会导致检测结果看起来“过晚”或“延迟”，从而让分析师感到困惑，并扭曲 MTTD 等效果指标。

指标组件	时间来源	重放对 MTTD 有何影响
检测窗口 / 事件时间戳	原始安全事件发生的时间。	这与活动时间保持一致。
检测时间 / 创建时间	检测结果实际由引擎发出时的时间。	相对于事件时间戳，此时间会显得“较晚”或“延迟”，因为它依赖于纳入了延迟丰富数据的二次（重放）运行。此差值会对 MTTD 计算产生负面影响。

衡量 MTTD 的最佳实践

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

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

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

如需实现最快速的检测，请使用单事件规则。这些规则以近乎实时的方式运行，延迟时间通常不到 5 分钟。

这也有助于更全面地使用复合检测。

多事件规则的运行频率是预先设定的，因此它们本身就会产生更高的延迟时间。在衡量多事件规则检测的 MTTD 时，请注意自动规则重放会提高覆盖率和准确性。这些重放通常会捕获需要后期上下文的威胁，从而增加这些检测的报告延迟时间。

对于时间紧迫的关键提醒：请使用单事件规则或运行频率尽可能短的多事件规则。缩短匹配窗口不会直接影响延迟时间，但可以通过设置最短延迟时间来提高效率。
对于复杂、长时间的相关性分析（UEBA、多阶段攻击）：这些规则依赖于广泛的上下文联接或参考列表，这些列表可能会异步更新。它们在处理延迟到达的情境数据或事件数据时可能会遇到高延迟，但它们的好处是能够以更高的保真度进行检测，而不是绝对的速度。

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