TRAIL威胁建模方法 - Trail of Bits博客
什么是TRAIL
多年来我们使用过多种威胁建模方法，但每种方法都有其局限性。为此我们结合现有最佳实践，迭代开发出自己的流程——TRAIL（Threat and Risk Analysis Informed Lifecycle）。TRAIL最初扩展了Mozilla的单组件快速风险评估（RRA）流程，将其应用于整个系统（无论大小），并融合了NIST SP 800-154以数据为中心的威胁建模指南和NIST SP 800-53安全与隐私控制词典的元素。
虽然RRA的数据词典启发了我们的方法，但TRAIL使我们能够以更严谨的方式建模系统的所有范围内组件及其关系。遵循TRAIL时，我们系统性地覆盖组件间的每个连接，不仅发现每个组件处理数据的直接威胁，还发现组件间不当交互产生的新兴弱点以及其他架构和设计级风险。
TRAIL威胁模型的价值
TRAIL有三个核心目标：
- 记录当前系统的架构级和操作风险
- 为每个风险提供实用的短期缓解方案和长期战略建议
- 使客户能够在缓解风险时自行更新威胁模型
在软件/系统开发生命周期（SDLC）中，应用安全评审能产生更好的产品。SDLC的设计阶段是进行协作式威胁建模的理想时机，此时还没有用户依赖特定系统功能，但需求已基本确定，更容易进行设计改进。
TRAIL如何运作
模型构建
TRAIL的基础是首先构建尽可能准确的模型。我们与客户合作识别所有范围内系统组件，然后在安全控制门控组件间连接的位置（或根据安全要求和设计应该存在的位置）放置信任边界。我们将共享信任边界的组件分组为信任区域。
通过与客户深入交流和阅读系统文档，我们建立对系统及其SDLC的了解，发现并记录先前未书面化的假设。然后我们建立连接和威胁参与者的相关组合，特别是那些跨越信任边界的连接。我们称这些连接-参与者组合为威胁参与者路径。
威胁场景
我们的核心建模工作使我们能够识别客户可能忽略的设计级和操作风险。我们将以威胁场景的形式记录这些风险。每个威胁场景描述对手可能利用系统中两个组件间跨越信任边界的单个连接的潜在方式。
对于某些威胁建模练习，我们在此阶段停止细化系统上下文，并以摘要级修复建议结束工作——我们称此类评审为轻量级威胁模型。
轻量级威胁模型的产出： 轻量级威胁建模参与会产生系统设计固有风险的端到端高级概述，通过少量威胁场景和建议进行说明。客户通常使用轻量级威胁模型的结果指导进一步的安全评审和修复。
表1：2023年Arch Linux Pacman评估中的示例威胁场景
| 场景 | 参与者 | 组件 |
|---|---|---|
| 环境变量影响Pacman包管理器的libcurl依赖 | 本地root | Pacman包管理器 |
| 攻击者尝试替换攻击，通过受损的本地网络仓库或远程仓库提升流行包的版本 | 仓库管理员/外部攻击者 | Pacman包管理器/本地网络仓库/远程网络仓库 |
| 攻击者破坏打包密钥并为包生成不同但有效的签名以引入恶意更改 | 打包者/内部攻击者 | Pacman包管理器/打包密钥 |
图1：从Arch Linux信任根到运行Pacman的主机的包及其签名数据的建模数据流
更多轻量级威胁模型可在我们的Publications仓库的审计报告中找到，包括对CoreDNS、Eclipse Jetty、Kubernetes事件驱动自动扩展（KEDA）等的评估报告。
发现与后续工作
当客户需要更细粒度的安全评审但不确定如何最好地定位时，我们可以进行轻量级威胁模型，并使用其结果将后续的安全代码评审、基础设施评审或模糊测试工作范围限定在少数威胁场景或系统组件上。
或者，我们可以进行全面威胁模型来产生系统级发现，而不是停留在轻量级威胁模型提供的高级概述上。威胁模型发现通过更深入、有针对性的调查具体化威胁场景，评估不同可能威胁参与者的利用严重性和难度，最后提供关于如何修复这些威胁的定制建议。
全面威胁模型的产出： 在全面的TRAIL威胁模型中，我们将超越轻量级威胁模型的终点，将识别的威胁场景整合起来并进行更多研究，最终呈现发现和特定于发现的建议。
以下是来自我们Linkerd参与的一些发现摘要：
- Linkerd目标服务（在2022年时）缺乏内置速率限制，可能允许攻击者造成拒绝服务
- 基础设施操作员可以使用Linkerd CLI工具通过未加密的HTTP获取包含敏感信息的YAML定义
- linkerd-viz网络仪表板缺乏访问控制，允许攻击者获取集群详细信息
图2：代表性Linkerd部署的建模数据流
表2：2022年Linkerd全面威胁模型中的示例威胁场景
| 源区域 | 目标区域 | 参与者 | 描述 |
|---|---|---|---|
| 外部 | 用户应用命名空间 | 基础设施操作员 | 用户应用与其边车代理共享pod，应用受损可能暴露命名空间内的路由信息和证书 |
| 外部 | Linkerd命名空间 | 内部攻击者 | 有权访问托管YAML文件的外部服务的内部攻击者可能操纵底层基础设施 |
| 用户应用命名空间 | linkerd-viz命名空间 | 内部攻击者 | 受限访问应用命名空间的内部攻击者可访问Prometheus端点获取指标数据 |
我们Publications仓库中的其他全面威胁模型报告包含更多威胁参与者路径和我们基于它们构建的发现；我们的Curl和Kubernetes报告是很好的例子。
应用结果
一旦我们映射了整个系统，识别了设计中的安全控制差距，共同探索了潜在威胁场景，并提供了我们的发现和建议，接下来该怎么办？
指导进一步安全评审
我们在内部使用威胁模型的结果为同一系统的进一步Trail of Bits评审提供上下文和方向，提高后续审计的效率和结果。如果您对威胁模型的结果和我们提供的其他类型安全参与都感兴趣，为什么不将两个参与背靠背预订，先进行威胁模型呢？我们2024年关于OSTIF工作的回顾博客文章提供了几个这种配对的好例子！
修复
我们的做法是在全面威胁模型中对每个发现包含短期（立即止损）和长期（实现理想状态）的缓解建议。在可能的情况下，我们为每个发现推荐几个重叠的缓解措施，因为单个缓解措施可能会失败或被资源丰富的攻击者破坏。我们还在全面和轻量级威胁模型中包含建议的高级摘要。
更新威胁模型
威胁模型必须随着系统的发展而变化。我们在每个报告中都提供一个附录，包含帮助您定期修改威胁模型的指导，使其在系统设计和需求随时间变化时保持相关性。我们将在下一篇文章中讨论如何以及何时更新您的威胁模型！
我喜欢TRAIL威胁模型的声音。如何获得一个？
请使用我们的联系表与我们联系。我们很乐意了解您的系统和需求！
特别感谢Stefan Edwards、Brian Glas、Alex Useche、David Pokora、Spencer Michaels、Paweł Płatek、Artem Dinaburg、Ben Samuels以及在Trail of Bits从事威胁建模参与的所有其他人的卓越贡献和对TRAIL演进的推动。
我们将在下一篇文章中介绍随着系统变化和修复安全问题而更新威胁模型的内容！