6.4 威胁情报与漏洞管理

6.4 威胁情报与漏洞管理

本节摘要：威胁情报（Threat Intelligence）是把攻击者信息加工成可行动决策的知识产品，按消费层次分战略、运营、战术与指标四类；漏洞管理（Vulnerability Management）是"发现—评估—修复—验证"的持续闭环，核心是按风险而非按扫描器严重度排序。本节鉴定情报的分层消费与漏洞闭环的运营要点。承接 6.3 节的事件响应，本节回到日常：大事件之间，安全团队靠这两台引擎维持场子。

情报不是数据流，修复不是扫描报告

两个术语都有被用歪的常见姿势。威胁情报被歪成"买一份威胁数据源订阅，倒进 SIEM 就完事"——结果告警量翻倍，人还是原来的人，产出是更多的噪音。漏洞管理被歪成"每月跑一次扫描，把报告群发运维"——结果高危漏洞平均修复周期以月计，报告越攒越厚。两个歪法共享同一个病根：把输入当成了产出。情报的价值在"改变了哪个决策"，修复的价值在"哪个漏洞真正关掉了"，订阅和扫描都只是原材料。

验明正身：威胁情报的分层

情报按消费对象与时效分成四层，采购与建设前先想清楚自己要哪层：

多数组织真正缺的不是指标层（公开源很多，机器能消化）而是战术层——知道"这个团伙惯用什么手法落马、怎么横移"，才能反推出 3.2 节该加什么检测规则、2.4 节的哪个阶段自己看不见。指标层买得到，战术层要靠自己的运营能力消化。

情报的结构化表达以 STIX 一类的标准为例，看一条指标长什么样：

情报对象(简化示意):
  类型: 恶意域名
  值:   cdn-metrics-update.example.xyz
  关联: 勒索家族 X 的 C2 基础设施
  置信: 高(多源交叉)
  有效: 至 2026-06-30
  建议动作: 出口封禁 + 历史日志回溯 90 天
                                   ^^^^^^^^ 情报的可行动性所在:
   回溯发现历史命中 = 已发生通信 = 立即触发 6.3 节的响应流程
​

注意最后一行——一条情报的价值判定标准就是它能不能触发动作。封禁是面向未来的动作，回溯是面向过去的动作，两者配套才算把一条指标消化完。

验明正身：漏洞管理闭环

漏洞管理是四拍循环：发现（3.4 节的扫描与情报推送）、评估（按风险排序，不是照抄扫描器分数）、修复（补丁、配置、虚拟补丁）、验证（复扫确认关闭）。1.3 节已经给出评估的原则——漏洞严重度要乘上场景，这里落到操作层：

修复优先级修正表(在扫描器严重度之上叠加场景因子):
  暴露面:   公网可达 +2 级     内网隔离 -1 级
  资产价值: 核心业务资产 +2 级  测试环境 -1 级
  利用状态: 已有在野利用 +2 级  无公开利用 -0
  补偿控制: 前方有 WAF/分段缓解 -1 级
  叠加后定 SLA: 超高危 72h 内  高危 7 天  中危 30 天  低危 下个窗口
​

SLA（修复时限承诺）是漏洞管理从"活动"变成"管理"的分水岭：有 SLA 才有超期率这个指标，有指标才谈得上治理。一个健康的漏洞管理月报只需要三行数字：本月新增数、按期关闭率、超期 Top 原因分布——第三行是给流程改进看的。

工程实践要点

在野利用状态是最高权重因子。 一个"中危"漏洞若已被攻击团伙批量利用，实际风险高于躺在代码里没人管的"高危"。跟踪利用状态靠威胁情报（本节前半的运营层情报）与厂商通告，两台引擎在这里咬合。

修复不了的要写补偿控制。 老系统没有补丁（厂商停止维护）是常态而非例外，处置选项是把"修不了"转成"够不着"：网络隔离到专用段、虚拟补丁拦利用流量、强化监控。补偿控制要在资产清单上登记并定期复验——它本身就是一条新增的控制项，会过期会失效。

⚠️ 常见坑：以扫描覆盖率冒充漏洞管理。"我们扫描覆盖率 98%"回答的是"找得到吗"，不是"关掉了吗"。考核指标请认准按期关闭率与暴露窗口时长（从漏洞公开到修复完成的平均天数）。

💡 关键直觉：情报与漏洞管理共享同一条判定标准——每个输入都应能回答"它改变了哪个决策、触发了哪个动作"。答不出来的输入，无论多贵，都是装饰品。

鉴定结论

• 情报四层中战术层是自建能力的分水岭，指标层必须配"封禁加回溯"的双动作才算消化；
• 漏洞管理四拍循环的核心是评估排序与 SLA，按期关闭率是唯一健康的北极星指标；
• 在野利用状态权重最高，修复不了的老系统走补偿控制并登记复验；
• 日常运营的两台引擎交代完毕。接下来接诊三位新病人：云、容器与物联网。

附卷：漏洞例会的一小时议程与三条裁决规则

漏洞管理要开成例会，例会要有一小时议程：

00-10 分: 上周按期关闭率与超期清单过目(只看数字与原因分布)
10-30 分: 新增高危项逐条定级——场景因子打分, 现场定 SLA
30-45 分: 超期项裁决——按裁决规则定归属, 不含糊
45-55 分: 情报简报——在野利用变化, 行业事件与本组织关联度
55-60 分: 行动项确认——每项有主人有时限, 会后十分钟内发出纪要
​

议程里最容易吵起来的是 30 到 45 分。预先立三条裁决规则，吵不起来：规则一，该不该修由安全定（风险判定是安全团队的职权），什么时候修由业务定（停机窗口是业务的职权）——职权分开，各自的道理才有边界。规则二，"修不了"必须走补偿控制登记，不接受"挂起"——挂起是无限期的委婉语，登记有复审日期。规则三，争议升级到 CTO 用一页纸——风险描述、两个方案、各自的代价与残留风险，让决策层十分钟拍板，而不是让工程师在群里拉锯三周。

情报源的订阅也顺手给个分层建议：指标层选一两个免费聚合源加厂商推送即可，别贪多；运营层重点订行业 ISAC 或同业通报（同业被打就是你的预演）；战术层如果预算只够订一份，选与自身技术栈匹配度高的厂商报告——写得再好，不覆盖你的系统也是空转。订阅清单半年复一次盘，砍掉半年没触发过任何动作的源：6.4 节正文的判词再念一遍——不能改变决策的输入是装饰品。

附卷二：漏洞披露时的对外口径

自家产品或服务被发现漏洞时，技术团队常被临时拉去写对外说明。三条纪律保平安：纪律一，只陈述事实与动作——"我们于某日确认某版本存在某类问题，已于某版本修复，建议用户升级"，不猜动机、不评价严重性、不承诺"绝对安全"。纪律二，给出可执行的用户动作——升级到哪个版本、临时缓解怎么配，写清楚到能照做，比任何表态都更安全。纪律三，时间线一致——对内报告、用户公告、监管通报的口径与时间点必须同源，三份材料各说各话是二次危机的标准起爆方式。

对外口径由法务与公关定稿、安全团队供事实（与 6.2 节的分工一致），但事实底稿的质量取决于安全团队的时间线功夫——这正是 6.3 节取节日常训练的能力。三节在真实事件里就是这么咬合的：取证给事实，情报给判断，合规给口径。

再送一个给小团队的减法建议：没有人力开漏洞例会时，把议程压缩成"一条消息"——每周五在安全频道发三行：本周新增高危数、按期关闭率、超期最长的一项及其原因。三行数据坚持一个季度，团队对漏洞的体感会自然形成；有了体感，例会随时可以升级回来。机制可以先瘦，不能先死。