分析规则的有效性和效率

支持的平台：

本指南面向在 Google Security Operations 中创建、部署和监控规则的安全工程师。本文介绍了如何使用 Google SecOps 实例中的数据监控规则，以确保规则按预期运行，并且不会过度消耗资源。这些数据有助于您调试延迟检测、了解延迟到达的富集数据对规则的影响，以及确定哪些规则的平均检测时间 (MTTD) 最长。

本指南提供了有关以下任务的文档：

  • 如何在规则的初始发布期间对其进行评估、接收提醒，以及查看规则信息中心以监控其健康状况。

  • 如何确定任何检测延迟的原因（例如，是否是由于提取延迟或逻辑效率低下），以及如何调整平均检测时间 (MTTD) 报告或通过添加规则排除对象来调整规则。

准备工作

如需查看和修改本文档中所述的规则，您需要成为 Chronicle API 编辑者。如需了解详情，请参阅 Google Security Operations 角色和权限。

在分析 Google SecOps 中规则的有效性之前，您应充分了解 YARA-L 语言、YARA-L 查询、如何创建和管理规则，以及如何创建信息中心：

主要术语

  • 规则：在日志数据注入到您的 Google SecOps 账号时自动识别威胁。
  • 配额：对数据注入量、可针对数据运行的查询数量和复杂程度，以及 Google SecOps 账号中处于有效状态的规则数量和复杂程度的限制。
  • 提醒和检测结果：Google SecOps 和您自己的安全基础架构发现的需要您注意的安全问题。
  • 注入：将安全数据导入 Google SecOps 并将其转换为 UDM 的过程。
  • 规则重放：如果相关情境数据在初始事件数据到达或处理之后才到达或处理，系统会自动针对现有数据重新运行规则。
  • Retrohunt：将新规则应用于现有数据，以识别之前未发现的威胁。

如何分析规则

以下部分介绍了如何分析规则的性能。

部署后测试和评估规则

首次将规则部署到正式版时，请在 Rule Observability 信息中心内监控 24 到 48 小时：

  1. 前往信息中心

  2. 搜索 Rule Observability。

  3. 在规则列中搜索新规则。规则可观测性信息中心包含检测次数、提取延迟时间和从提取到检测的时间等统计信息。

为确保规则逻辑在开始生成高优先级提醒之前不会引入人为延迟，您可以使用检测的架构参考。该架构定义了用于监控安全提醒的结构化格式。它经过优化，可用于跟踪检测频率、风险分布和规则性能。您可以仔细查看查询示例，以便更好地了解如何使用架构。

确定规则结果延迟的原因

请完成以下步骤，确定规则结果是否延迟，如果延迟，请确定原因：

  1. 依次前往检测 > 提醒和 IOC。
  2. 在提醒标签页上，找到检测类型列。
  3. 搜索带有黄色灯泡图标的提醒。
  4. 将鼠标悬停在该图标上，查看检测是否由以下任一情况触发：
    • 规则重新处理：由用户手动触发。
    • Retrohunt：由用户手动触发。
    • 延迟的事件数据：表示是否预计会出现检测延迟。

根据检测时间过滤提醒

  1. 依次前往检测 > 提醒和 IOC。

  2. 在提醒标签页上，使用检测时间列的过滤元素，根据检测的到达时间对检测进行排序。

  3. 点击表格顶部的刷新图标 ，然后点击立即刷新。您可以查看 Google SecOps 账号中收到的最新提醒，以及与每条提醒关联的规则（查看规则名称列）。

检查元数据

如需进一步了解规则的执行情况，您可以使用 latencyMetrics 检查原始检测 JSON，以找出 oldestEventTime 和 oldestIngestionTime 之间的差异。

检测时间值

下表列出了与 DetectionTimingDetails 关联的枚举值：


值
说明
MTTD 影响

UNSPECIFIED


在标准调度窗口内创建的检测。
MTTD 的标准答案。

REPROCESSING


因规则重放（例如，数据延迟到达）而生成。
表示运营风险；应在报告中说明。

RETROHUNT


通过历史回溯搜索运行生成。
通常从标准 MTTD 报告中滤除。

示例：latencyMetrics 元数据

以下 latencyMetrics 示例显示了事件发生时间（oldestEventTime 与 newestEventTime）与事件被提取时间（oldestIngestionTime 与 newestIngestionTime）之间的时间差。事件与提取到 Google SecOps 账号之间存在大约 53 分钟的延迟时间。

"detectionTimingDetails": ["DETECTION_TIMING_DETAILS_REPROCESSING"],
"latencyMetrics": {
  "oldestIngestionTime": "2025-12-09T16:54:14Z",
  "newestIngestionTime": "2025-12-09T16:54:14Z",
  "oldestEventTime": "2025-12-09T16:01:06Z",
  "newestEventTime": "2025-12-09T16:01:06Z"
}

问题排查

下表列出了您可能会遇到的与规则相关的一些问题以及解决方法：


问题
分辨率

显示灯泡图标，但枚举为 UNSPECIFIED.
当事件时间和提取时间之间的差值超过 30 分钟时，这是正常行为。使用数据健康状况中心指标来调查注入延迟的来源。

检测结果相对于事件发生时间显示较晚。
检查 detectionTimingDetails。如果枚举值为 REPROCESSING，则延迟很可能是由于富集数据到达较晚，而不是规则执行延迟。如果为 UNSPECIFIED，请调查规则逻辑的效率。

过多的计算。
相应规则可能扫描了过多的数据，或者逻辑效率低下。前往规则排除项，或使用过滤条件分流来调整规则，以缩小其数据搜索范围。

已知限制

  • 阈值僵化：延迟数据的视觉提示固定为 30 分钟的阈值，不考虑用户定义的延迟时间窗口。
  • 数据健康状况：规则可观测性可反映规则健康状况，但数据健康状况监控（更接近数据提取）可更有效地发现一般性的迟到数据问题。
  • 配额强制执行：虽然信息中心会显示资源使用情况，但当规则接近配额限制时，它不会提供实时通知。

后续步骤

如需了解规则重放和规则检测延迟，请参阅以下内容：

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