了解规则检测延迟

支持：

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

检测规则概览

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

预期和不可预测的延迟

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

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

检测生成方法

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

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

导致规则检测延迟的因素

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

规则类型和复杂度

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

单事件规则

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

复杂的单事件规则

这些规则会评估单个事件，但会纳入额外的数据依赖性：

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

多事件规则

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

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

规则运行频率

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

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

匹配窗口时长

对于多事件规则，匹配窗口时长定义了汇总事件所需的观察期。在整个时间窗口结束之前，检测结果无法显示。

日志提取延迟

注入延迟时间是指事件在来源处发生到 Google SecOps 接收并解析日志之间经过的时间。

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

  • 示例：一条规则在 30 分钟的时间范围内关联了事件 A（事件时间为上午 9:03）和事件 B（事件时间为上午 9:05）。如果事件 A 在上午 10:05（延迟一小时）到达，则会错过上午 9:00 - 9:30 时间段的初始执行。系统会在主要运行大约 4 小时后（下午 2:00 左右）的后续校准运行期间重新评估该代码块，并在事件发生大约 5 小时后生成检测结果。

如需了解第三方 API 轮询 Feed 中的上游索引编制延迟时间，请参阅轮询 Feed 中延迟到达的事件。

时区差异

默认情况下，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) 和企业资产图表数据。由于 ECG 流水线依赖于批处理（可能需要 30 小时或长达数天，具体取决于数据量），因此引用 graph.entity 字段的规则会在图表关系完全计算后生成检测结果。

历史规则运行和 RetroHunt

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

  • 追溯性丰富工作流：
    1. 下午 1:00 收到一个事件，其 ip_address = 10.0.0.5（主机名未知）。
    2. 下午 2:30，收到一条 DHCP 日志，其中将 10.0.0.5 与 workstation-123 关联起来。
    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 专业人士的解答。