大多數嚴重漏洞都源自設計階段,而非寫程式階段。一個及早做、有 owner 的輕量威脅模型,價值遠勝過上線後一份 100 頁的 pentest 報告。
什麼是威脅模型?
威脅模型是回答 Adam Shostack 四個問題的過程:
- What are we working on? — 畫出資料流程圖 (DFD)。
- What can go wrong? — 套用 STRIDE 列出威脅。
- What are we going to do about it? — 緩解措施,或由人負責的「accept risk」。
- Did we do a good job? — 部署後再檢視。
一分鐘看懂 STRIDE
| 威脅 | 違反屬性 | 範例 |
|---|---|---|
| Spoofing (假冒) | Authentication | 偽造使用者、token 被重用 |
| Tampering (竄改) | Integrity | 修改請求、修改 DB 中資料 |
| Repudiation (否認) | Non-repudiation | 稽核日誌不足以證明操作 |
| Information disclosure (資訊洩漏) | Confidentiality | 洩漏 PII、透過日誌洩漏金鑰 |
| Denial of service (阻斷服務) | Availability | 暴力破解、slowloris、昂貴查詢 |
| Elevation of privilege (權限提升) | Authorization | IDOR、跳出 sandbox、容器逃逸 |
畫出正確層級的 DFD
DFD 上需要四種元素:
- External entity:使用者、第三方 API。
- Process:服務、函式。
- Data store:資料庫、S3、queue。
- Data flow:元素之間的箭頭。
最重要的是信任邊界 (trust boundary):不同信任等級區域之間的界線 (Internet ↔ web tier、app ↔ DB、租戶 A ↔ 租戶 B)。每條穿越信任邊界的箭頭,都是需要驗證、檢核、加密的點。
從 DFD level 1 開始 (1 個服務 + 直接相依)。不要畫過於籠統的 level 0,也不要鑽到 level 3——既花時間,又不會產生新的決策資訊。
在每個元素上套用 STRIDE
實用小技巧:對 DFD 上每個元素,問 6 個 STRIDE 問題。不必每個格子都硬擠出威脅——不合理就略過。記入下表:
| Element | Threat | 描述 | Mitigation | Owner | Severity |
| -------------- | ------ | ---------------------------------------- | ---------------------- | ----- | -------- |
| Login endpoint | S | 對帳號暴力破解 | Rate limit + MFA | @team | High |
| Login endpoint | I | 透過錯誤訊息洩漏使用者列舉 | Generic error message | @team | Medium |
| Upload service | T | 儲存體上的檔案 replace race | Versioning + checksum | @team | Medium |
| Order DB | E | 查詢 /orders/{id} 時的 IDOR | 依 owner 做 authz 檢查 | @team | High |
風險評分
兩個常見方案:
- CVSS v3.1/v4:業界標準,適合具體漏洞,有可分享的標準 vector。
- OWASP Risk Rating:簡單 (Likelihood × Impact),容易向非技術 stakeholder 解釋。
在組織內統一選 1 種,並寫入手冊。不要讓每個團隊各自發明評分標準——之後無法相互比較。
風險登錄表是活的資產
威脅模型不是一次性文件。風險登錄表需要:
- 每個風險都有 owner。
- 有緩解 deadline 或接受風險的理由。
- 每季或在重大架構變動時重新檢視。
- 連結到 issue tracker,讓 mitigation 真的有 ticket 可追。
什麼時候該用 LINDDUN、PASTA?
預設使用 STRIDE。可考慮加入:
- LINDDUN:當服務處理大量 PII/PHI、需要針對隱私做威脅建模時 (Linkability、Identifiability、Non-repudiation、Detectability、Disclosure、Unawareness、Non-compliance)。
- PASTA:需要把威脅模型與商業風險細節綁在一起時,有 7 個正式階段——適合銀行、醫療等關鍵系統。
結論
威脅模型不是魔法。一場 60 分鐘的會議搭配 DFD level 1、STRIDE 檢查表與風險登錄表,就足以幫一個服務避開大部分設計缺陷。定期重複、有 owner、寫入 ADR——這就是把威脅模型變成技術習慣,而不是年度活動的方式。