Threat Modeling 威胁建模入门
什么是威胁建模？
威胁建模是一种结构化的安全分析方法，用于在系统设计阶段识别、评估并缓解潜在的安全威胁。它不是一次性的活动，而是一个贯穿软件开发生命周期（SDLC）的持续过程。通过尽早发现架构缺陷，开发团队可以避免后期昂贵的漏洞修复，并将安全设计融入产品基因。
为什么威胁建模重要？
- 前置安全决策：在设计图纸上解决问题，比在已部署的系统中修补漏洞成本低数十倍。
- 对齐业务目标：将有限的资源优先投入到保护最有价值的资产上。
- 满足合规要求：许多行业标准（如ISO 27001、SOC 2、PCI DSS）都要求实施威胁建模。
- 培养安全意识：让开发、运维和产品团队共同理解系统面临的攻击面。
威胁建模的核心概念
在深入实践之前，需要明确四个关键问题，它们构成了威胁建模的主干：
- 我们正在构建什么？ – 建立系统架构图与数据流图。
- 哪里可能出错？ – 识别潜在的威胁来源和攻击向量。
- 我们要怎么办？ – 评估风险并决定处置措施（缓解、转移、接受或避免）。
- 我们做得好吗？ – 验证措施的有效性，并不断迭代。
主流的威胁建模方法论
STRIDE 模型
由微软提出的经典威胁分类，帮助系统化地思考威胁类型：
- Spoofing（假冒身份）：攻击者伪装成合法用户或服务。
- Tampering（数据篡改）：未经授权修改数据或代码。
- Repudiation（抵赖）：用户执行了操作但可以否认，缺乏不可否认性。
- Information Disclosure（信息泄露）：敏感数据暴露给未授权实体。
- Denial of Service（拒绝服务）：资源被耗尽，导致合法用户无法使用。
- Elevation of Privilege（权限提升）：攻击者获取到更高级别的权限。
适用场景：软件系统级别的威胁分析，尤其适合Web应用、微服务和API。
DREAD 风险评估模型
在识别出威胁后，用DREAD进行风险评级以排定优先级：
- Damage potential（潜在破坏力）：如果威胁成真，有多大危害？
- Reproducibility（可复现性）：攻击复现的难易度。
- Exploitability（可利用性）：发动攻击的技术难度。
- Affected users（受影响用户数）：多少用户会被波及。
- Discoverability（可发现性）：漏洞被发现的概率。
通常对每项进行1-10评分，加权后得出综合风险值，得分越高越优先处理。
PASTA 方法论
面向攻击者视角的流程化攻击模拟与威胁分析（Process for Attack Simulation and Threat Analysis）。分为七个阶段：
- 定义业务目标
- 定义技术范围
- 应用分解与分析
- 威胁分析
- 漏洞与弱点分析
- 攻击建模与模拟
- 风险分析与对策
PASTA强调将风险与业务影响直接挂钩，适合大型组织或高安全性要求的系统。
LINDDUN 方法论
专门聚焦于隐私威胁建模，对应七个隐私威胁类型：
- Linkability（可关联性）
- Identifiability（可识别性）
- Non-repudiation（不可否认性）
- Detectability（可检测性）
- Disclosure of information（信息泄露）
- Unawareness（用户不知情）
- Non-compliance（不合规）
在GDPR等隐私法规背景下，LINDDUN 对于涉及个人数据的系统尤为关键。
威胁建模分步指南（用数据流图进行 STRIDE 分析）
下面以最常见的 STRIDE 配合数据流图（DFD）为例，展示一次轻量级威胁建模的过程。
第一步：定义范围与绘制架构图
绘制一个高层次的系统数据流图，标明以下要素：
- 外部实体（External Entity）：用户、第三方服务、其他系统。
- 过程（Process）：服务器应用、微服务、函数。
- 数据存储（Data Store）：数据库、文件系统、缓存。
- 数据流（Data Flow）：实体之间传递数据的路径。
- 信任边界（Trust Boundary）：数据流跨越不同权限级别的分界线（如从Internet到内网）。
工具推荐：白板、draw.io、PlantUML、Mermaid 或专门的威胁建模工具（如 Microsoft Threat Modeling Tool、OWASP Threat Dragon）。
第二步：对每个元素应用 STRIDE
沿着数据流图逐个元素审查，针对每个信任边界交叉处的元素提出 STRIDE 问题。例如：
- 外部实体（如“用户”）：是否存在身份假冒风险？用户凭证如何管理和验证？
- 过程（如“Web API”）：输入是否可能被篡改（SQL注入/XSS）？异常处理是否能防止信息泄露？
- 数据存储（如“用户数据库”）：数据静态加密了吗？日志是否能防止抵赖记录？
- 数据流（如“用户凭据经HTTPS传输”）：传输过程中是否有机密性保护？防篡改吗？
可以列出威胁清单，格式如下：
| 元素 | 威胁类型 | 威胁描述 | 缓解建议 |
|---|---|---|---|
| 登录API (过程) | 假冒 | 攻击者暴力破解或利用凭证填充 | 实施多因素认证、速率限制、账户锁定 |
| 用户数据 (数据流, HTTP) | 信息泄露 | 中间人拦截未加密流量 | 强制使用HTTPS，启用HSTS |
| 文件存储 (数据存储) | 篡改 | 直接上传恶意文件覆盖系统文件 | 文件类型白名单校验、隔离存储权限、病毒扫描 |
第三步：评估与处置风险
使用 DREAD 或简单的“高/中/低”矩阵对每个威胁进行评级。并非所有威胁都需要立即修复，结合业务上下文选择策略：
- 缓解：采取安全控制措施降低风险（如增防火墙、补丁、重构代码）。
- 转移：将风险转移给第三方（如购买网络安全保险）。
- 接受：当风险水平可承受，或处置成本远大于损失时，正式记录并接受。
- 避免：通过更改设计完全消除威胁（如移除某个高危功能）。
第四步：生成安全需求与测试用例
将高优先级的缓解措施转化为具体的安全需求，并驱动测试：
- 安全需求：“所有跨信任边界的请求必须经过强身份认证。”
- 测试用例：“使用无效token调用API端点，验证是否返回401 Unauthorized。”
输出物归档后，应与开发任务关联，并纳入CI/CD流水线的安全检查点。
常见工具速览
| 工具 | 特点 | 适用阶段 |
|---|---|---|
| Microsoft Threat Modeling Tool | 免费，集成STRIDE，支持自动分析 | 设计阶段 |
| OWASP Threat Dragon | 开源，在线/桌面版，强DFD编辑 | 设计阶段 |
| IriusRisk | 商业工具，与Jira等集成，规模化 | 企业级全流程 |
| pytm | Python 编写文本式DFD，适合DevSecOps | 设计自动化 |
| Threatspec | 通过在代码中注释直接建模 | 开发阶段 |
如何在团队中落地威胁建模
从小处着手，融入日常流程
- 选择一次迭代试行：挑选一个高危特性或新服务，利用1小时完成一次轻量级建模。
- 角色融合：安全专家引导，开发、架构师、产品负责人共同参与。
- 定义就绪检查：将威胁建模加入“Definition of Done”或“Definition of Ready”，不完成建模不允许进入开发。
建立知识库与复用
将发现的威胁模式沉淀为内部“威胁库”和“安全问题检查表”。下次建模时可以快速参照，并保证一致性。此外，定期回顾并修复以往模型中的遗漏。
自动化与左移
将威胁模型作为代码管理（如使用pytm或基于Mermaid的图表），并集成到版本控制中。在代码合并请求时，触发自动化规则检查数据流变化是否引入了新的信任边界，若存在则标记需要评审。
关键要点总结
- 威胁建模是前瞻性的安全实践，应尽早且频繁地执行。
- STRIDE 是入门的最佳框架，与数据流图结合可覆盖绝大多数软件威胁。
- 工具只是辅助，真正的价值在于团队对系统威胁的共同理解与安全思维的建立。
- 完美主义是敌人：初期不求面面俱到，先建立持续迭代的节奏。
威胁建模不是一次性的文档工作，而是一种将安全内化为设计肌肉记忆的文化实践。从今天开始，拿起白板，和你的团队一起画出第一张数据流图吧。