回顾真实发生过的公开事故，不是重播新闻，而是从「在你的环境里如何防御」的视角来解读。本文是 基于公开记录（监管机构、官方公告、Apache Software Foundation、报道）的解说。出处在文末注明。
- 对象
- Equifax（美国信用信息巨头）
- 公布
- 2017 年 9 月 7 日（入侵 5 月～7 月／发觉 7 月 29 日）
- 手法分类
- 利用已知 CVE（Apache Struts RCE）未应用，进行入侵与对外带出
- 影响规模
- 美国约 1.47 亿人（姓名、SSN、出生日期、住址等。部分信用卡号也在内）
- 根本原因
- 放任已知 CVE ＋ 缺乏资产清单 ＋ 检测空白（证书失效）
- 主要对策
- 补丁 SLA、资产盘点、机器监控、检测健全性
发生了什么（通俗版）
Equifax 运营着一个供用户对信用信息提出异议的在线申诉窗口。它是基于一个名为 Apache Struts 的组件构建的，而该组件被发现存在一个 可以从外部执行任意代码 的严重漏洞（CVE-2017-5638）。
修复补丁在 漏洞公布的同一天（2017 年 3 月 7 日） 就已发布。然而，目标的申诉系统一直没有打上补丁。攻击者在两个月后的 5 月，利用这个已知漏洞入侵，并在内部网络中横向移动，带出了大量个人信息。
更糟的是，监控通信的设备 因证书失效而长期停摆，导致异常的外带活动 76 天都没能被检测到。7 月 29 日刚更新证书，可疑通信便立刻显现。本应用来察觉的机制，一直处于停止状态。
原因不是高级的攻击，而是没有打补丁
这次事故所利用的，是一个全球早已公开、补丁也已发布的已知漏洞。造成损失的不是攻击的高级程度，而是缺少在规定时间内堵住已知风险的运维。无论是个人开发还是组织，这都会以同样的结构发生。
攻击的各个阶段与拦截方法
重要的是，这是一条五步的连锁，而 每一步都有可以拦下的地方。请不要把它读成攻击步骤，而要读成哪里本可以被拦下。
① 已知 CVE 公开（修复补丁同日发布）
⊘ 拦截点：用机器监控即时检测『与自己相关的 CVE』
② 公开系统一直未应用而被放任
不掌握 Struts 在哪里运行，因此被漏掉了。
⊘ 拦截点：资产清单 ＋ 补丁 SLA（公开→应用的期限）
③ 通过 RCE 入侵
通过未修补的漏洞执行任意代码。
⊘ 拦截点：最小权限・WAF 作为『辅助』并用
④ 在扁平网络中横向移动并大量外带
隔离薄弱，一处被攻陷便波及到广域数据。
⊘ 拦截点：用网络隔离限制一次入侵能波及的范围
⑤ 监控证书失效，76 天无法检测
本应用来察觉的设备停着。
⊘ 拦截点：把证书・监控的健全性检查养成习惯
已公布的时间线
2017-03-07
CVE-2017-5638 公布。同日发布修复补丁。2017-03～
公司内部发出告警。但目标的申诉系统仍未应用。2017-05～07
攻击者利用未修补的漏洞入侵，带出数据。2017-07-29
刚更新监控设备的证书，便检测到可疑通信而被发觉。2017-09-07
对外公布。查明约 1.47 亿人受影响。2019-07
与 FTC・CFPB・各州以最高约 7 亿美元达成和解（美国史上最大规模）。
根本原因：不只是漏打了一个补丁
如果停留在「忘了打补丁」上，就会重演。实际上，本质是 多道防御接连失守。
失守的配置（事故时）
- 放任已知 CVE（修复已发布，却没应用到公开系统）
- 缺乏资产清单（不掌握组件在哪里运行）
- 扁平网络（允许横向移动、数据波及）
- 检测空白（监控设备因证书失效而长期停摆）
守住的配置（防止重演）
- 补丁 SLA：定下从公开到应用的时限，优先处理 KEV／高 CVSS
- 资产清单：用机器掌握依赖与运行位置，不漏掉任何目标
- 网络隔离：限制一次入侵能波及的范围
- 检测健全性：定期确认证书・监控在正常工作
打补丁是持续的运维，而不是一次性作业
重要的不是「将来某天修」，而是要有「在公开后 N 小时／天以内修好」的时限（SLA）。并且，为了不遗漏该打补丁的对象，需要让机器掌握哪里在运行什么。一旦依赖人的记忆，就会像 Equifax 那样留下没打补丁的系统。
在你的环境里防止重演
下面是不论规模都有效、按优先级排列的对策。把「不放任已经公开的 CVE」这一点，用机制来保证。
拥有资产清单（哪里在运行什么）
把自己的依赖库，以及它们在哪些服务・容器上运行，列成清单。Equifax 最大的问题就是漏掉了目标系统。要点在于以 实际正在运行的版本 来掌握。
定下补丁 SLA（公开→应用的期限）
先定下「重大 CVE 在公开后 N 天以内应用」的期限。尤其要把 KEV（正在被实际利用）与高 CVSS 放在最优先。有了期限，被搁置的修复才会显现出来。
让机器去监控（不靠人力追踪）
靠人力追踪 CVE 是不可能的。用 Dependabot（GitHub）或 osv-scanner 检查锁文件，只对与自己依赖相关的 CVE 自动通知。依赖的机器监控该怎么搭建里有具体步骤。
准备隔离与检测（以防攻击得手）
隔离网络以抑制横向移动，并能检测异常的大量外带。把确认监控与证书是否正常工作也纳入运维。 停止运行的监控什么也检测不到。
本站自身也在实践同样的对策
本站自身也按这里所写的，把自己的依赖纳入 CVE 监控的对象。我们自己也在实践 Equifax 的教训：用不依赖人记忆的机制堵住已知漏洞。 把「将来某天修」换成「在期限内、借助机器修好」。
出处（公开记录）
本文的事实基于以下公开信息。不涉及攻击的复现步骤或载荷，只聚焦于防御的教训。
- Apache Software Foundation「Media Alert: Equifax Data Breach Due to Failure to Install Patches」(2017) — news.apache.org
- Equifax 官方公告「Releases Details on Cybersecurity Incident」(2017) — investor.equifax.com
- CFPB/FTC/各州 和解公告 (2019) — consumerfinance.gov
- CSO Online「Equifax data breach FAQ」— csoonline.com