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的认知，发现并记录之前未书面化的假设。然后我们建立连接和威胁参与者的相关组合，特别是那些跨越信任边界的连接。我们称这些连接-参与者组合为威胁参与者路径。
威胁场景
我们的核心建模工作能够识别客户可能忽略的设计级和操作风险。我们将以威胁场景的形式记录这些风险。每个威胁场景描述对手可能利用系统中跨越两个组件间信任边界的单个连接的潜在方式。
发现与后续工作
当客户需要更细粒度的安全评审但不确定如何最好地定位时，我们可以进行轻量级威胁建模，并使用其结果来限定后续安全代码评审、基础设施评审或模糊测试工作的范围。
或者，我们可以进行全面威胁建模来产生系统级发现。威胁模型发现通过更深入的针对性研究具体化威胁场景，评估不同可能威胁参与者的利用严重性和难度，最后提供量身定制的修复建议。
应用结果
指导进一步安全评审
我们在内部使用威胁模型结果为同一系统的进一步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演进的推动。