threat-modelling

威胁建模（STRIDE / SDL）

威胁建模是 Microsoft 安全开发生命周期（SDL）中的一项结构化实践，用于在设计早期识别、沟通并缓解威胁——在编写代码之前，并在设计发生重大变化时重新进行。

适用场景

设计新系统、对现有系统进行重大更改、评估架构的安全性，或开展正式的安全设计审查。

请勿将此技能用于：

• 组织范围内的安全架构或路线图（使用 security-architecture）
• 运行时检测或事件响应（使用 sentinel / defender-xdr）
• 代码级漏洞扫描（使用 SAST/DAST 工具）

STRIDE - 六大类别一览

字母	威胁	被破坏的安全属性	常见缓解措施
S	欺骗	身份验证	MFA、双向 TLS、签名令牌
T	篡改	完整性	签名、哈希、写保护存储
R	抵赖	不可否认性	审计日志、签名交易
I	信息泄露	机密性	加密（静态和传输中）、授权
D	拒绝服务	可用性	速率限制、配额、自动扩缩、WAF
E	权限提升	授权	最小权限、输入验证、沙箱

**经验法则：**针对数据流图中的每个元素，逐一检查 全部六种 STRIDE 类别。因为“这里不适用”而跳过某些类别，是漏掉真实威胁的最常见原因。

方法

1. 定义范围和假设 - 说明哪些内容在范围内、哪些不在范围内、信任模型（你信任谁做什么），以及要保护的资产。没有范围界定的威胁模型只是一种观点。 验证：一页范围说明列出了资产、参与者、范围内组件，以及明确的范围外项目。
2. 构建数据流图（DFD） - 绘制外部实体、进程、数据存储、数据流和 信任边界。信任边界是权限或数据在主体之间交互的位置——大多数威胁都发生在那里。 验证：每条跨越信任边界的数据流都已突出标记；没有遗漏任何跨越边界的数据流。
3. 按元素使用 STRIDE 列举威胁 - 针对每个元素或数据流，逐一检查全部六种 STRIDE 类别。对于每项适用的威胁，写一句描述。 验证：已根据全部六个字母评估每个元素；你可以展示覆盖矩阵。
4. 按风险对威胁排序 - 使用 DREAD，或根据可能性和影响进行简单的高／中／低评级。进行分级排序，让团队优先处理最高级别的威胁。 验证：前 10 项威胁列表按风险排序，而非按发现顺序排列。
5. 为每项威胁制定具体的缓解措施 - 缓解措施 = 一项具体控制（MFA、输入验证、签名、加密、速率限制、最小权限）加上负责人和目标日期。笼统地说“我们应该加强安全”不算缓解措施。 验证：每项最高级别的威胁都有明确的缓解措施、负责人和实施目标。
6. 验证缓解措施已实施 - 在构建期间，确认每项缓解措施都已落实到代码、配置或流程中。在审查期间，测试缓解措施是否确实能阻止威胁（负向测试）。 验证：测试套件或安全审查清单中包含缓解措施测试。
7. 发生重大变更时重新建模 - 将威胁建模视为 迭代过程。每当出现新的信任边界、新的外部集成、新的数据分类或重大重构时，都应重新建模受影响的部分。 验证：团队有一份书面的触发条件清单，并在最近一次触发事件后更新了模型。
8. 在适用时使用工具 - Microsoft Threat Modeling Tool 可自动为 DFD 中的每个元素生成 STRIDE 威胁。威胁建模卡片／模板适用于不使用工具的研讨会。

防护原则

• 威胁建模是迭代式的——每次重大设计变更后都要重新审视，而不是只在项目启动时进行。设计阶段冻结的模型与最终交付的系统毫无关系。
• 明确记录假设和范围外事项——未记录的假设会成为来年的安全事故。
• 将威胁与可执行的缓解措施关联起来，并指定负责人和日期，而不是停留在抽象风险上。
• 针对每个元素逐一检查 STRIDE 的六个字母——跳过类别是最常见的疏漏。
• 威胁建模不能替代代码审查、依赖扫描或渗透测试。它通过明确测试重点来补充这些工作。
• 产出是达成共识，而不是文档。如果开发团队无法口头说明主要威胁，就说明模型尚未真正落实。

常见反模式

• “我们在项目启动时做过威胁建模”——之后再也没有更新。被建模的系统早已不复存在。
• 一份包含 200 个威胁却没有优先级排序的电子表格。 什么问题都得不到修复，因为所有问题看起来都一样。交付成果应是完成分类排序。
• 因为“并不适用”而跳过 STRIDE 字母。 要逐项检查；如果某个类别确实不适用，就记录原因，不要默默跳过。
• 缓解措施 = “使用 TLS”。 这不算缓解措施。缓解措施 = 在网关强制使用 TLS 1.2+ 和密码套件 X，由测试 Y 验证，并由 Z 负责。
• 把威胁模型当作安全团队的产物，工程团队从不查看。模型必须由开发团队负责；安全团队负责协助。

示例提示词

• Run a STRIDE threat model with a data flow diagram and trust boundaries.
• Use the Microsoft Threat Modeling Tool for a design review.
• How do I identify threats and map mitigations for a new system?
• Conduct an SDL threat modelling session.
• What does the E in STRIDE cover and how is it mitigated?

Microsoft Learn

• Microsoft Threat Modeling Tool： https://learn.microsoft.com/azure/security/develop/threat-modeling-tool
• Threat Modeling Tool 威胁参考： https://learn.microsoft.com/azure/security/develop/threat-modeling-tool-threats
• Threat Modeling Tool 缓解措施： https://learn.microsoft.com/azure/security/develop/threat-modeling-tool-mitigations
• Microsoft SDL： https://www.microsoft.com/securityengineering/sdl
• SDL 实践： https://www.microsoft.com/securityengineering/sdl/practices