威脅模型範本（Threat Model Document）

參照標準：Microsoft STRIDE / OWASP Threat Modeling / ISO/IEC 27005:2022
文件用途：系統性識別、分析、評估與處置系統面臨的安全威脅
適用階段：系統設計階段（Design Phase）— Security by Design

📋 章節目錄

1. 文件資訊
2. 系統概述
3. 資料流程圖（DFD）
4. 信任邊界識別
5. STRIDE 威脅分析
6. 威脅風險評估
7. 緩解措施
8. 殘餘風險
9. 威脅追溯矩陣
10. 附錄

1. 文件資訊

📝 範本

📖 使用說明

• 威脅模型在架構設計完成後、開發實作前進行
• 建議組成跨功能團隊：架構師 + 資安人員 + 開發者 + QA
• STRIDE 是微軟提出的分類法，覆蓋六大威脅類型
• 本文件需與安全需求清單（SecurityRequirements）互相參照

💡 範例

2. 系統概述

📝 範本

2.1 系統架構摘要

2.2 資產識別

📖 使用說明

• 系統架構摘要提供技術棧全貌，協助識別攻擊面
• 資產識別需列出需保護的有價值目標（攻擊者感興趣的）
• 資產敏感等級決定威脅分析的優先順序

💡 範例

2.1 系統架構摘要

2.2 資產識別

3. 資料流程圖（DFD）

📝 範本

Level 0 - 系統環境圖

外部實體 → [系統邊界] → 外部實體

Level 1 - 子系統分解

📖 使用說明

• DFD 是威脅建模的核心輸入，透過視覺化理解資料流向
• Level 0 呈現系統與外部互動全貌
• Level 1 展開各子系統，識別每個資料流的信任邊界
• 建議使用工具：Microsoft Threat Modeling Tool、OWASP Threat Dragon

💡 範例

Level 1 - HRMS 子系統分解

┌─────────────────── 信任邊界：Internet ───────────────────┐
│                                                          │
│  [員工/主管]  ────→  Web SPA (React)                    │
│                                                          │
└─────────────────────────────────────────────────────────┘
                           │ HTTPS (JWT)
┌────────────────── 信任邊界：DMZ ────────────────────────┐
│                           ▼                              │
│                    (API Gateway - Kong)                   │
│                           │                              │
└───────────────────────────┼──────────────────────────────┘
                           │ mTLS
┌────────────────── 信任邊界：Internal ───────────────────┐
│                           ▼                              │
│    (Auth Service) ←── (HR Core Service)                  │
│         │                    │                           │
│         ▼                    ▼                           │
│    [Redis Cache]      [PostgreSQL DB]                    │
│                                                          │
└─────────────────────────────────────────────────────────┘
                           │ LDAPS
┌────────────────── 信任邊界：Enterprise ─────────────────┐
│                           ▼                              │
│              [Active Directory]                           │
│                                                          │
└─────────────────────────────────────────────────────────┘

4. 信任邊界識別

📝 範本

📖 使用說明

• 信任邊界是安全等級不同的兩個區域之間的分界線
• 跨越信任邊界的資料流是威脅分析的重點（攻擊最可能發生處）
• 每條跨邊界的資料流都需要相應的保護機制

💡 範例

5. STRIDE 威脅分析

📝 範本

STRIDE 分類說明

威脅列表

📖 使用說明

• 逐一對每個 DFD 元素（處理程序、資料儲存、資料流）套用 STRIDE
• 外部實體通常只分析 S（Spoofing）和 R（Repudiation）
• 資料儲存通常分析 T、I、D
• 處理程序所有 STRIDE 類型都適用
• 每個威脅需具體描述攻擊場景（非泛泛而談）

💡 範例

6. 威脅風險評估

📝 範本

風險評分標準（DREAD 或自訂）

風險評估結果

📖 使用說明

• 風險等級 = 影響 × 可能性 × 可利用性（或加總取平均）
• 高風險（7-9分）：必須在上線前處置
• 中風險（4-6分）：計畫性處理，可接受短期風險
• 低風險（1-3分）：記錄並持續監控
• 風險評估結果決定緩解措施的優先順序

💡 範例

7. 緩解措施

📝 範本

📖 使用說明

• 每個高/中風險威脅都需要對應的緩解措施
• 緩解策略分為四種：
  • 消除：重新設計，完全移除威脅（最佳）
  • 緩解：降低影響或可能性（最常見）
  • 轉移：轉移風險給第三方（保險/外包）
  • 接受：記錄風險，不處理（需管理層核准）
• 緩解措施需連結到安全需求清單（SecurityRequirements）中的具體需求

💡 範例

8. 殘餘風險

📝 範本

📖 使用說明

• 殘餘風險 = 實施緩解措施後仍無法完全消除的風險
• 所有殘餘風險需經管理層正式核准（Risk Acceptance）
• 殘餘風險需定期重新評估（至少每季度）
• 高殘餘風險應有補償性控制措施

💡 範例

9. 威脅追溯矩陣

📝 範本

📖 使用說明

• 追溯矩陣確保每個威脅都能向前追溯到架構元素、向後追溯到測試案例
• 完整鏈路：DFD 元素 → 信任邊界 → 威脅 → 安全需求 → 緩解措施 → 測試驗證
• 若某威脅沒有對應的測試案例，代表測試覆蓋不足

💡 範例

10. 附錄

📝 範本

10.1 威脅建模會議記錄

10.2 參考資料

📖 使用說明

• 會議記錄保留威脅建模決策的可追溯性
• 建議威脅模型每個 Sprint 或重大架構變更時更新
• 工具推薦：Microsoft Threat Modeling Tool (免費)、OWASP Threat Dragon (開源)

💡 範例

10.1 威脅建模會議記錄

📌 範本使用注意事項

1. 本範本依據 Microsoft STRIDE 與 ISO/IEC 27005:2022 風險管理框架編製
2. 威脅模型需在架構設計確定後、開發實作前完成（Shift-Left Security）
3. 搭配「安全需求清單」使用 — 威脅分析結果需轉化為安全需求
4. 搭配「測試計畫」使用 — 高風險威脅需有對應的安全測試案例
5. 每次重大架構變更或新功能增加時，需重新進行威脅建模