3. 检测工程核心原则

检测工程不是“把规则堆进 SIEM”，而是一套围绕威胁假设、数据可观测性和运营反馈的工程方法。它要回答六个彼此咬合的问题：我们要发现什么、为什么相信它可被发现、需要哪些数据、告警是否足够可信、规则如何随环境演化、以及如何证明改进有效。这六个问题分别对应检测需求定义、检测假设、可观测性、信噪比、检测生命周期与持续改进。

一、检测需求定义：从威胁出发，而不是从日志出发

检测需求定义是把业务风险翻译成可验证的检测目标。一个可执行的检测需求至少包含：威胁行为描述、受影响资产范围、期望发现时机、可接受误报水平、以及验证方式。例如“检测域内非服务账号对 LSASS 内存的异常读取”比“监控凭据窃取”更可落地，因为它限定了行为、对象和判定边界。

需求定义常用来源包括：ATT&CK 技术映射、红队/攻防演练缺口、事件复盘中的漏报、合规控制项、以及资产关键性排序。实践中建议用“威胁—资产—数据—判定”四元组记录需求，避免需求停留在口号层面。

二、检测假设：把“可能发生”写成可证伪的命题

检测假设是检测需求的可证伪表达。它通常写成：“如果攻击者执行 X 行为，那么在 Y 数据源中应出现 Z 特征，且该特征在正常业务中应满足条件 C。”例如：如果攻击者使用 PsExec 横向移动，那么在进程创建日志中应出现 PSEXESVC 服务安装与远程服务启动，且源主机与目标主机不应存在常规运维关系。

假设的价值在于它把检测逻辑拆成可验证的因果链：行为→数据→特征→判定。若某条假设无法被数据验证，说明可观测性不足；若特征在正常业务中频繁出现，说明信噪比需要优化。

三、可观测性：检测的“传感器覆盖”

可观测性决定检测能力的上限。它不只是“有没有日志”，而是数据是否具备足够的字段、上下文、时间精度和留存周期。以进程创建为例，仅有进程名和命令行往往不足以判定恶意；还需要父进程、用户、完整性级别、签名状态、网络连接、以及主机资产标签。

可观测性评估可按数据源逐项打分：采集覆盖率、字段完整度、时间同步、留存时长、查询延迟。常见缺口包括：只采集 Windows 安全日志而缺少 Sysmon、云审计日志未开启、DNS 日志未留存、终端 EDR 遥测未接入数据湖。检测工程师应把可观测性缺口作为独立工作项管理，而不是在规则失败后才被动补数据。

四、信噪比：告警可信度的工程化度量

信噪比衡量告警中真实事件与噪声的比例。高噪声规则会消耗分析师注意力，导致真实告警被淹没。信噪比优化不是简单“加白名单”，而是通过上下文富化、行为基线、阈值调优和关联分析提升判定精度。

例如，一条“可疑 PowerShell 编码命令”规则在开发团队中可能每天触发数百次。优化路径包括：排除已知构建服务器、要求父进程为 Office 或浏览器、增加下载行为或网络连接关联、以及按资产关键性分级。优化后应记录误报率、漏报风险和平均调查时长，作为规则质量的量化依据。

五、检测生命周期与持续改进

检测规则有生命周期：需求提出→假设设计→数据验证→规则实现→测试上线→运营监控→复盘优化→退役归档。每个阶段都应有明确准入和退出条件。例如，规则上线前必须通过已知恶意样本和正常业务样本的双向测试；上线后需持续监控触发量、误报率和覆盖缺口。

持续改进依赖反馈闭环：分析师在告警中标记误报原因，检测工程师将其转化为规则调优或数据补采需求；红队演练暴露的漏报转化为新检测假设；事件复盘发现的检测盲区进入需求池。闭环的关键是“可追踪”：每条规则都应关联到需求编号、假设、数据源和负责人。

六、把原则落到日常工程动作

在真实团队中，这六项原则应转化为可执行的工作习惯。需求定义阶段，使用统一模板记录威胁编号、资产范围、数据源、判定条件和验证用例；假设设计阶段，要求每条规则至少对应一条可证伪假设，并写明“如果数据缺失，如何降级”；可观测性阶段，建立数据源健康看板，监控采集延迟、字段缺失率和留存到期告警；信噪比阶段，按周统计规则触发量、误报率和平均调查时长，对高噪声规则强制进入调优队列；生命周期阶段，为每条规则设置负责人、上线日期、最近验证日期和退役条件；持续改进阶段，每月复盘漏报事件和红队路径，把结论转化为新需求或数据补采任务。

综上，检测需求定义决定方向，检测假设提供可证伪的验证路径，可观测性决定能力上限，信噪比决定运营可用性，生命周期管理保证规则质量，持续改进则让整个体系随威胁和业务变化不断进化。六者不是并列清单，而是一个相互约束、持续反馈的工程闭环。