威胁建模（Threat Modeling）#

2017 年，Twitter 发生了一起严重的数据泄露事件：超过 3000 万用户账号被黑客获取。事后调查发现，问题根源在于系统设计阶段从未进行过系统的威胁分析。如果 Twitter 在设计双因素认证时，能够系统性地分析「攻击者如何绕过认证流程」「session token 泄露的场景有哪些」，这场灾难或许可以避免。

威胁建模（Threat Modeling）正是这样一种系统性方法：它帮助我们在设计阶段识别系统的潜在威胁，评估风险优先级，并在架构层面做出更安全的设计决策。这不是一项可选的「锦上添花」工作，而是安全软件开发的必要环节。

#一、威胁建模的本质

威胁建模的核心回答三个问题：

1. 系统面临什么威胁？ —— 我们在防御什么
2. 这些威胁的严重程度如何？ —— 我们应该优先关注什么
3. 如何应对这些威胁？ —— 我们应该做什么

#1.1 威胁建模不是一次性活动

很多团队犯的错误是：项目开始时做一次威胁建模，然后把它当作「已完成」的任务归档。实际上，威胁建模应该是持续的活动，随着系统演进、新的攻击手法出现、新的业务场景上线，威胁模型需要不断更新。

flowchart LR
    A[初始威胁建模] --> B[开发阶段]
    B --> C[需求变更]
    C --> A
    B --> D[发布后监控]
    D --> |发现新威胁| A

#1.2 威胁建模的时机

• 系统设计初期：确定信任边界和安全架构
• 功能重大变更：评估新功能带来的新威胁
• 技术架构升级：评估新技术的安全影响
• 安全事件后：复盘并更新威胁模型
• 定期安全评审：至少每年一次

#二、威胁建模的核心步骤

威胁建模是一个迭代的过程，业界最常用的框架是微软提出的「STRIDE 建模方法」，包含四个核心步骤：

flowchart TB
    subgraph 步骤一
        A1[分解系统]
    end
    
    subgraph 步骤二
        B1[识别威胁]
        B2[STRIDE 方法]
        B3[攻击树分析]
    end
    
    subgraph 步骤三
        C1[缓解威胁]
        C2[安全控制措施]
        C3[风险评估]
    end
    
    subgraph 步骤四
        D1[验证缓解]
        D2[测试验证]
        D3[文档记录]
    end
    
    A1 --> B1
    B1 --> C1
    C1 --> D1
    D1 --> |迭代| A1

#2.1 步骤一：分解系统

分解系统的目的是理解系统的组成、数据流和处理逻辑。这一步的核心产出是数据流图（Data Flow Diagram, DFD）。

DFD 的四个核心元素：

DFD 绘制示例：

flowchart LR
    subgraph 外部
        USER[用户]
        BANK[银行系统]
    end
    
    subgraph 系统内部
        AUTH[认证服务]
        API[业务 API]
        DB[(数据库)]
    end
    
    USER -->|登录请求| AUTH
    AUTH -->|验证| API
    API -->|读写| DB
    API -->|查询余额| BANK
    BANK -->|响应| API

信任边界的识别：

信任边界（Trust Boundary）是数据流跨越不同信任级别的位置。在信任边界处，数据需要特别保护。

常见的信任边界：

• 用户输入到系统内部
• 系统内部到外部系统
• 不同安全域之间（如 DMZ 到内网）
• 应用程序到数据库

#2.2 步骤二：识别威胁

识别威胁是威胁建模的核心环节。常用的方法包括：

#2.2.1 STRIDE 方法

STRIDE 是微软提出的威胁分类框架，将威胁分为六类：

#2.2.2 攻击树（Attack Tree）

攻击树是一种自顶向下的威胁分析方法，从攻击者的目标出发，逐层分解达成目标所需的步骤。

flowchart TB
    ROOT["获取管理员权限"]
    
    ROOT --> A1["通过 SQL 注入"]
    ROOT --> A2["通过 XSS 窃取会话"]
    ROOT --> A3["通过暴力破解密码"]
    
    A1 --> A1A["找到注入点"]
    A1 --> A1B["绕过 WAF"]
    
    A2 --> A2A["诱使管理员点击链接"]
    A2 --> A2B["窃取 HttpOnly Cookie"]
    
    A3 --> A3A["社工获取邮箱"]
    A3 --> A3B["暴力破解弱密码"]
    
    style ROOT fill:#ff6b6b,color:#fff
    style A1 fill:#ffd93d
    style A2 fill:#ffd93d
    style A3 fill:#ffd93d

攻击树的价值在于从攻击者视角思考问题，帮助团队理解攻击者可能的路径，从而在关键节点设置防御。

#2.3 步骤三：缓解威胁

识别威胁后，需要评估每个威胁的风险，并决定如何应对。

风险评估矩阵：

威胁缓解策略：

#2.4 步骤四：验证缓解

缓解措施实施后，需要验证其有效性。

验证方法：

1. 代码审查：检查安全控制是否正确实现
2. 渗透测试：模拟攻击验证防御是否有效
3. 自动化测试：将安全测试集成到 CI/CD
4. 文档更新：记录威胁模型变更

#三、威胁建模工具

#3.1 Microsoft Threat Modeling Tool

微软提供的免费威胁建模工具，适合 Windows 开发环境。

优点：

• 免费、易上手
• 内置 STRIDE 分类
• 自动生成威胁报告
• 支持导出标准格式

缺点：

• 仅支持 Windows
• 协作功能有限

#3.2 OWASP Threat Dragon

OWASP 维护的开源威胁建模工具，支持跨平台使用。

优点：

• 开源免费
• Web 版本可用
• 支持团队协作
• 活跃社区支持

#3.3 IriusRisk

商业威胁建模平台，提供完整的威胁管理和跟踪功能。

优点：

• 丰富的威胁库
• 自动生成安全需求
• 与 Jira 等工具集成
• 完整的风险管理流程

#3.4 工具对比

#四、威胁建模的输出物

威胁建模的产出应该包括以下文档：

#4.1 数据流图（DFD）

系统的技术架构图，标注所有外部实体、数据流、数据存储和进程。

#4.2 信任边界图

在 DFD 基础上标注所有信任边界，明确哪些数据流需要特别保护。

#4.3 威胁列表

#4.4 安全需求

从威胁分析中推导出的安全需求，应该纳入产品需求管理。

#4.5 缓解措施跟踪

记录每个威胁的缓解状态，确保所有高风险威胁都得到妥善处理。

#五、威胁建模的常见误区

#5.1 误区一：一次建模，终身受用

系统是活的，威胁也在演进。威胁模型必须随着系统变化而更新。

#5.2 误区二：追求完美，迟迟不动

威胁建模不可能穷尽所有威胁，关键是建立流程并持续改进。不要因为担心遗漏而迟迟不开始。

#5.3 误区三：只关注技术威胁

业务逻辑漏洞、社会工程攻击、物理安全等非技术威胁同样重要。

#5.4 误区四：建模与开发脱节

威胁建模的输出必须转化为具体的开发任务，否则就是空中楼阁。

#六、轻量级威胁建模实践

对于小型项目或时间紧迫的情况，可以采用轻量级威胁建模方法：

flowchart TB
    A[回答三个问题] --> B["系统有什么价值？"]
    A --> C["系统如何被攻击？"]
    A --> D["我们做足防御了吗？"]
    
    B --> E["数据流图（简化版）"]
    C --> F["STRIDE 快速检查"]
    D --> G["安全控制清单"]
    
    E --> H[威胁列表]
    F --> H
    G --> H

简化版 STRIDE 检查表：

#思考题

问题 1：在为一家电商平台进行威胁建模时，你发现系统需要处理大量用户上传的图片。作为安全架构师，你会关注哪些威胁？如何在 DFD 中标注这些风险？

问题 2：在敏捷开发模式下，Sprint 周期通常只有 1-2 周。如何在快速迭代中有效实施威胁建模，避免成为开发瓶颈？