回顧真實發生過的公開事故，不是重播新聞，而是從「在你的環境裡如何防禦」的視角來解讀。本文是 基於公開記錄（主管機關、官方公告、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