STRIDE威胁建模方法最早发表于2006年11月的《MSDN杂志》，作者是微软的工程师Shawn Hernan、Scott Lambert 、Tomasz Ostwald 和 Adam Shostack。那我们为什么要进行威胁建模？ 如何使用数据流图对系统进行威胁建模？如何减轻威胁？接下来本文展开逐一介绍。
1. 安全设计原则
在介绍STRIDE方法前我们需要先了解下安全设计的原则，设计安全软件的一个问题是，不同的群体对安全性的看法不同：
- 软件开发人员主要从代码质量方面考虑安全性，而网络管理员则考虑防火墙、事件响应和系统管理；
- 学术界可能主要根据经典的Saltzer和Schroeder设计原则、安全模型或其他抽象概念来考虑安全性。
当然，以上考虑在构建安全系统时都很重要。常用的安全设计原则如下：
| 原则 | 解释 |
|---|---|
| 开放式设计 | 假设攻击者掌握了来源和规格 |
| 默认安全 | 系统或软件应默认配置为安全状态，即默认情况下不开启不必要的服务或功能，减少潜在的攻击面 |
| 最小权限 | 系统中的每个组件或用户只应拥有完成其任务所需的最小权限集合。这样可以减少潜在的安全风险，因为即使攻击者获取了某些权限，其影响范围也会受到限制 |
| 纵深防御 | 在多个层面上实施安全措施，以确保即使一个安全层被攻破，其他层仍能提供保护。这包括物理安全、网络安全、应用安全等多个层面 |
| 透明性和可理解性 | 安全机制应尽可能透明，易于理解和操作，以减少人为错误的可能性 |
| 经济性 | 安全机制设计尽可能简单短小，从而在排查缺陷、检测漏洞时代码更容易处理 |
| 可审计性 | 记录和审计系统活动，以便在发生安全事件时能够追踪和分析。这包括日志记录、监控和报告机制。 |
安全意味着系统具有机密性、完整性和可用性的特性（即CIA特性），用户得到了正确的身份验证和授权，并且不可否认的。（PS：CIA加上份验证和授权、不可否认下文简称为CIA变体）下图解释了每个属性：
确保应用具有这些安全属性的一种方法就是使用STRIDE进行威胁建模，STRIDE 是六个主要威胁类别的首字母缩写：
- 欺骗（Spoofing）：冒充某人或某物
- 篡改（Tampering）：未经授权更改数据
- 否认（Repediation）：不宣称对执行的操作负责
- 信息泄露（Information Disclosure）：在未获得权限的情况下查看数据
- 拒绝服务（Denial of Service）：使系统过载
- 权限提升（Elevation of Privilege）：拥有本不应拥有的权限
STRIDE代表的六种威胁，每种威胁都违反了 “CIA 变体” 的特定属性，具体如下：
2. 威胁建模
2.1. 什么是威胁建模
威胁建模是一种有助于保护系统、应用程序、网络和服务的有效技术。 威胁建模使用以图形形式演示系统工作方式的数据流关系图。 之后，它应用一个框架来帮助你发现和修复安全问题。它可帮助你在开发生命周期的早期确定潜在的威胁和降低风险策略。
威胁建模方法由微软的安全工程和通信小组开发。与SDLC的其他部分一样，威胁建模也在不断发展，并将应用于新的环境中。当创建自己的安全代码开发流程时，这种方法可能会很好地作为基线，实际上很多公司都参照了微软的威胁建模方法制定了自己的基线。
2.2. 为什么要进行威胁建模？
无论你是在构建一个新系统还是更新现有系统，你都需要考虑入侵者如何攻击它，然后在系统的设计和实施阶段建立适当的防御。
微软内部通过一种名为威胁建模的技术来设计安全系统，即对系统设计或体系结构进行系统审查，以发现和纠正设计级别的安全问题。威胁建模是安全开发生命周期中不可或缺的一部分。
3. 威胁建模和STRIDE
威胁建模是Microsoft安全开发生命周期（SDL）的核心元素。这是一种工程技术，可以用来帮助您识别可能影响应用程序的威胁、攻击、漏洞和对策。我们可以使用威胁建模来塑造应用程序的设计，满足公司的安全目标，并降低风险。STRIDE方法是执行威胁建模的理论依据。
为了遵循STRIDE，我们要将系统分解为相关组件，分析每个组件对威胁的易感性，并减轻威胁。然后重复这个过程，直到我们对任何剩余的威胁都感到满意。这时我们才可以认为系统是安全的。
我们无法证明当组件组成一个系统时，对欺骗威胁单独免疫的组件之间的相互作用不易受到欺骗威胁的影响。事实上，只有当系统被连接起来以创建更大的系统时，威胁才会经常出现。
STRIDE威胁建模的流程如下：
- 定义安全需求
- 绘制数据流图
- 识别潜在威胁
- 制定缓解措施
- 进行安全验证
3.1. 定义安全需求
需求定义阶段是一个关键步骤，它定义你的应用程序是什么，以及它发布后可用来做什
么。 在需求阶段，就要考虑在你的应用程序中构建的安全控制措施，以确保发布并部署安全的应用程序。
此阶段是考虑基础的安全和隐私问题的最佳时间。 在项目开始时定义可接受的安全和隐
私级别有助于团队：
- 了解与安全问题相关的风险。
- 在开发过程中确定和修复安全 bug。
- 在整个项目中应用确定的安全和隐私级别。
在编写对应用程序的要求时，请确保考虑有助于保护应用程序和数据安全的安全控制措
施。
3.2. 绘制数据流图（DFD）
数据流图（DFD）通常用于以图形方式表示系统，将系统分解为多个部分，并显示每个部分不易受到相关威胁的影响。
DFD 使用由四个元素组成的标准符号集：
- 数据流
- 数据存储
- 过程
- 交互程序
对于威胁建模，我们还添加了扩展元素：信任边界。下图则显示了这些符号。
注：
- 交互程序是系统的终点：人员、Web服务和服务器。一般来说，它们是系统范围之外的数据提供者和消费者，但显然与系统相关。
- 信任边界可能是最主观的：它们代表了可信和不可信元素之间的边界。信任是复杂的，你的牙医会给你牙齿，你的父母会给你零花钱，但你可能不相信你的牙医能给你零花钱。
正确绘制及使用DFD是正确使用威胁模型的关键。
3.3. 识别潜在威胁
需使用数据流图查找针对系统的潜在威胁，STRIDE威胁清单如下：
| 威胁 | 定义 | 问题 | 威胁示例 |
|---|---|---|---|
| 欺骗 | 攻击者冒充某人或某物 | 通信的双方是否都通过了身份验证？ | 通过看似合法的帐户向用户发送一封带有恶意链接和附件的电子邮件，以捕获用户的凭据、数据和设备访问权限 |
| 篡改 | 攻击者在未经授权的情况下更改数据 | 如何得知某人无法更改传输中的数据、正在使用的数据或静态数据？ | 通过弱 API 调用处理修改内存，导致崩溃和泄漏敏感错误消息 |
| 否认 | 攻击者声称尚未执行任何操作 | 每个操作是否可以绑定到标识？ | 声称没有删除数据库记录 |
| 信息泄露 | 攻击者看到了不应看到的数据 | 如何得知某人无法看到传输中的数据、正在使用的数据或静态数据？ | 访问安全控制较弱的未授权文档和文件夹 |
| 拒绝服务 | 攻击者使你的系统崩溃 | 系统中是否存在资源受限的区域？ | 向网络发送大量请求 |
| 权限提升 | 攻击者未经授权而可访问数据 | 如何得知某人可以执行此操作？ | 利用输入处理逻辑或内存中的弱点来提取数据 |
数据流图中的每个元素（处理过程、数据存储、数据流和外部交互）都有一组易受威胁的因素，如下表所示：
| 元素 | 仿冒 | 篡改 | 否认 | 信息泄露 | 拒绝服务 | 权限提升 |
|---|---|---|---|---|---|---|
| 数据流 | X | X | X | |||
| 数据存储 | X | X | X | |||
| 处理过程 | X | X | X | X | X | X |
| 外部交互 | X | X |
3.4. 制定缓解措施
在此阶段，需要决定如何处理所有威胁。 每个 STRIDE 威胁都对应到一项或多项安全控制，这些控制措施提供不同的功能和操作类型。
| 威胁 | 安全控制 | 安全控制示例 |
|---|---|---|
| 欺骗 | 身份验证 | 发送和接收使用数字签名进行签名的消息，以验证来源并确保消息完整性 |
| 篡改 | 完整性 | 验证输入以防止处理恶意有效负载和错误处理意外行为 |
| 否认 | 不可否认性 | 创建和保护包含用户操作和时间戳的安全日志 |
| 信息泄露 | 机密性 | 应用访问控制列表，以确保合适的用户可以访问适当的数据 |
| 拒绝服务 | 可用性 | 使用弹性资源管理不断增加或减少的使用量 |
| 权限提升 | 授权 | 使用最少的访问量运行服务 |
可能有可以立即减少或完全消除多个威胁的安全控制。 例如，使用 SSL/TLS 创建安全传输通道，以帮助防止恶意数据修改或泄露。
在上一阶段（识别潜在威胁）中发现的问题，可以使用以下其中一个解决方案。 它们在不同组织之间存在略微差异：
| 解决方案 | 描述 |
|---|---|
| 减轻 | 通过使用 bug 修复或重新设计来减轻或消除威胁影响和严重性。 |
| 转移 | 将问题分配给另一个系统或团队。 |
| 消除 | 去除系统中包含问题的部分。 |
| 接受 | 在没有解决方法的情况下接受风险。 此解决方案需要授权风险决策者的批准。 此决定可能基于威胁严重性。 严重威胁可能需要高级领导的批准，而深层防御风险可能需要高级工程师批准。 与你的团队交流以获得战略指导。 |
3.5. 进行安全验证
验证阶段是威胁建模过程的最后一步，通常发生在部署系统之前。 它涉及到确保满足要求、验证假设以及准备好安全控制。
3.5.1. 验证要求和设置默认值
首先，验证是否满足第一阶段创建的所有要求。
示例：
- 网络安全计划
- 机密管理解决方案实施
- 日志记录和监视系统
- 标识和访问控制
然后，确保更改云提供商、操作系统和组件的默认配置设置，以满足所有安全要求。
3.5.2. 执行验证
执行验证会涉及运行手动和自动验证。 在微软内部，系统在部署前要执行一个验证流程。 该流程可能包括自动扫描程序、代码评审和渗透测试。 可以在每次部署之前或隔一定的时间（如每 6 - 12 个月）强制执行该过程。
4. 结论
设计安全的软件可能很困难，但与任何挑战一样，一个好的策略是将问题分解为更容易解决的较小部分。对于高风险活动，将STRIDE模型与威胁建模结合使用就是这样一种方法。微软内部的许多团队中已经使用了这个模型。
在开发安全软件时，建议将威胁建模作为流程的关键部分，特别是本文中介绍的STRIDE模型。但关键是要找到一种适合你的方法，在设计的早期应用它，记住任何组件都可能失败，并进行必要的研究，以确保你已经考虑到已知的攻击模式。
最后，设计只是构建安全软件的一部分。执行支持、实施、测试、构建和交付以及服务和维护都在系统的最终安全性方面发挥着至关重要的作用。
若大家对微软的SDL安全开发生命周期感兴趣，可以深入学习如下两篇文档：
- 微软SDL安全开发生命周期总体介绍.pptx（共26页，访问密码：6277）
- 微软安全开发生命周期详细指导文档.pdf （共285页，访问密码: 6277）
5. 参考链接
- uncover-security-design-flaws-using-the-stride-approach
- https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling
- https://learn.microsoft.com/zh-cn/training/modules/tm-introduction-to-threat-modeling/4-step-3-fix-phase
推荐阅读：
- 安全设计 | 68家国内外科技巨头和安全巨头参与了CISA发起的安全设计承诺，包含MFA、默认密码、CVE、VDP等七大承诺目标
- 安全设计 | Microsoft 威胁建模工具Threat Modeling Tool安装、使用及威胁生成原理详解（文末附样例）
