TRAIL威胁建模方法解析
什么是TRAIL
多年来我们使用过多种威胁建模方法，但每种方法都有其局限性，无法完全满足客户需求。因此我们整合已知最佳实践，迭代开发出专属流程——TRAIL（Threat and Risk Analysis Informed Lifecycle）。该框架最初扩展自Mozilla的单组件快速风险评估（RRA）流程，适用于全系统（无论规模大小），并融合了NIST SP 800-154以数据为中心的威胁建模指南和NIST SP 800-53安全隐私控制词典的核心要素。
虽然RRA的数据词典为我们提供了灵感，但TRAIL能以更严谨的方式建模系统所有范围内组件及其相互关系。通过TRAIL流程，我们会系统化覆盖组件间的每个连接点，不仅揭示各组件处理数据的直接威胁，还发现因组件间不当交互产生的潜在弱点以及其他架构设计层级风险。
传统安全补丁容易陷入"接收安全报告→实施单独修复→再次收到相同问题报告"的循环。结构化威胁建模能打破这种治标不治本的循环。合格的威胁模型能暴露设计层级弱点（个体漏洞只是其表象），从而实现根本性修复。
TRAIL威胁模型的价值体现
TRAIL设立三大目标：
- 记录当前系统架构层级和运营风险
- 针对每个风险提供实用短期缓解方案和长期战略建议
- 支持客户在风险缓解和系统演进过程中自主更新威胁模型
在整个软件/系统开发生命周期（SDLC）中，应用安全评审能显著提升产品质量。SDLC的设计阶段是开展协作式威胁建模的最佳时机——此时尚未有用户依赖特定系统功能，而需求已基本确定，便于进行设计改进。当然，实施威胁建模在SDLC任何阶段都能产生价值，因为它能增强开发人员对设计选择后果的理解。
TRAIL运作机制
模型构建
TRAIL的基础是构建尽可能精确的系统模型。我们与客户协作识别所有范围内系统组件，然后在安全控制网关组件连接处（或根据安全要求应当设置处）设立信任边界，将共享信任边界的组件归类为信任区域。
通过深入沟通和文档研读，我们构建系统及其SDLC的认知图谱，发现并记录先前未明确的假设。随后建立连接与威胁行为者的相关组合，特别是跨越信任边界的连接——我们称之为威胁行为者路径。
虽然与客户讨论潜在威胁时形式相对自由，但构建威胁行为者路径能确保严谨性，避免遗漏攻击者恶意提升权限或导致数据在组件间/系统外移动的路径。
威胁场景
核心建模工作帮助我们识别客户可能忽略的设计层级和运营风险，并以威胁场景形式记录。每个威胁场景描述对手可能利用系统中两个组件间跨越信任边界的单个连接的方式。整合威胁场景并进行进一步确认研究后，我们将撰写发现报告（后续详述）。对于部分威胁建模任务，我们在此阶段停止细化系统上下文，仅提供汇总级修复建议——此类评审称为轻量级威胁模型。
轻量级威胁模型交付内容：
- 端到端的高层级系统设计风险概览
- 配以数个威胁场景及建议的示意图
- 客户通常用其指导后续安全评审和修复
示例：2023年Arch Linux包管理器Pacman评估中的威胁场景：
| 场景 | 行为者 | 组件 |
|---|---|---|
| 环境变量影响Pacman的libcurl依赖。例如Pacman通过http_proxy环境变量定义代理重定向HTTP连接。若攻击者向Pacman运行时环境注入环境变量（安装时以root权限运行，难度较高），可能导致Pacman出现可利用或异常行为。 | 本地root | Pacman包管理器 |
| 攻击者尝试替换攻击，通过受控本地网络仓库或远程仓库提升热门软件包版本。Pacman始终安装其可访问所有仓库中的最新版本。因此若用户同时启用本地和远程仓库，攻击者只需在远程仓库引入同名高版本包即可诱导用户安装。类似攻击也可能通过DNS混淆实现（例如攻击者注册仿冒本地网络域名的域名）。参见GitHub博客关于npm替换攻击的文章。 | 仓库管理员/外部攻击者 | Pacman包管理器/本地网络仓库/远程网络仓库 |
| 攻击者窃取打包密钥并为软件包生成不同但有效的签名以引入恶意更改。此时Pacman会正常安装新版本，用户完全无法察觉。目前无法在包签名变更时启用警告功能。 | 打包者/内部攻击者 | Pacman包管理器/打包密钥 |
表1：Arch Linux Pacman评估中的威胁场景示例
更多轻量级威胁模型案例可参阅我们Publications代码库中的审计报告，包括CoreDNS、Eclipse Jetty、Kubernetes事件驱动自动扩展（KEDA）等项目的评估报告。
发现与后续工作
当客户需要更细粒度安全评审但不确定如何定位时，我们可先进行轻量级威胁建模，并利用其结果限定后续安全代码评审、基础设施评审或模糊测试的范围，仅针对少量威胁场景或系统组件。
Alternatively，我们可不限于轻量级威胁模型的高层概述，而是进行全面威胁建模以产生系统级发现。威胁模型发现通过深入定向研究具体化威胁场景，评估不同威胁行为者的利用难度和严重性，最终给出定制化修复建议。
全面威胁模型交付内容： 在全面TRAIL威胁模型中，我们将超越轻量级威胁模型的终点，整合已识别的威胁场景并进行更多研究，最终呈现发现和针对性建议。以下是我们Linkerd项目中的部分发现摘要：
- 在Linkerd评估期间（2022年），向Linkerd集成Kubernetes集群内边车代理提供路由信息的目标服务缺乏内置速率限制。这使得具有集群用户应用命名空间边车代理访问权限的攻击者可通过重复请求路由信息轻易导致拒绝服务，或改变目标服务可用状态以强制Linkerd控制器组件更新。
- 我们发现无任何机制阻止基础设施操作员使用Linkerd CLI工具通过未加密HTTP获取YAML定义（含敏感信息）。此明文数据流会削弱基础设施操作员系统的整体安全态势。
- 同期linkerd-viz网页仪表板缺乏访问控制。这意味着任何通过在Linkerd配置的Kubernetes集群上运行扫描工具获知仪表板网络地址的攻击者，均可通过访问该仪表板获取集群中命名空间、服务、容器等资源的详细信息，并以此为基础针对集群上运行的软件。
下表列出了用于构建上述发现的部分威胁场景：
| 源区域 | 目标区域 | 行为者 | 描述 |
|---|---|---|---|
| 外部 | 用户应用命名空间 | 基础设施操作员 | 用户应用与其边车代理及初始化容器共享Pod。因此用户应用基础设施操作员应意识到：若用户应用被入侵，边车代理等横向组件也可能被入侵，可能暴露命名空间内的路由信息和证书。 |
| 外部 | Linkerd命名空间 | 内部攻击者 | 具有托管基础设施操作员YAML文件的外部服务访问权限的内部攻击者可能操纵底层基础设施。 |
| 用户应用命名空间 | linkerd-viz命名空间 | 内部攻击者 | 访问权限仅限于应用命名空间的内部攻击者可访问Prometheus端点获取指标数据，从而洞察原本不可见的其他集群组件。 |
表2：2022年Linkerd全面威胁模型中的威胁场景示例
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演进做出的卓越贡献。
我们将在下一篇文章中探讨系统变更和修复安全问题时如何更新威胁模型！
注释：
- 我们使用NIST SP 800-53安全控制家族对威胁建模评估中的发现进行分类，该分类指明发现详述的系统控制缺口。威胁模型报告中会包含各安全控制家族的简要定义。
- 不受欢迎人物（威胁行为者角色）帮助我们描述系统内人员（合法或其他）、其权限以及这些行为者的（滥用）用例。我们在TRAIL流程早期编写简单行为者角色。
- NIST SP 800-154对攻击向量的定义（包括源组件和攻击者利用访问目标组件漏洞的数据）是我们威胁行为者路径概念的基础。