此页面由 Cloud Translation API 翻译。

了解规则重放和 MTTD

支持的平台：

Google SecOps SIEM

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

规则重放

Google SecOps 可处理大量安全数据。为了确保依赖于关联数据或上下文数据的规则能够准确检测，规则引擎会自动运行规则重放流程。此过程会在不同时间间隔多次评估同一块事件数据，以处理延迟到达的数据或需要更新上下文的规则，例如匹配入侵指标 (IOC)。

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

常见的规则重放触发器包括：

延迟到达的丰富数据

数据扩充流水线（例如实体上下文图 [ECG]）可能会批量处理数据。如果 UDM 事件在其相关情境数据（例如资产信息或用户情境）到达之前到达，则在初始规则执行期间可能会漏检。
追溯性 UDM 丰富化更新

如果您的规则在检测逻辑中使用别名化字段（丰富字段）（例如 $udm.event.principal.hostname），并且源数据（例如 DHCP 记录）在一个多小时后才到达，则这些字段值会针对该特定事件时间进行追溯更新。后续的规则执行（“清理运行”）会使用这些新丰富的值，这可能会触发之前错过的检测。
预设多事件规则

多事件 (ME) 规则会按计划（例如每 10 分钟、每小时或每天）运行，以评估事件时间块。为了捕获对历史数据的后期丰富更新，这些规则会在稍后重新评估同一时间段，通常至少运行两次或三次（例如，在 5-8 小时后进行检查，然后在 24-48 小时后再次进行检查）。

如果检测结果来自规则重放，则提醒的检测窗口或事件时间戳是指原始恶意活动发生的时间。创建时间是指检测创建的时间，该时间可能会晚得多，有时会晚数小时或数天。

检测延迟时间较长（事件与检测之间的时间差较大）通常是由延迟到达的数据的重新丰富或实体上下文图 (ECG) 流水线中的延迟造成的。

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

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

衡量 MTTD 的最佳实践

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

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

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

多事件规则因其预定的执行频率而固有地会产生更高的延迟时间。在衡量多事件规则生成的检测的 MTTD 时，务必要认识到，自动规则重放产生的检测有助于提高覆盖率和准确性。虽然这些重放通常可以捕获需要后期上下文的威胁，但必然会增加相应检测的报告延迟时间。

对于需要及时发出提醒的关键事件：请使用单事件规则或运行频率尽可能短的多事件规则（例如，匹配时间窗口较短，不到 1 小时）。
对于复杂、长时间的相关性分析（UEBA、多阶段攻击）：如果规则依赖于可能会异步更新的广泛的上下文联接或参考列表，则预计延迟时间会更长（最长可达 48 小时或更长时间）。此处的优势在于检测保真度更高，而非绝对速度。

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