了解规则检测延迟

支持的平台：

本文档解释了 Google Security Operations 中的规则检测延迟，指出了注入和处理流水线中的影响因素，概述了结构化的问题排查方法，并提供了减少检测延迟时间的技术。

检测规则概览

检测规则会检查规范化的原始日志（包括常规日志和实体通用数据模型 (UDM) 事件），以根据规则规范生成安全检测结果。实体 UDM 事件通常包含上下文信息，例如用户或资产元数据。检测规则还可以评估之前生成的检测结果，以生成复合提醒。

预期延迟和未预测到的延迟

检测延迟时间因规则逻辑、数据依赖关系和系统处理周期而异。延迟分为两类：

  • 预期延迟：由结构性因素（例如注入过程、规则类型、运行频率、检测生成方法、匹配窗口时长和已知系统限制）导致的延迟。您可以通过调整检测规则配置和调度参数来最大限度地减少预期延迟。
  • 不可预测的延迟：由外部或动态管道条件引起的延迟，包括来自数据源的日志交付瓶颈、Google SecOps 服务中的瞬态处理延迟、上下文可用性延迟以及 UDM 重新丰富周期。

检测生成方法

Google SecOps 通过以下执行流水线生成规则检测结果：

  • 流式引擎：高速管道，可在接近实时的时间内（通常在摄取后 5 分钟内）连续评估标准和窗口化的单事件规则。在标准执行期间，系统会持续评估迟到的事件和追溯性丰富化。
  • 查询引擎：评估需要跨多个事件进行基于时间的事件关联的规则或外部数据连接：
    • 复杂的单事件规则：包括查询参考列表或数据表的单事件规则。
    • 多事件规则：根据配置的安排，以批处理方式查询事件时间块（例如 10 分钟或 1 小时间隔，或超过 48 小时的窗口的 match_window / 10）中的数据。
  • 针对历史数据运行规则：通过 Retrohunt 针对历史日志追溯性地评估规则。历史扫描完成后，检测结果才会出现。
  • 重新丰富 UDM 事件：当向历史事件添加新情境或更新实体数据时，重新评估之前处理的时间块。

导致规则检测延迟的因素

检测结果的显示速度取决于规则复杂程度、调度间隔、数据注入延迟时间和上下文丰富流水线。

规则类型和复杂程度

检测规则分为多个类别，具有不同的延迟时间特征：

单事件规则

单事件规则在连续流式传输引擎上近乎实时地执行，可实现最低的检测延迟时间。这些规则会评估单个事件，而不会联接外部数据集、数据表或多事件匹配窗口。

复杂的单事件规则

这些规则评估单个事件，但同时也考虑了额外的数据依赖关系：

  • 包含时间窗口的单事件规则：包含 match 部分的单事件规则（例如，评估单个事件是否在某个时间窗口内满足条件）。这些规则会在数据注入时在连续流式传输引擎上以近乎实时的方式进行评估。
  • 参考单事件规则：将事件属性与参考列表或数据表进行比较的单事件规则。

多事件规则

多事件规则可在指定的匹配时间范围内关联两个或更多 UDM 事件条件，并按预定的批处理间隔执行。

  • 标准多事件规则：汇总多个时间窗口内的多个事件，并以 10 分钟或 1 小时为间隔执行（对于超过 48 小时的窗口，则以 match_window / 10 为间隔执行）。
  • 情境感知规则：使用情境感知分析将事件数据与 UDM 实体事件（例如 user_context 或 asset_context）相关联。由于上下文感知规则依赖于多个数据源，因此它们对数据摄取时间更为敏感。如需了解详情，请参阅在规则中使用包含丰富情境的数据。

规则运行频率

配置的执行频率决定了查询引擎评估事件时间块的频率：

  • 近乎实时：持续评估单事件规则（标准和窗口化）。
  • 10 分钟的频次：适用于匹配时间范围小于 60 分钟的多事件规则。
  • 1 小时频率：匹配窗口期为 48 小时或更短的多事件规则的默认间隔。
  • match_window / 10 频次：对于匹配窗口超过 48 小时的多事件规则，系统会自动分配频次（例如，对于 100 小时的匹配窗口，每 10 小时运行一次；对于 10 天的匹配窗口，每 24 小时运行一次）。

匹配窗口时长

对于多事件规则，匹配窗口时长定义了汇总事件所需的观测时间段。只有在整个时间窗口结束后，系统才能显示检测结果。

日志提取延迟

提取延迟是指从源中发生事件到 Google SecOps 接收并解析日志之间所经过的时间。

如果某个事件在相应时间段的初始预定评估时间之后到达，则会错过首次运行。该系统在后续的自动后台运行（校正运行）中捕获迟到的数据，这些运行大约在主运行后 4 小时（如果富集完成，则可选择 30 小时）进行。

  • 示例：某规则将事件 A（事件时间为上午 9:03）和事件 B（事件时间为上午 9:05）在 30 分钟的时间窗口内相关联。如果事件 A 在上午 10:05 到达（晚了一个小时），则会错过 9:00-9:30 时间段的初始执行。系统会在主运行后大约 4 小时（下午 2 点左右）的后续对账运行期间重新评估该屏蔽，并在事件发生后大约 5 小时生成检测结果。

时区差异

Google SecOps 默认将日志时间戳解读为世界协调时间 (UTC)。如果日志源省略了明确的时区偏移量，系统会将时间戳视为 UTC，这可能会导致日志看起来是延迟到达的，即使是立即收到的也是如此。

  • 示例：某个事件发生在美国东部时间上午 10:00（世界协调时间 15:00），并在世界协调时间 15:05 到达 Google SecOps，但没有时区元数据。系统将时间戳解释为 UTC 时间 10:00，造成 5 小时的感知摄入延迟，从而将规则评估推迟到后台校准运行。

解决方法：如需解决时区差异问题，请执行以下操作：

  • 配置日志源，以在事件时间戳中明确包含世界协调时间 (UTC) 时区偏移量。
  • 请与支持团队联系，为特定提取 Feed 设置时区替换。
  • 使用 BindPlane 处理器在提取之前将日志正文时间戳标准化为 UTC。如需了解详情，请参阅使用 BindPlane 修改日志正文时间戳。

情境联接和数据丰富化

Google SecOps 通过从次要来源添加身份、资产和威胁元数据来丰富 UDM 事件。上下文可用性延迟可能会延长检测时间。

别名和丰富情报机制

别名和丰富功能可将原始指标与组织背景信息相关联：

  • 别名：识别并链接同一实体在不同数据源中的不同标识符（例如，将 DHCP 日志中的 IP 地址映射到 MAC 地址和主机名，如 alex-macbook，或将用户 ID 映射到员工职位）。
  • 丰富：使用别名化上下文填充归一化的 UDM 事件字段（例如，当原始事件中仅存在 IP 地址时，填充 $udm.event.principal.hostname）。

支持的信息丰富类型包括资产、用户、进程、文件哈希元数据、地理位置和云资源。如需了解详情，请参阅 UDM 扩充和别名设置概览。

UDM 活动的再丰富化

随着上下文来源的演变，系统会不断更新历史事件：

  • 基础数据发生变化：在提取历史事件后，如果收到新的情境数据，则可以在最多 24 小时内更新这些事件。
  • 富集系统更新：当实体元数据、IP 地理定位或 VirusTotal 威胁情报更新时，规则引擎会重新评估历史封锁（通常在计划的校正运行或重新处理期间），以生成具有更新后上下文的检测结果。
  • 延迟的情境数据：如果情境数据（例如主机名）在事件日志生成一天后才到达，系统会重新丰富 UDM 事件，后续的校正运行会评估丰富后的记录。
  • 上下文修改：如果富集更新更改了事件属性（例如将 IP 地理定位从 USA 更新为 Canada），则与更新后的值匹配的规则会在后续重新评估期间触发检测。

实体上下文图 (ECG) 处理

实体上下文图（ECG）关联入侵指标（IOC）和企业资产图数据。由于心电图流水线依赖于批处理（根据数据量，可能需要 30 小时或长达数天），因此引用 graph.entity 字段的规则会在图关系完全计算完毕后生成检测结果。

历史规则运行和 RetroHunt

针对历史数据运行规则时，只有在 Retrohunt 扫描完成所选时间范围内的所有数据后，才会生成检测结果。

  • 追溯性丰富化工作流程：
    1. 下午 1:00，系统收到一个事件，其主机名为 ip_address = 10.0.0.5（未知）。
    2. 下午 2:30，系统收到一条将 10.0.0.5 关联到 workstation-123 的 DHCP 日志。
    3. 别名流水线会使用 principal.hostname = workstation-123 更新历史记录中的下午 1:00 事件。
    4. 后续规则重放会评估在初始运行期间未触发的增强型主机名和表面检测结果。

参考列表

在执行时，查询参考列表的规则会根据最新的列表版本进行评估。更新参考列表可能会导致已安排的规则针对之前提取的日志追溯性地生成检测结果。

不存在规则

为防止误报，系统在评估检查 不存在条件（例如 !$e 或 #e=0）的规则之前，引入至少一个小时的缓冲时间，以确保所有相关日志都有时间到达。

数据处理和调整限制

评估检测延迟时间时，请注意以下系统行为：

  • 丰富处理：上下文丰富功能可以在初始提取后最多 24 小时内更新历史 UDM 事件。
  • 补全周期：多事件规则会在初次运行后大约 4 小时（也可选择 30 小时）自动重新执行，以捕获延迟到达的数据。如需了解详情，请参阅了解规则重放和 MTTD。
  • 检测限制：如需了解平台容量和节流边界，请参阅了解检测限制。

排查规则检测延迟问题

如需诊断规则为何生成了延迟检测结果，请在 Google SecOps 控制台中检查以下启发式分析和流水线阶段：

  • 查看规则元数据和时间安排：在规则信息中心内，查看规则名称、规则类型和规则时间安排列，以确定规则的执行引擎和基准评估频率。
  • 将事件时间与提取时间进行比较：在检测结果标签页上找到检测结果，然后将事件时间戳与提取时间戳进行比较。如果事件时间与提取时间之间的差距超过 30 分钟，则延迟是由源处的日志传送延迟或收集期间的延迟造成的。如果检测结果是根据以下数据生成的，则检测类型列中会显示 图标：到达时间晚于 30 分钟的事件数据、自动校正运行、重新处理流水线或回溯式搜索。
  • 查看上下文来源依赖项：检查规则是否引用了 principal 扩充、UDM 别名或 graph.entity 字段。上下文流水线以异步方式处理，可能会在后续的校正运行期间显示检测结果。
  • 验证频次和匹配时间范围的兼容性：确认配置的运行频次与匹配时间范围大小一致（例如，确保将匹配时间范围为 15 分钟的规则安排为每 10 分钟或每 1 小时运行一次）。
  • 检查是否存在数据 Feed 中断：查看提取日志和 Feed 管理信息中心，了解是否存在提取延迟或短暂的来源中断。

缩短检测延迟时间的提示

为了最大限度地减少整个环境中的检测延迟，请应用以下优化技巧：

  • 优化规则运行频次：
    • 对于单事件规则（标准和窗口化），请使用近乎实时。
    • 为匹配窗口小于 60 分钟的多事件规则配置 10 分钟的时间表。
    • 对于匹配时间范围介于 1 到 48 小时之间且需要快速提醒的规则，请使用1 小时。
  • 调整匹配窗口时长：将匹配窗口设置为捕获相关威胁行为所需的最低时长。
  • 消除日志传送瓶颈：确保转发器和收集器立即发送事件数据，以防止日志错过初始执行窗口。
  • 验证时区配置：确保日志源提供明确的 UTC 偏移量，以防止出现 5 小时以上的感知提取延迟。
  • 审核上下文和不存在条件：仅在检测逻辑需要时才使用上下文丰富字段和不存在条件 (!$e)，因为这些字段和条件会引入有意设置的缓冲期。

后续步骤

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

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