資安 mitigation 對讀者有意義的不是「mitigation 存在」、是「mitigation 跟 threat 的對應鏈成立」。 對應鏈拆三段——設計上 mitigation X 攔 threat Y + 攔的 mechanism 是 Z + Z 失效時的訊號是 W——任一段空、mitigation 在實作端就會跟 threat 錯位、變成「看似在防、實際只擋表面 artifact」的 defense theater。

三段都齊、reader 才能反向驗證實作有沒有達到設計強度。

情境

資安章節常見的論述形態：給 mitigation 名稱（rate limit、CSRF token、prepared statement）+ 對應 threat 名稱（brute force、CSRF、SQLi）。表面對位、底層 mechanism 沒交代。讀者讀「prepared statement 防 SQLi」、實作時用 string concat + escape function、心裡覺得「我擋 SQLi 了」——因為原文只給 mitigation/threat 對應、沒給 mechanism（parameterization 跟 escape 是兩種不同 mechanism、抗的攻擊面不同）。

實際 case 的失效模式有三類：

失效模式 1：Mitigation 攔表面 artifact、不是攻擊 mechanism

1論述：rate limit 擋 brute force
2讀者實作：per-IP rate limit
3攻擊 mechanism：分散來源（botnet）每個 IP 低頻率、整體高頻率
4結果：mitigation 攔到的是「單 IP 高頻」表面、不是「身分嘗試」mechanism

對位該寫的是「rate limit 攔『單來源高頻嘗試』、不攔『身分嘗試』本身」——mechanism level 的對位、不是名稱對位。

失效模式 2：Mitigation 跟 threat 在不同抽象層

1論述：CSP 擋 XSS
2讀者實作：CSP header 設 default-src 'self'
3Threat 抽象層：XSS 是 injection class、有 reflected / stored / DOM 三類
4Mitigation 抽象層：CSP 是 browser-side execution policy
5結果：CSP 擋「未授權 script 執行」、不擋 stored XSS 在 DB 已 persist 的階段

對位該寫 mitigation 在抽象層的位置——CSP 在 browser 執行層、不在 input 處理層。讀者光看「CSP 擋 XSS」會以為 input sanitization 不必做。

失效模式 3：Mitigation 假設上層 threat 已擋

1論述：bcrypt 防 password DB 外洩後 brute force 還原
2讀者實作：bcrypt 存 password
3被忽略的 threat：DB 外洩前 - phishing / credential stuffing / weak password
4結果：bcrypt 是「外洩後」的 last line、不是 password security 的 first line

對位該寫 mitigation 在 defense-in-depth 的層次跟前提——bcrypt 在「假設 DB 外洩」的條件下成立、不擋外洩前的 threat。讀者沒拿到前提、會以為 bcrypt 是 password security 的 sufficient solution。

理想做法

每個 mitigation 段落補三欄對位：

三欄對位模板

1[Mitigation X]
2- 攔的 threat：[具體攻擊行為、不是攻擊類別名稱]
3- 攔的 mechanism：[X 在什麼層擋 / 擋的是 mechanism 的哪一步]
4- 失效訊號：[reader 能觀察到 mitigation 有沒有發揮的具體現象]

例（per-IP rate limit）：

1per-IP rate limit
2- 攔的 threat：單來源連續嘗試（同 IP 短時間多次 login）
3- 攔的 mechanism：在 single-source 維度限制 attempt rate、攻擊者必須切 IP 才能繞
4- 失效訊號：分散來源（多 IP 各自低頻）的 aggregate 嘗試率、per-IP rate limit metric 不會 trigger

例（bcrypt password hashing）：

1bcrypt
2- 攔的 threat：DB 外洩後 password 被離線 brute force 還原
3- 攔的 mechanism：work factor 控制 hash 計算成本、攻擊者每次嘗試的成本不可優化
4- 失效訊號：weak password / 已知 password 在 dictionary 中、攻擊者不需 brute force 全 space
5- 前提：上層擋住 phishing / credential stuffing、bcrypt 是 last line、不是 first line

對位的層次規則

對位驗證要在三個層次都對齊：

只到名稱層 = defense theater；到 mechanism 層 = 可實作驗證；到前提層 = 可疊加 defense-in-depth audit。

對位 audit 的工具方法

對 mitigation 群組做集合運算：

11. 列章節所有 mitigation 跟對應 threat
22. 對每對 (mitigation, threat) 補 mechanism + 前提
33. 集合化：聯集所有 mitigation 攔的 mechanism、聯集所有 threat 的 mechanism
44. 找 gap：threat 集合裡沒被 mitigation 集合涵蓋的 mechanism
55. Gap 處理：補 mitigation / 標 out-of-scope（[#101](../threat-model-explicitness/)）/ 升級到 defense-in-depth 上層

集合運算讓對位錯誤跟覆蓋 gap 從「靠感覺」升級到「可量化」。

沒這樣做的麻煩

Defense theater 在 audit 跟 implementation 都通過、生產系統有破口

只到名稱層對位的 mitigation、audit 工具看到「rate limit 已部署」會 pass、implementation 看到「CSRF token 已加」會 pass、threat 還在——攻擊者用 mechanism 變體（分散來源 / DOM XSS / stored injection）繞過、mitigation 集體 silent 失效。對位錯誤的 mitigation 跟沒 mitigation 在攻擊者眼中等價、但對 audit / 對讀者不等價——這個 gap 是 defense theater 的本質。

跟 #82 字面攔截 vs 行為精煉 同骨：mitigation 名稱對位是字面層、mechanism 對位是行為層、前提對位是 contextual 行為層。stop at 字面層 = false confidence。

Mitigation 變體跟 threat 變體無法 trace

新 threat 出現（如 credential stuffing 之於傳統 brute force）、reader 必須重新評估既有 mitigation 是否還對位。對位鏈寫到 mechanism + 前提的 mitigation 可被 trace（per-IP rate limit 的 mechanism 是 single-source 限制、credential stuffing 是分散來源、不對位、需新 mitigation）；只到名稱層的 mitigation 不可 trace（rate limit vs credential stuffing：名稱看起來「應該擋」、實際不擋）。寫作時的 mechanism / 前提投資、是給未來 threat evolution 留的 review 入口。

Mitigation 疊加時的責任邊界含糊

多個 mitigation 共防一個 threat、若各自不寫 mechanism + 前提、疊加時無法判斷「誰負責什麼層」。修補某個 mitigation 時不知道會不會影響其他 mitigation 的前提、變更冒險成本上升。明示 mechanism + 前提 = 明示 mitigation 之間的 dependency、修補成本可控。

跟其他抽象層原則的關係

判讀徵兆

適用範圍與邊界

• 適用：資安 mitigation 設計（auth / crypto / 防護 / 標準 control）的論述；任何「方法 → 問題」對應的高 stakes 領域（concurrency primitive 對 race 類別 / consensus 演算法對 failure mode / financial control 對 risk 類別）
• 不適用：純概念 / 歷史介紹（不教 mitigation）、研究探討（讀者預期自行 explore mechanism）
• 邊界：「對位驗證」≠「列出每個攻擊變體」——mechanism 層列到攻擊行為的根 mechanism 即可、不必列所有 surface 變體；判別準則是「reader 能不能用這個 mechanism 描述去判斷新變體攻擊是否在 mitigation 覆蓋內」
• 過度對位反例：每個 mitigation 寫 mechanism + 前提 + 三層 scope qualifier + 五種失效訊號、文章變 audit checklist、不是教學；mitigation 對位的投資量級對應 mitigation 在系統的責任比重——核心 mitigation（auth / crypto primitive）值得三層完整對位、輔助 mitigation（log redaction / banner notice）只到 mechanism 層即可

本卡是資安 audit 第二個維度（mitigation 對位）、配 #101 threat model 明確性、後續 #103 context-dependence、#104 citation 形成完整 audit dimension 集合。