3. 检测需求来源与优先级

检测工程最怕的不是没有规则，而是规则很多却没有一条真正对应需要被发现的威胁。检测需求管理要解决两个问题：需求从哪里来，以及先做哪一个。前者决定覆盖面，后者决定投入产出比。本节把检测需求的主要来源归纳为四类：威胁情报、事件复盘、合规要求和业务风险，并给出一套可落地的提取与排序方法。

四类来源各自提供什么

威胁情报提供的是“外部正在发生什么”。它通常以 IOC（IP、域名、文件哈希）、TTP（战术、技术与过程）和攻击者画像的形式出现。IOC 适合快速布防，但生命周期短；TTP 更稳定，适合转化为行为检测规则。例如情报显示某勒索团伙惯用“通过 PsExec 横向移动后部署加密程序”，那么可提取的检测需求是“监控 PsExec 远程执行并伴随大量文件重命名”的行为链，而不是只封一个 IP。

事件复盘提供的是“我们这里真实发生过什么”。一次真实入侵的复盘能暴露检测盲区：攻击者从哪个入口进来、用了什么工具、在哪些主机留下痕迹、为什么当时没告警。复盘产出的检测需求最贴近自身环境，优先级通常较高，因为它证明该路径在本环境中可行。

合规要求提供的是“必须覆盖什么”。等级保护、行业监管、审计条款会明确要求对特定行为留痕和告警，例如“对重要系统的异常登录进行监测”。合规需求的特点是必须做，但不一定代表当前最高风险，因此适合作为基线需求纳入，而不是全部抢占最高优先级。

业务风险提供的是“什么最值得保护”。核心数据库、支付接口、源代码仓库、域控服务器，一旦被攻破损失巨大。业务风险帮助我们把检测资源向高价值资产和高影响场景倾斜，避免把大量规则堆在无关紧要的测试机上。

从来源到检测需求的提取方法

无论来源是哪一类，提取检测需求时都要回答四个问题：数据源是什么、行为特征是什么、触发条件是什么、预期告警是什么。以“威胁情报显示攻击者使用 Cobalt Strike 默认证书”为例，提取过程如下：数据源为网络流量 TLS 证书字段；行为特征为 JA3 指纹或证书序列号匹配已知恶意值；触发条件为该指纹在非授权主机上出现；预期告警为“疑似 C2 通信”。这样一条需求才是可实现的，而不是停留在“加强 C2 检测”的口号上。

事件复盘提取需求时，建议沿着攻击链逐段检查：初始访问、执行、持久化、提权、防御规避、凭据访问、发现、横向移动、收集、命令与控制、数据外泄。每一段问一句“如果攻击者在这里动手，我们有没有数据能看到、有没有规则会告警”。缺失的那一段就是新的检测需求。

优先级排序：影响 × 可行性 × 时效

需求收集完之后，用三个维度打分排序，每个维度取 1～5 分，总分 3～15 分。

影响看资产价值和潜在损失。域控、核心数据库、支付系统上的检测需求给 5 分；普通办公终端给 2 分。可行性看数据源是否已有、规则是否容易实现、误报是否可控。日志已接入且行为特征明确的给 5 分；需要新增探针或行为模糊的给 2 分。时效看情报有效期和攻击窗口。正在活跃的勒索攻击情报给 5 分；已过期的历史 IOC 给 1 分。

举例：某情报显示攻击者正利用某 VPN 漏洞攻击同行业单位，影响 5 分、可行性 4 分（VPN 日志已接入）、时效 5 分，总分 14 分，应立刻开发。另一条合规要求“对普通用户登录失败进行记录”，影响 2 分、可行性 5 分、时效 2 分，总分 9 分，可作为基线排期。这样排序既不会漏掉必须做的合规项，也不会让低价值需求挤占高优先级资源。

一个可填写的检测需求登记表示例

下面给出一个可直接使用的登记表结构，字段只保留检测工程真正需要的部分。

登记表的价值在于让需求可追踪、可排序、可复评。每条需求从提出到上线，状态依次为“待排期—开发中—测试—已上线—已下线”。上线后还要回看告警量和误报率，如果一条规则上线一个月零告警，要么是环境确实干净，要么是规则写错了，两种情况都需要复查。

常见误区

• 只追情报不建基线：IOC 来得快去得也快，没有行为基线，情报过期后检测能力归零。
• 合规需求全部置顶：合规是底线不是上限，全部置顶会让真正的高风险需求排不上队。
• 复盘只写报告不产需求：复盘的终点应该是新的检测规则或监控项，否则同类事件还会再次发生。
• 忽略可行性：一条影响 5 分但数据源缺失、误报极高的需求，实际价值可能低于影响 3 分但能立即上线的需求。

把四类来源统一收进登记表，用影响、可行性、时效三个维度打分排序，再按状态跟踪到上线和复评，检测需求管理就从“拍脑袋决定做什么”变成了可解释、可追溯、可持续迭代的工程过程。