TRAIL威胁建模方法 - Trail of Bits博客
什么是TRAIL
多年来我们使用过多种威胁建模方法，每种方法各有优势，但没有一种完全符合客户需求。因此我们结合已知最佳实践，通过迭代构建了自己的流程。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 CLI工具通过未加密HTTP获取包含敏感信息的YAML定义
- linkerd-viz网络仪表板缺乏访问控制，攻击者可获取集群详细信息
图2：代表性Linkerd部署的建模数据流
表2：2022年Linkerd全面威胁模型中的示例威胁场景
| 源区域 | 目标区域 | 参与者 | 描述 |
|---|---|---|---|
| 外部 | 用户应用命名空间 | 基础设施操作员 | 用户应用与其边车代理共享pod，应用受损可能暴露路由信息和证书 |
| 外部 | Linkerd命名空间 | 内部攻击者 | 可操纵托管YAML文件的外部服务 |
| 用户应用命名空间 | linkerd-viz命名空间 | 内部攻击者 | 可访问Prometheus端点获取指标数据 |
我们Publications代码库中的其他全面威胁模型报告包含更多威胁参与者路径和基于它们构建的发现；我们的Curl和Kubernetes报告是很好的例子。
应用结果
一旦我们映射了整个系统，识别了设计中的安全控制差距，共同探索了潜在威胁场景，并提供了发现和建议，接下来该怎么办？
指导进一步安全评审
我们在内部使用威胁模型的结果为同一系统的进一步Trail of Bits评审提供上下文和方向，提高后续审计的效率和结果。如果您对威胁模型的结果和我们提供的其他类型安全参与都感兴趣，为什么不将两个参与背靠背预订，先进行威胁模型？
修复
我们的做法是在全面威胁模型中对每个发现包含短期（立即止损）和长期（达到理想状态）的缓解建议。在可能的情况下，我们建议每个发现采用多个重叠的缓解措施，因为单个缓解措施可能失败或被资源丰富的攻击者颠覆。我们还在全面和轻量级威胁模型中包含建议的高层摘要。
更新威胁模型
威胁模型必须随着系统的发展而变化。我们在每个报告中提供一个附录，包含指导帮助您定期修改威胁模型，使其在系统设计和需求随时间变化时保持相关。我们将在下一篇文章中讨论如何以及何时更新威胁模型！
如何获取TRAIL威胁模型
请使用我们的联系表与我们联系。我们很乐意了解您的系统和需求！
特别感谢Stefan Edwards、Brian Glas、Alex Useche、David Pokora、Spencer Michaels、Paweł Płatek、Artem Dinaburg、Ben Samuels以及在Trail of Bits从事威胁建模参与的所有其他人，感谢你们的卓越贡献和对TRAIL演进的推动。
我们将在下一篇文章中介绍随着系统变化和修复安全问题而更新威胁模型！ ↩︎
SDLC是一个常见的过程流（希望您使用它！），将人们在创建和维护系统时做的工作组织到几个生命周期阶段：需求收集、设计、开发、测试、维护和重新评估。虽然有些人将SDLC与Agile联系起来，但使用SDLC来框架和衡量开发过程的进展不需要遵循Agile或任何其他过程或管理框架。 ↩︎
正如Adam Shostack之前所说："[威胁建模]提供了一个结构化、系统化、全面的安全方法。结构化威胁建模技术识别可能出错的地方，并保证您的全面性。组织在团队之间获得协作而不是冲突。" ↩︎
我们使用NIST SP 800-53安全控制家族对威胁建模评估期间编写的发现进行分类。此分类表明发现详述的系统中的控制差距。您将在我们的威胁模型报告中看到每个安全控制家族的简要定义。 ↩︎
不受欢迎人物（威胁参与者角色）帮助我们描述系统中的参与者（合法或其他方式）、他们拥有的特权以及这些参与者的（滥）用案例。我们在TRAIL过程的早期步骤中编写简单的参与者角色。 ↩︎
NIST SP 800-154对攻击向量的定义（包括源组件和攻击者利用访问目标组件中漏洞的数据）是我们威胁参与者路径概念的基础。 ↩︎