💡 今日學習目標：理解美國國家標準暨技術研究院推出的 NIST CSF 2.0 框架，掌握六大核心功能（GV、ID、PR、DE、RS、RC）的頂層防禦思維，並看懂新增的「治理（Govern）」為什麼被放在正中央，而不是排在第六格。

📌 前言：修補程式，比攻擊早了整整三天

先看一個要命的時間差。

2017 年 3 月 7 日，Apache 官方發布了 Struts 框架一個嚴重遠端程式碼執行漏洞（CVE-2017-5638）的修補程式。三天後，3 月 10 日，攻擊者就開始利用這個還沒被修補的漏洞，入侵了美國徵信機構 Equifax 的系統。

這件事本身還不是最要命的部分。真正要命的是：Equifax 的資安團隊，其實知道這個漏洞，也知道有修補程式可用。 內部政策也白紙黑字寫著「重大漏洞要在 48 小時內修補」。

但修補程式沒有被套用到所有受影響的系統上。攻擊者從 3 月起潛伏其中，到 5 月 13 日開始大規模竊取資料，一路持續到 7 月底。

為什麼這麼久都沒被發現？因為負責監控流量的設備，用來解密流量的 SSL 憑證早在 2016 年 1 月就已過期。換句話說，那台監控設備整整 19 個月處於失效狀態，沒有人發現。直到 7 月 29 日更新憑證後，異常流量才在第一時間現形；9 月 7 日正式對外公告。

更驚人的是眾議院調查報告的另一個數字：Equifax 當時放任超過 300 張憑證過期，其中 79 張是用於監控「業務關鍵」網域的。那台失效的監控設備不是特例，是常態。

最終結果：1 億 4,790 萬名美國人的個資外洩，包含社會安全碼、出生日期、地址。

📖 資料來源：美國眾議院監督與政府改革委員會調查報告（2018-12，PDF），本案最完整的一手調查；Apache Software Foundation 官方聲明

這裡最諷刺的地方是：Equifax 不是沒有政策，甚至不是沒有修補程式。是「政策有沒有被真的落實、有沒有人負責確認」這一層，整個是空的。

而這正是今天要談的框架裡，最新加入的那一塊拼圖。

🔍 核心原理：NIST CSF 2.0 六大功能，以及正中央那一塊

在沒有資安標準框架之前，許多企業做資安就像「瞎子摸象」：有人花了幾百萬買防火牆，卻忘了維護資料庫備份；有人寫了極為嚴謹的權限程式碼，卻從來不看伺服器日誌。

為了給全球組織提供一套通用的資安戰略語言，美國國家標準暨技術研究院（NIST）發布了著名的 Cybersecurity Framework (CSF)。這份框架有一段值得知道的沿革：

• CSF 1.0（2014 年 2 月）：源自歐巴馬政府的第 13636 號行政命令，目標鎖定在關鍵基礎設施（電力、金融、交通等），而且明確定位為自願採用的框架，不是強制法規。
• CSF 1.1（2018 年 4 月）：小幅修訂，補強供應鏈風險與自我評估的指引。
• CSF 2.0（2024 年 2 月）：適用範圍從關鍵基礎設施擴大到任何規模、任何產業的組織，並且新增了第六個核心功能：Govern（治理）。

📖 資料來源：IBM — Unpacking the NIST Cybersecurity Framework 2.0

在最新的 CSF 2.0 版本中，框架被劃分為六大核心功能（Functions）。但這裡有一個容易被畫錯的地方：Govern 不是排在 Recover 後面的「第六格」，它被 NIST 畫在正中央，是其餘五項功能運作的基礎：

NIST CSF 2.0 六大功能深度解析：

1. 🏛️ Govern（治理）：「策略與究責」。定義組織的風險管理策略、角色責任與監督機制。CSF 2.0 全新獨立的核心功能，用意是把資安決策拉到管理層，而不是只丟給工程團隊。
2. 🔍 Identify（識別）：「資產與風險」。盤點組織內有哪些硬體、軟體、資料與潛在資安風險。
3. 🛡️ Protect（保護）：「邊界與存取」。部署存取控制、資料加密與安全開發，防止資安事件發生。
4. 📡 Detect（偵測）：「即時監控」。透過 Log 分析與異常偵測，在駭客入侵的第一時間發現跡象。
5. 🚨 Respond（回應）：「事件處置」。當資安事件不幸發生時，如何進行隔離、遏止與溝通。
6. 🔄 Recover（復原）：「系統重建」。透過備份與災難復原計畫，迅速恢復業務正常運作。

🔬 用 Equifax 案例重新看一次六大功能

回頭看開頭那個案例，你會發現這不是單一環節出錯，是多個功能同時失守，而源頭都能追回 Govern：

• Identify 沒做齊：資安團隊知道漏洞存在，但顯然沒有一份完整、即時更新的資產清冊告訴他們「哪些機器都還在跑有漏洞的 Struts 版本」。
• Protect 執行不到位：修補政策白紙黑字寫著 48 小時，但沒有被落實到所有系統上。
• Detect 出現致命盲點：監控工具因為 SSL 憑證過期而看不見流量，而且這個狀況整整存在了 19 個月都沒人發現。

三個功能同時出包，聽起來像是三個獨立的意外。但眾議院監督委員會的調查報告與 GAO（美國政府問責署）的結論是一致的：根因是治理層級的問題：沒有人被明確賦予「確認修補真的執行」與「確認監控工具本身健康」的責任。政策寫在紙上，跟政策被驗證執行，是兩件不同的事，而 Govern 管的正是後者。

這跟 Day 22 講的 Capital One 案例可以放在一起對照：Capital One 是架構設計層級的疏忽（信任邊界、攻擊面、故障安全）；Equifax 是治理層級的疏忽（政策沒人驗證、責任沒人扛）。 兩種疏忽都可能造成上億筆資料外洩，這也是為什麼 CSF 2.0 要把 Govern 獨立出來、放在正中央：技術控制做得再細，沒有治理層去驗證與究責，防線一樣會悄悄破洞。

💡 常見誤解：「NIST CSF 是強制要遵守的法規」

這是很常見的誤會。NIST CSF 從 1.0 版一開始就被明確定位為「自願性」框架。它源自的第 13636 號行政命令，本身要求 NIST 制定的就是一套自願採用的框架，不是法律。你不會因為沒有導入 CSF 而違法。

但「自願」不代表「沒有壓力」。愈來愈多的政府採購合約、資安保險核保、甚至其他法規（例如某些行業別的監理要求）會引用 CSF 作為事實上的基準線，把「有沒有對照 CSF 做風險管理」當作是否夠格投保、夠格得標的條件之一。

⚠️ 這牽涉到具體合約與監理要求的判讀，不是一句話能講完的法律問題。如果你的組織在評估要不要導入、或合約裡被要求要符合 CSF，建議實際諮詢熟悉相關法規的專業人士，這裡不是要取代那個判斷。

💡 開發者角度：NIST CSF 2.0 的實務意義

身為開發者，我們不能只關心 Protect（保護） 階段的寫 Code。

了解 NIST CSF 2.0 能讓我們在設計系統時具備大局觀：

• 寫 API 時 ➔ 思考是否符合 Identify（資產盤點） 與 Protect（權限加密）。
• 印 Log 時 ➔ 思考這是否能幫助 SIEM 系統進行 Detect（異常偵測）。別忘了 Equifax 那台因憑證過期而失效 19 個月、卻沒有人發現的監控設備，監控本身也需要被監控。
• 規劃資料庫時 ➔ 思考是否備妥了異地備份機制以支援 Recover（復原）。
• 訂修補政策時 ➔ 別只寫在文件裡，想清楚 Govern 要問的那句話：「這件事，誰負責確認它真的被做到？」這正是 Day 05 規劃 SDLC 時那份 CheckList 想問的同一個問題，只是這次拉到了組織治理的高度。

🎯 今日重點小結與防守心法

• 🔹 心法 1：Govern 是地基，不是第六格。CSF 2.0 把治理畫在正中央，是因為其餘五項功能的執行品質，最終都取決於治理層有沒有把政策落實成「有人真的負責、有人真的驗證」。
• 🔹 心法 2：政策寫出來，不等於政策被執行。Equifax 有修補政策、有監控工具，但沒人驗證兩者是不是真的在運作，這正是三個功能同時失守的根因。
• 🔹 心法 3：CSF 是自願框架，但愈來愈常被當作事實基準。不遵守不違法，但合約、保險、監理要求正在把它變成隱性門檻。

🚀 接下來兩天：把六大功能落地成日常 CheckList

從 Day 25 開始，我們把 Identify 與 Protect 拆成開發新手能直接照做的清單；Day 26 則處理 Detect、Respond 與 Recover，包含怎麼寫出真正有用的稽核 Log。Day 27 我們會遇到另一個治理層級的框架 ISO 27001，屆時可以回頭比較它跟 NIST CSF 的 Govern 有什麼異同。

💬 明日預告：【Day 25】NIST CSF 實務落地：識別 (Identify) 與保護 (Protect) — 盤點與防禦機制
明天我們將深入探討 NIST CSF 的核心前兩棒：如何做好資產盤點與安全保護！