2. 检测工程生命周期

检测工程不是“写一条规则然后上线”这么简单。一条检测规则从想法到退役，会经历需求获取、设计、开发、测试、部署、度量与退役七个阶段。每个阶段都有明确的输入、输出和判断标准，任何一个环节缺失，都会导致规则在生产环境中失效、误报泛滥或无人维护。本节将完整拆解这条生命周期，并给出可落地的操作细节。

需求获取：从威胁和业务出发

需求获取是生命周期的起点，目标是回答“我们要检测什么、为什么现在要检测”。需求通常来自四个渠道：威胁情报（如某APT组织近期使用的新TTP）、事件复盘（如上次应急中暴露的检测盲区）、合规要求（如等保或行业规范明确要求记录的日志类型）、以及红队演练中未被发现的攻击路径。

以“检测Kerberoasting攻击”为例，需求描述应包含：攻击者通过请求服务票据（TGS）并离线破解服务账户密码。检测目标是在域控安全日志中识别异常的TGS请求。需求获取阶段需要明确：数据源是否可用（Windows安全事件ID 4769）、日志是否已接入SIEM、服务账户的基线行为是什么。如果数据源缺失，需求应被标记为“阻塞”，先推动日志接入，而不是直接进入设计阶段。

设计：把需求翻译成可执行的检测逻辑

设计阶段的核心是选择检测方法并定义逻辑边界。常见的检测方法包括：签名匹配（如已知恶意哈希）、行为基线（如某进程首次出现）、关联规则（如多个事件在时间窗口内组合）、以及异常统计（如登录失败次数突增）。

继续以Kerberoasting为例，设计阶段需要确定：使用事件ID 4769，过滤掉机器账户和krbtgt，关注加密类型为RC4（0x17）的请求，并统计同一账户在5分钟内请求不同服务票据的数量。这里的关键参数是时间窗口和阈值。假设正常业务中，一个用户5分钟内最多请求3个不同服务，那么阈值可设为5。设计文档应记录这些假设，并注明“阈值需在测试阶段用真实数据校准”。

设计阶段还要定义误报抑制策略。例如，排除已知的扫描器账户、排除服务账户自身的定期任务。这些排除条件必须具体到账户名或进程路径，而不是笼统的“排除白名单”。

开发：编写规则与解析逻辑

开发阶段将设计文档转化为具体的规则代码。不同SIEM平台的语法不同，但核心结构一致：数据源过滤、条件判断、时间窗口聚合、告警输出。以下是一个伪代码示例，展示Kerberoasting检测规则的逻辑结构：

rule Kerberoasting_Detection {
  source: windows_security_event
  filter: event_id == 4769
          AND account_name NOT IN ("krbtgt", "机器账户$")
          AND ticket_encryption_type == 0x17
  group_by: account_name, client_address
  window: 5 minutes
  condition: count(distinct service_name) >= 5
  output: alert(
    title: "疑似Kerberoasting攻击",
    severity: "high",
    fields: [account_name, client_address, service_name_list]
  )
}

开发时要注意字段映射的准确性。例如，Windows事件4769中的“Service Name”字段在不同日志采集器中的命名可能不同，必须与解析器保持一致。此外，规则中应避免使用过于宽泛的匹配，如“包含admin”这类条件，否则会引入大量误报。

测试：用真实数据验证规则

测试阶段的目标是回答两个问题：规则能否检出目标行为？规则是否会产生不可接受的误报？测试通常分为单元测试和集成测试。

单元测试使用构造的样本日志，验证规则在理想情况下触发。例如，构造5条同一账户在5分钟内请求不同服务票据的4769事件，确认规则产生告警。集成测试则将规则部署到测试环境，回放最近7天的真实日志，统计告警数量和误报率。假设回放结果显示，某服务账户因定期任务触发了12次告警，经分析属于正常行为，则需要在规则中增加排除条件，或调整阈值。

测试阶段还应验证告警的上下文信息是否完整。一条高质量的告警应包含：触发时间、账户名、源IP、请求的服务列表、以及原始日志的引用链接。缺少这些信息，分析师需要额外查询，延长响应时间。

部署：灰度上线与监控

部署不是简单地把规则推送到生产环境。推荐采用灰度策略：先将规则部署到监控模式（只记录不告警），观察1-3天。监控模式下，规则会记录所有匹配事件，但不触发通知。分析师可以评估匹配数量是否在预期范围内。

如果监控模式下的日均匹配量在可接受范围内（例如少于10条），则切换为告警模式。同时，需要配置告警路由：高优先级告警发送到值班群，低优先级告警进入工单系统。部署后的一周内，应每天检查告警质量，记录误报和漏报情况。

度量：用数据判断规则是否有效

度量阶段回答“这条规则值得保留吗”。核心指标包括：

• 真阳性率：规则检出的告警中，经确认属于真实攻击或异常的比例。
• 误报率：误报数量占总告警数量的比例。通常要求低于30%。
• 平均响应时间：从告警产生到分析师开始处理的时间。
• 覆盖率：该规则覆盖的ATT&CK技术是否与其他规则重叠或互补。

假设Kerberoasting规则上线一个月，共产生40条告警，其中12条确认为真实攻击尝试，28条为误报（主要来自一个遗留服务账户）。真阳性率为30%，误报率为70%，高于可接受阈值。此时应回到设计阶段，增加对该服务账户的排除条件，或调整时间窗口和阈值，然后重新测试和部署。

退役：有序下线与知识保留

退役不是删除规则，而是有序下线并保留知识。触发退役的条件包括：规则长期无告警（如连续90天零告警）、误报率持续过高且无法修复、数据源已废弃、或该攻击技术已被更精确的规则覆盖。

退役流程包括：将规则状态改为“已退役”，保留规则文档和测试用例，记录退役原因和替代方案。如果规则曾产生过真实告警，应将相关案例归档到知识库，供后续参考。退役后，应更新检测覆盖率矩阵，确保该技术仍有其他规则覆盖，或明确标注为“未覆盖”。

整条生命周期不是单向的，而是一个闭环。度量阶段发现的问题会反馈到设计阶段，触发规则优化；退役阶段保留的知识会反哺需求获取，帮助识别新的检测盲区。只有把七个阶段都走完，检测规则才能真正成为安全运营的有效资产，而不是堆积在SIEM里的“僵尸规则”。