监控规则性能

支持平台：

本指南面向在 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. 在规则 列中搜索新规则。Rule Observability 信息中心包含检测计数、注入延迟时间和从注入到检测的时间等统计信息。

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

确定规则结果延迟的原因

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

  1. 前往检测 > 提醒和 IOC。
  2. 在提醒 标签页上，找到检测类型 列。
  3. 搜索带有黄色灯泡图标的提醒。
  4. 将鼠标悬停在该图标上，查看检测是否由以下任一原因触发：
    • 规则重新处理：由于规则重放而生成
    • Retrohunt：由用户手动触发。
    • 延迟的事件数据：由于规则重放（具体是因为数据延迟到达）而生成。

如需详细了解因规则重新处理而创建的检测，请参阅规则重放。

根据检测时间过滤提醒

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

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

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

检查元数据

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

检测时间值

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


值
说明
MTTD 影响

UNSPECIFIED


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

REPROCESSING


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

RETROHUNT


通过历史 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 专业人士的解答。