了解规则重放和 MTTD

支持的平台：

本文档介绍了规则重放（也称为清理运行或补全运行）如何处理迟到的数据和上下文更新，以及这些重放如何影响平均检测时间 (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 小时）后运行首次评估。
      • 首次补算：系统会在主运行后大约 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 专业人士的解答。