了解规则重放和 MTTD

支持的平台：

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

规则重放

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

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

  • 单事件规则：当 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 天内到达，系统将重新评估规则。

  • 多事件规则：

    • 多事件规则会按计划运行，并重新评估时间块以考虑延迟的数据。您配置规则的时间表决定了有效截止窗口：
      • 默认时间表：系统通常会在活动时间后大约 5 小时和 24 小时运行自动对账。如果数据在 24 小时运行结束后到达，则此规则不会针对相应时间窗口评估该数据。
      • 已启用可自定义的安排：借助此功能，您可以通过“运行频次”设置更好地控制运行时间。请参阅为规则配置自定义时间表。关键时间安排如下：
        • 首次运行：系统会在活动时间加上配置的偏移量（例如，T + 1 小时）时运行首次运行。
        • 首次补足运行：系统会在首次运行后大约 4 小时运行首次补足运行。这意味着系统可以包含在 T + 4-5 小时内到达的事件。
        • 补全运行 2（有条件）：如果您开启确保丰富化完整性，系统会在首次运行后大约 30 小时运行最终的补全运行。这样一来，系统处理迟到数据的时间窗口就会延长到大约 T + 30-31 小时。
      • 截止时间影响：通过自定义时间表，最后一次数据核对运行将决定纳入延迟数据的有效截止时间。这通常会在首次运行后大约 4 小时发生，如果您启用了确保丰富化完整性，则会在首次运行后大约 30 小时发生。如果事件或丰富数据在给定时间窗口的最终校正运行后到达，则相应规则不会针对该时间窗口处理这些事件或丰富数据。

延迟到达的数据场景示例

  • 场景 1：来源事件延迟 - 单事件规则

    • Google SecOps 会提取时间戳为 3 天前的事件。标准单事件规则会将此事件视为新数据进行处理。

  • 场景 2：后期丰富 - 单个事件规则

    • 系统昨天处理了一次登录事件。如今，它会提取并丰富相关用户的新信息（例如，部门变更）。系统会根据具有更新后的用户上下文的登录事件重新评估单事件规则。

  • 场景 3：来源事件较晚 - 多事件规则（默认时间表）

    • 如果某个事件在事件时间戳 10 小时后到达，系统会在 5 小时的校正运行期间错过该事件，但在 24 小时的校正运行期间会处理该事件。如果事件到达时间比预期时间晚了 25 小时，系统将不会处理该事件。

  • 方案 4：延迟的来源事件 - 多事件规则（可自定义的安排）

    • 您配置了一个多事件规则，其首次运行偏移量为 1 小时。事件会在其时间戳 6 小时后到达。
    • 此事件错过了首次运行（T + 1 小时）和首次调整运行（T + 4 小时）。除非您启用确保丰富完整性，否则系统不会根据此规则处理相应事件。

  • 场景 5：后期丰富 - 多事件规则（可自定义丰富完整度）

    • 多事件规则的偏移时间为 1 小时，并且您启用了确保丰富完整性。事件的丰富数据会在事件时间戳后的 28 小时内到达。
    • 部分此类延迟丰富的数据可能在第二次“补全运行”时可用，该运行大约在 T + 30 小时进行（因为您已开启确保丰富完整性）。如果扩充数据可用，系统会使用此后期扩充重新评估规则。

  • 场景 6：迟到的来源事件 - 包含匹配窗口的多事件规则

    • 多事件规则的回溯期为 48 小时match，并采用启用了确保丰富完整性的自定义时间表（最终的校正时间约为 T + 30 小时）。事件在时间戳 36 小时后到达。此事件不会得到处理，因为它是在最终的校正运行之后到达的，即使事件时间相对于其他事件位于规则的匹配时间范围内也是如此。截止时间取决于相对于结算时间表的到达时间，而不仅仅是匹配窗口。

  • 场景 7：迟到的源事件 - 开窗单事件规则

    • 如果时间戳为 8 天前的来源事件延迟到达，则可能会超出 WSE 规则的 7 天回溯期，因此可能不会被处理。

对时间指标的影响

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

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

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

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

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

衡量 MTTD 的最佳实践

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

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

检测类型列中的 图标表示系统根据以下数据生成的检测结果：到达时间晚于 30 分钟的事件数据、规则重新处理运行或回溯搜索。此图标也会显示在 Google SecOps 的提醒页面上。

优先考虑实时检测系统

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

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

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

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

  • 对于时间紧迫的关键提醒：请使用单事件规则或运行频率尽可能短的多事件规则。缩短匹配窗口不会直接影响延迟，但可以通过设置最小延迟来提高效率。

  • 对于复杂、长时间的相关性分析（UEBA、多阶段攻击）：这些规则依赖于广泛的上下文联接或参考列表，这些列表可能会异步更新。它们可能会因情境数据或事件数据到达较晚而出现高延迟，但它们可提供较高的检测保真度，而不是绝对的速度。

优化规则以减少对后期丰富化的依赖

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

需要更多帮助？获得社区成员和 Google SecOps 专业人士的解答。