理解威胁建模：方法与实战（STRIDE 和 Attack Trees）

家人们

点击上方蓝字关注我

什么是威胁建模？

威胁建模使用系统化、条理清晰的方法，来更具前瞻性的识别软硬件系统中的潜在威胁和漏洞。其目标是在软件开发生命周期的早期阶段（如设计阶段）识别潜在的安全风险，以降低后期风险处理的难度。

为什么说威胁建模很重要呢？因为理论上它能够在软件开发生命周期的早期阶段识别安全问题，减少后期修复的成本和时间。此外，威胁建模提供了一种系统化的方法来评估安全风险，帮助发现传统测试方法和代码审查可能忽略的设计缺陷，根据威胁的严重性和可能性对安全措施进行优先级分配，确保资源的有效利用。最后，威胁建模使安全团队能够更好地理解系统中的安全漏洞，并制定相应的防护策略，从而提高系统的整体安全性。

现状

但是（坏就坏在但是身上了），互联网厂商或者中小型企业在开发软件时往往采用敏捷开发方法，这种方法过度强调快速交付和迭代更新。而且这种快速开发节奏可能导致很多安全措施，特别是威胁建模阶段的缺失。要知道，在一周发三四个版时去追求大而全的威胁建模，我们的 +1 可能直接让我们回家种田去了...

所以在实际项目中做这件事的时候，就需要有权衡，我们需要通过持续评估和快速反馈来保持安全与开发速度的平衡，优先识别和处理最关键的安全风险，确保在每个迭代中逐步提升系统的安全性，而不是试图在一开始就解决所有潜在问题（这也是不可能做到的）。

常用威胁建模方法论

安全团队在做威胁建模时，要参考业界主流方法论，根据需求做相应的精简、评估和反馈，我就介绍一些主流常用的模型吧，大家可以简单的看一下，看完这些模型我们再根据实际情况来选用，后面会说到这一点。

STRIDE 模型是由微软提出的一种威胁分类方法，STRIDE 是六类威胁的缩写，分别是：

Spoofing（欺骗）：冒充他人身份的威胁

Tampering（篡改）：对数据或系统进行未经授权的修改

Repudiation（抵赖）：行为发生后无法追溯，否认某些行为

Information Disclosure（信息泄露）：未授权访问或泄露敏感信息

Denial of Service（拒绝服务）：使系统无法正常提供服务

Elevation of Privilege（权限提升）：获得更高的权限来执行未经授权的操作

DREAD 模型是一种用于评估和量化威胁风险的模型，其名称来自五个风险因素：

Damage Potential（损害潜力）：威胁可能造成的损害程度

Reproducibility（重现性）：威胁被再次利用的难易程度

Exploitability（利用难度）：利用该威胁的难度

Affected Users（影响用户）：受威胁影响的用户数量

Discoverability（发现难度）：威胁被发现的难易程度

PASTA（Process for Attack Simulation and Threat Analysis）方法是一种基于风险的威胁建模方法，强调从攻击者视角进行分析。PASTA 包含七个阶段：

• 定义业务目标

• 技术范围分析

• 应用程序分解

• 威胁分析

• 漏洞分析

• 攻击模拟

• 风险分析和管理

攻击树是一种图形化的方法，用于系统地描述和分析攻击途径。攻击树的根节点表示攻击目标，每个子节点表示实现该攻击目标的可能步骤。通过这种方式，安全团队可以识别、分析和优先处理不同的攻击路径，制定相应的防御策略（但这个模式很依赖专家，假设安全团队本身乏善可陈，用这种方法会让排查漏洞时陷入迷惑状态，不清楚入侵者怎么来的，也不清楚该怎么排查问题）。

这些模型怎么用？

我先说整体思路，应用威胁建模的关键在于四个点：

1. 详细分解系统，识别所有可能的威胁（识别攻击面）。

2. 通过系统化的步骤对威胁进行分类、评分和分析。

3. 根据分析结果制定和实施缓解措施。

4. 持续更新和改进，确保对应用实施的安全措施能够适应变化产生的新威胁。

接下来我分别针对以上模型举例：

以设计一个网银系统举例，我们做的第一件事是系统分解，把系统分解为不同的组件和数据流：

• 用户（User）

• 认证服务（Authentication Service）

• 交易处理服务（Transaction Processing Service）

• 数据存储（Database）

• 网络通信（Network Communication）

接下来针对各个组件应用 STRIDE 模型识别可能的威胁，并完成评估和分析，以用户组件为例：

1. Spoofing（欺骗）

• 用户身份欺骗：攻击者冒充合法用户登录系统。

• 评估和分析：使用弱密码或社工手段获取用户凭证，导致账户被盗用。可能影响大量用户，导致财产损失和系统信誉受损。

• 威胁评级：高

• 会话劫持：攻击者通过截获会话令牌冒充合法用户。

• 评估和分析：会话令牌未加密或使用不安全的会话管理，可能导致攻击者获取访问权限。

• 威胁评级：中

2. Tampering（篡改）

• 数据篡改：攻击者在传输过程中篡改交易数据。

• 评估和分析：未使用加密传输导致数据被截获和篡改，影响交易的完整性和正确性。

• 威胁评级：高

• 客户端篡改：攻击者篡改客户端应用或脚本以发起恶意请求。

• 评估和分析：客户端未验证的输入导致恶意数据被发送到服务器。

• 威胁评级：中

3. Repudiation（抵赖）

• 交易抵赖：用户否认进行过某些交易。

• 评估和分析：缺乏详细的交易日志和审计记录，使得用户可以抵赖交易。

• 威胁评级：中

• 活动抵赖：用户否认执行过某些操作（如修改账户信息）。

• 评估和分析：系统未记录用户活动或记录不完整，导致难以追踪用户行为。

• 威胁评级：中

4. Information Disclosure（信息泄露）

• 敏感信息泄露：未经授权的用户访问敏感数据，如账户余额和交易记录。

• 评估和分析：缺乏访问控制和数据加密措施，可能导致敏感数据被泄露。

• 威胁评级：高

• 日志信息泄露：日志中包含敏感信息，被未经授权的人员访问。

• 评估和分析：日志未加密或未做权限控制，可能泄露敏感操作信息。

• 威胁评级：中

5. Denial of Service（拒绝服务）

• 服务中断：攻击者通过大量请求使系统无法响应正常用户的请求。

• 评估和分析：系统未能有效处理大量请求，导致服务不可用。

• 威胁评级：高

• 资源耗尽：攻击者通过消耗系统资源（如CPU、内存）导致系统性能下降。

• 评估和分析：资源分配不合理或未能有效监控资源使用，导致服务中断。

• 威胁评级：中

6. Elevation of Privilege（权限提升）

• 权限提升攻击：攻击者利用系统漏洞获得比预期更高的权限。

• 评估和分析：系统存在未修复的漏洞或配置错误，导致权限被提升。

• 威胁评级：高

• 特权滥用：拥有高权限的用户滥用其权限执行未经授权的操作。

• 评估和分析：缺乏权限控制和监控机制，高权限用户的行为未受限。

• 威胁评级：中

第三步是比较麻烦的，需要文档做记录，写文档这件事也是两极分化，一部分人认为文档写完系统都更新十几个版了，纯属吃力不讨好；另一部分人认为不写文档就不是好习惯blbla的，我的观点是：

大家写文档的意愿程度，取决于产品需求的变更频率。

第四步是指定缓解措施与方案，例如：

• 用户身份欺骗：实施多因素认证（MFA）和强密码策略。

• 会话劫持：使用加密的会话令牌和安全的会话管理。

• 数据篡改：采用传输层安全（TLS）加密数据传输。

• 交易抵赖：记录详细的交易日志和审计记录。

最后一步就是持续维护和改进。

还要提一嘴 ASTRIDE 模型，全称是 Advanced STRIDE，这个模型属于对 STRIDE 的增强版，增加了很多细节和步骤让团队可以更深入的理解和应对安全威胁，例如引入行为分析识别异常行为和基于上下文做威胁分析等，

上面的例子是基于微软的 STRIDE 模型，那接下来我还以设计网银系统为例，基于 Attack Trees 做一次威胁建模。建模时还是以四个关键点为核心，即分解系统，识别威胁；对威胁进行分类、评分和分析；根据分析结果制定和实施缓解措施；持续更新和改进。不过基于 Attack Trees 的做法还是和 STRIDE 有点小区别的。

明确网银系统的范围和安全目标是进行有效威胁建模的第一步。需要考虑的包括：

1. 系统边界：明确网银系统包含的组件和数据流，如用户、认证服务、交易处理服务、数据存储和网络通信。

2. 安全目标：

• 保护用户账户信息的保密性和完整性。

• 确保交易数据的完整性和保密性。

• 维持系统的可用性，防止拒绝服务攻击。

识别网银系统中的关键资产和功能，将其作为攻击树的根节点。例如：

1. 用户账户信息：用户的登录凭证、个人信息等。

2. 交易处理服务：用户发起的转账、支付等金融交易。

3. 数据存储：数据库中的用户数据和交易记录。

4. 认证服务：用户登录和身份验证服务。

5. 网络通信：数据在用户和服务器之间的传输

为每个攻击目标构建攻击树。攻击树的根节点是攻击目标，子节点表示实现该攻击目标的各种途径。

1. 攻击目标：用户账户信息（包括获取用户凭证、篡改账户信息等）

• SQL注入攻击

• 中间人攻击（MITM）

• 使用弱密码或社工

• 通过钓鱼攻击获取凭证

• 会话劫持

2. 攻击目标：交易处理服务(包括中断交易处理、篡改交易数据等)

• 数据包截获和篡改

• 恶意软件攻击

• 分布式拒绝服务（DDoS）攻击

• 应用层拒绝服务攻击

针对每个攻击途径进行详细分析，评估其可能性和影响。例如：

• 使用弱密码或社工

• 可能性：高，用户通常使用弱密码或容易受到社工攻击

• 影响：高，攻击者获取用户凭证后可访问账户信息

• 钓鱼攻击获取凭证

• 可能性：中，取决于用户的防范意识和系统的反钓鱼措施

• 影响：高，因成功后攻击者可完全控制用户账户

为每个威胁制定相应的缓解措施，例如：

1. 使用弱密码或社工

• 可能性：高，因用户通常使用弱密码或容易受到社工攻击。

• 影响：高，因攻击者获取用户凭证后可访问账户信息。

2. 钓鱼攻击获取凭证

• 可能性：中，取决于用户的防范意识和系统的反钓鱼措施。

• 影响：高，因成功后攻击者可完全控制用户账户。

3. 会话劫持

• 可能性：中，取决于会话管理的安全性。

• 影响：中，因攻击者可能获取部分会话信息。

4. SQL注入攻击

• 可能性：中，取决于应用程序对输入的验证程度。

• 影响：高，因攻击者可获取和篡改数据库中的重要信息。

5. 中间人攻击（MITM）

• 可能性：中，取决于传输层的安全性。

• 影响：高，因攻击者可截获和篡改通信数据。

详细记录攻击树模型，并随着系统的变化和新威胁的出现进行更新。定期评估和审查攻击树，确保其反映当前的安全状态，这里的记录应包括攻击树结构图、每个节点的详细分析、威胁的可能性和影响评估、对应的缓解措施和实施状态。

攻击树示例：

获取用户凭证||-- 使用弱密码或社工|   |-- 强制使用强密码策略|   |-- 实施多因素认证（MFA）||-- 通过钓鱼攻击获取凭证|   |-- 提高用户安全意识|   |-- 使用反钓鱼技术||-- 会话劫持    |-- 使用加密的会话令牌    |-- 实施安全的会话管理

看了基于以上两个模型做的威胁建模，大家应该清楚思路了，有点像风险评估，但又不太一样，风险评估和威胁建模的相似之处是都需要识别潜在问题、进行程序化分析、并制定有效的防护措施，不同点在于，风险评估的范围更广、时间更灵活、输出的结果也不同，我们可以粗暴的把威胁建模当作是风险评估的子选项吧。

威胁建模工具

以下是一些常用的威胁建模工具推荐：

• 特点：专门设计用于实现STRIDE威胁建模方法。用户可以创建数据流图，系统自动生成潜在威胁。

• 优点：易于使用，集成度高，适合初学者和经验丰富的安全专家。

• 适用场景：适合各种规模的企业，特别是那些已经使用Microsoft产品的企业。

• 特点：开源的威胁建模工具，支持创建数据流图，并提供基于STRIDE的威胁识别。

• 优点：免费，跨平台（支持Web和桌面应用），适合敏捷开发环境。

• 适用场景：适合中小型企业和希望使用开源工具的组织。

• 特点：自动化威胁建模平台，支持多种威胁建模方法（如STRIDE、PASTA等），并提供详细的风险评估和缓解建议。

• 优点：功能全面，支持大型复杂系统的威胁建模，集成度高。

• 适用场景：适合大型企业和对安全性要求高的行业。

• 特点：企业级威胁建模工具，支持多种威胁建模框架，并能与其他安全工具集成。

• 优点：自动化程度高，提供详细的威胁和缓解策略报告，易于与DevOps流程集成。

• 适用场景：适合大型企业和需要自动化威胁建模的团队。

• 特点：模拟和分析安全威胁，通过建模和仿真预测攻击路径和安全漏洞。

• 优点：提供详细的仿真报告和风险评估，支持复杂网络环境的安全建模。

• 适用场景：适合需要深入安全分析和仿真的企业和研究机构。

讨论：威胁建模是伪概念吗？

有人认为威胁建模是伪概念，主要由于大家在实践时会有如下问题，并且不太好解决，我们逐条分析。

威胁建模的效果在很大程度上依赖于实施的质量，如果实施不当，威胁建模可能无法有效识别和缓解潜在的安全威胁。例如，假设威胁建模没有覆盖系统的所有组件和数据流，或未能准确评估威胁的严重性和可能性，那么即使进行了威胁建模，系统还是一坨谢特。

网络威胁是不断变化和演化的，新的攻击方法和漏洞不断出现。威胁建模虽然是在系统开发的早期阶段进行，但不要忘了它需要动态持续集成持续改进啊，这一步做不好就会造成安全措施的长期大量滞后。

有些企业可能过度依赖威胁建模工具，而完全不使用手动分析和专家判断。虽然工具可以帮助识别一些常见的威胁，但它们无法完全替代人类专家的经验；此外，工具的误报和漏报也会影响威胁建模的有效性。

威胁建模需要投入时间和资源，但并非所有企业都有足够的资源进行全面和持续的威胁建模，尤其是中小型企业。这些企业可能在初期进行威胁建模，但由于资源限制，未能在后续阶段进行必要的安全维护和更新，导致系统仍存在漏洞。

在实际项目中，安全与功能的开发常常需要权衡。快速交付产品和满足市场需求可能会优先于全面的安全措施，导致安全问题被忽视或推迟处理。这在敏捷开发方法中特别常见，因为这种方法强调快速迭代和持续交付。

以上因素都会导致威胁建模不完善从而看似"失效"，但我认为威胁建模不是伪概念（虽然我的职业生涯没做过太多次威胁建模），它的核心思想是通过系统化的方法识别和缓解潜在威胁，以提高系统的安全性：

• 预防胜于治疗：威胁建模在系统开发的早期阶段识别和缓解潜在威胁，有助于在部署之前解决安全问题，减少修复漏洞的成本和时间 。

• 系统化安全评估：威胁建模提供了一种系统化的方法来评估安全风险，有助于发现传统测试方法和代码审查可能忽略的设计缺陷 。

• 提高整体安全性：通过威胁建模，安全团队可以更好地理解系统中的安全漏洞，并制定相应的防护策略，从而提高系统的整体安全性 。

结语

总的来说，威胁建模本身是一种有效的安全实践，但其成败取决于实施的质量和是否进行持续维护。企业需要充分认识到这一点，才能更好地利用威胁建模来提升系统的安全性。

点点赞，点点关注，点点文末广告，抱拳了家人们 ^o^

点点赞 点点关注 点点文末广告 抱拳了家人们

创作不易

关注一下

帮忙点点文末广告

原文始发于微信公众号（imBobby的自留地）：理解威胁建模：方法与实战（STRIDE 和 Attack Trees）