了解规则检测延迟
本文档介绍了 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 小时生成检测结果。
时区差异
Google SecOps 默认将日志时间戳解读为 UTC。如果日志源省略了明确的时区偏移量，系统会将时间戳视为 UTC，这可能会导致日志看起来是延迟到达的，即使是立即收到的也是如此。
- 示例：某个事件于美国东部时间上午 10:00（世界协调时间 [UTC] 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:00，系统收到一个包含
ip_address = 10.0.0.5（主机名未知）的事件。 - 下午 2:30，系统收到一条将
10.0.0.5关联到workstation-123的 DHCP 日志。 - 别名化流水线会使用
principal.hostname = workstation-123更新历史记录中的下午 1:00 事件。 - 后续的规则重放会评估经过丰富的主机名，并显示在初始运行期间未触发的检测结果。
- 下午 1:00，系统收到一个包含
参考列表
在执行时，引用列表的查询规则会根据最新的列表版本进行评估。更新参考列表可能会导致已安排的规则针对之前提取的日志追溯性地生成检测结果。
不存在规则
为防止出现误报，系统在评估检查不存在条件（例如 !$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 如何将规则配置映射到持续流式传输和预定批处理查询引擎。
- 为规则配置自定义时间表：为多事件规则自定义运行频率、结算延迟时间和补差丰富完整性。
- 了解规则重放和 MTTD：了解自动化补全运行如何处理迟到的数据和上下文更新，从而影响平均检测时间 (MTTD) 指标。
- 使用规则编辑器管理规则：在 Google SecOps 中创建、修改和管理自定义检测规则。
需要更多帮助？获得社区成员和 Google SecOps 专业人士的解答。