以Trail of Bits方式进行威胁建模

Trail of Bits
发布于 2025-03-01 14:50
阅读 17

本文介绍了TRAIL，一个由Trail of Bits开发并不断改进的威胁建模流程。TRAIL旨在帮助客户跟踪和记录有缺陷的信任假设和不安全的设计决策对系统架构的影响，通过识别架构层面的风险并提供短期和长期缓解方案，使客户能够随着系统变化自主更新威胁模型，同时还阐述了TRAIL的工作原理，以及轻量级和综合性威胁模型的产出。

我们的威胁建模过程略有不同。随着时间的推移，多位应用安全专家对这一过程进行了改进，以便为我们的客户提供最大的价值，并尽量减少在系统更改时更新威胁模型所需的工作量。

我们将我们的过程称为 **TRAIL**，它代表 **T** hreat and **R** isk **A** nalysis **I** nformed **L** ifecycle（威胁和风险分析驱动的生命周期）。TRAIL 使我们能够追踪和记录有缺陷的信任假设和不安全的设计决策对我们客户的架构以及支持它们的系统和流程的影响。缓解像这样的系统级发现可以消除整个漏洞类别，这意味着需要担心的零星错误报告和修复会更少。

## 什么是 TRAIL

多年来，我们都使用过各种威胁建模方法；每种方法都有其优势，但没有一种方法能完美地满足我们客户的需求，因此我们将我们所知道的最佳部分结合起来，并迭代构建我们自己的流程。TRAIL 最初将 Mozilla 的单组件[快速风险评估](https://infosec.mozilla.org/guidelines/risk/rapid_risk_assessment.html) (RRA) 流程扩展到整个系统（无论大小），并结合了 [NIST SP 800-154](https://csrc.nist.gov/files/pubs/sp/800/154/ipd/docs/sp800_154_draft.pdf) 数据中心威胁建模指南和 [NIST SP 800-53](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf) 安全和隐私控制字典的部分内容。

虽然 RRA 的数据字典启发了我们的方法，但 TRAIL 使我们能够更严格地建模系统中所有在范围内的部分及其关系。在遵循 TRAIL 时，我们会系统地覆盖组件之间的每个连接。我们不仅会发现每个组件处理的数据的直接威胁，还会发现由于组件之间不正确的交互以及其他架构和设计层面的风险而出现的新弱点。

安全补丁很容易变成一个循环：收到安全报告，进行一次性修复，然后收到另一张工单，其中记录了完全相同问题的另一个实例。结构化的威胁建模打破了这种一遍又一遍地治疗症状的循环。适当的威胁模型会暴露设计层面的弱点（个别漏洞是其症状），以便可以对其进行修复。

## 为什么 TRAIL 威胁模型有价值

TRAIL 有三个目标：

1. 记录当前系统架构层面和运营层面的风险；
2. 对于每个风险，为我们的客户提供实用的短期缓解方案和长期的战略建议；
3. 使我们的客户能够在缓解风险时自行更新威胁模型[1](https://blog.trailofbits.com/2025/02/28/threat-modeling-the-trail-of-bits-way/#fn:1)，并且系统会随着时间的推移而发生变化。

在整个软件/系统开发生命周期（[SDLC](https://en.wikipedia.org/wiki/Systems_development_life_cycle)）[2](https://blog.trailofbits.com/2025/02/28/threat-modeling-the-trail-of-bits-way/#fn:2)中，应用安全审查会产生更好的产品。SDLC 的[设计阶段](https://learnblockchain.cn/article/17457/#:~:text=Performing%20a%20threat%20model%20during%20the%20design%20phase%20of%20the%20software%20development%20lifecycle%20(SDLC)%20may%20have%20informed%20Bybit%20that%20their%20system%20contains%20the%20following%20control%20failures) 是进行协作式[3](https://blog.trailofbits.com/2025/02/28/threat-modeling-the-trail-of-bits-way/#fn:3) 威胁建模练习的理想时机，该练习涉及安全工程师和构建系统的人员：还没有用户依赖于特定的系统功能，但需求主要已确定，因此更容易进行设计改进。但种植树的第二个最佳时间自然是现在。威胁建模工作在每个 SDLC 阶段都提供了价值，因为它提高了开发人员对设计选择后果的理解。

## TRAIL 如何工作

### 模型构建

TRAIL 的基础是首先构建尽可能准确的模型。我们与客户合作以识别所有在范围内的系统组件。然后，我们将在安全控制[4](https://blog.trailofbits.com/2025/02/28/threat-modeling-the-trail-of-bits-way/#fn:4) 限制组件之间连接的任何地方放置信任边界（或者按照安全要求和设计，**应该**放置）。我们将共享信任边界的组件分组到信任区域中。

我们将与客户进行广泛的交谈，并阅读他们的系统文档，以建立对系统及其 SDLC 的了解，从而发现并记录以前未书写的假设。然后，我们建立连接和威胁参与者[5](https://blog.trailofbits.com/2025/02/28/threat-modeling-the-trail-of-bits-way/#fn:5)的相关组合，特别是对于那些跨越信任边界的连接。我们将这些连接-参与者组合称为**威胁参与者路径** [6](https://blog.trailofbits.com/2025/02/28/threat-modeling-the-trail-of-bits-way/#fn:6)。

虽然我们在此过程中与客户讨论潜在威胁的方式相对自由，但构建威胁参与者路径可确保我们保持严格，并且不会遗漏攻击者可能恶意升级其权限或导致数据在组件之间或系统之外移动的方式。

### 威胁情景

我们的核心模型构建工作使我们能够识别客户可能错过的设计层面和运营风险。我们将以威胁情景的形式记录这些风险。每个威胁情景都描述了对手可能利用系统内两个组件之间跨越信任边界的单个连接的潜在方式。将威胁情景放在一起并进行进一步的确认研究使我们能够编写发现，但我们稍后将讨论发现。对于某些威胁建模练习，我们将在此时停止完善我们的系统上下文，并将以总结层面的修复建议来结束我们的工作——我们将这种类型的审查称为**轻量级**威胁模型。

#### 从轻量级威胁模型中获得什么

轻量级威胁建模参与会产生系统设计中固有的风险的端到端、高级概述，并用一些威胁情景加上建议来说明。我们的客户通常使用轻量级威胁模型的结果来指导进一步的安全审查和修复。以下是 2023 年 Trail of Bits 对 Arch Linux 软件包管理器 Pacman 的[评估](https://github.com/trailofbits/publications/blob/master/reviews/2023-12-pacman-securityreview.pdf)中的一些威胁情景：

| **情景** | **参与者** | **组件** |
| --- | --- | --- |
| **环境变量会影响 Pacman 软件包管理器的 libcurl 依赖项。** 例如，Pacman 通过 `http_proxy` 环境变量中定义的代理重定向其 HTTP 连接。如果攻击者将环境变量注入到 Pacman 的运行时环境中——考虑到它在安装期间以 root 身份运行，这是一个困难的前景——他们可能会导致 Pacman 表现出可利用或不良的行为。 | - 本地 root | - Pacman 软件包管理器 |
| **攻击者尝试替换攻击，通过受感染的本地网络存储库或远程存储库提升流行软件包的版本。** Pacman 将始终安装其有权访问的所有存储库中软件包的最新版本。因此，如果用户同时启用了本地和远程存储库，则可以容易地诱导用户安装此版本的软件包，如果攻击者可以将相同名称、更高版本的软件包引入到其中一个远程存储库中。也可能通过 DNS 混乱实现类似的攻击（例如，如果攻击者注册一个镜像本地网络域名的域名）。请参阅[这篇 GitHub 博客文章](https://github.blog/2021-02-12-avoiding-npm-substitution-attacks/)，了解针对 npm 的替换攻击。 | - 存储库管理员 - 外部攻击者 | - Pacman 软件包管理器 - 本地网络存储库 - 远程网络存储库 |
| **攻击者破坏了打包密钥并为软件包生成不同但有效的签名以引入恶意更改。** 在这种情况下，Pacman 会正常安装新的软件包版本，并且用户将完全没有意识到。目前，没有办法在软件包的签名更改时启用警告。 | - 打包者 - 内部攻击者 | - Pacman 软件包管理器 - 打包密钥 |

**表 1：** 我们 2023 年对 Arch Linux Pacman 的评估中的示例威胁情景

![图 1：从 Arch Linux 信任根到运行 Pacman 的主机建模的软件包及其签名数据的数据流](https://img.learnblockchain.cn/2025/06/27/pacman.png)图 1：从 Arch Linux 信任根到运行 Pacman 的主机建模的软件包及其签名数据的数据流

更多轻量级威胁模型可以在我们的[出版物](https://github.com/trailofbits/publications) 存储库中的审计报告中找到，包括我们对 [CoreDNS](https://github.com/trailofbits/publications/blob/master/reviews/CoreDNS.pdf)、[Eclipse Jetty](https://github.com/trailofbits/publications/blob/master/reviews/2023-03-eclipse-jetty-securityreview.pdf)、[Kubernetes 事件驱动自动缩放 (KEDA)](https://github.com/trailofbits/publications/blob/master/reviews/2023-01-keda-securityreview.pdf) 和其他产品的评估报告。

### 发现和后续工作

当客户想要更精细的安全审查但不确定如何最好地定位它时，我们可以进行轻量级威胁模型，并使用其结果来将后续安全代码审查、基础设施审查或模糊测试工作范围缩小到只有几个威胁情景或系统组件。

或者，我们也可以不停止于轻量级威胁模型提供的高级概述，而是进行全面的威胁模型来生成系统级发现。威胁模型发现通过更深入、有针对性的调查来具体化威胁情景，评估不同可能的威胁参与者利用的严重性和难度，并最终提出有关如何修复这些威胁的定制建议。

#### 从全面的威胁模型中获得什么

在全面的 TRAIL 威胁模型中，我们将继续进行轻量级威胁模型的终点，将我们识别的威胁情景放在一起并进行更多的研究，最终提出发现和针对特定发现的建议。以下是我们 Linkerd [参与](https://github.com/trailofbits/publications/blob/master/reviews/Linkerd-threatmodel.pdf)中的一些发现摘要：

- 在 Linkerd 参与时（2022 年），目标服务向 Linkerd 集成的 Kubernetes 集群中的 sidecar 代理提供路由信息，但缺乏内置的速率限制。这可能允许集群用户应用程序命名空间内的具有 sidecar 代理访问权限的攻击者通过重复请求路由信息来容易地导致拒绝服务，或者更改目标服务的可用性状态以强制更新 Linkerd 控制器组件。
- 我们还发现，没有什么可以阻止基础设施运营商使用 Linkerd CLI 工具通过未加密的 HTTP 获取 YAML 定义，包括敏感信息。这种明文数据流将削弱基础设施运营商系统的整体安全态势。
- 同样在当时，`linkerd-viz` Web 仪表板缺乏访问控制。这意味着任何攻击者只要通过简单地在 Linkerd 配置的 Kubernetes 集群上运行扫描工具就能了解 Linkerd 仪表板的网络地址，然后可以通过访问此仪表板获得关于集群中命名空间、服务、Pod、容器和其他资源的详细知识，并且可以使用此信息作为针对在集群上运行的软件的基础。

![图 2：代表性的 Linkerd 部署的建模数据流](https://img.learnblockchain.cn/2025/06/27/linkerd.png)图 2：代表性的 Linkerd 部署的建模数据流

下表包括我们用于构建上述发现的一些威胁情景：

| **始发区** | **目标区** | **参与者** | **描述** |
| --- | --- | --- | --- |
| 外部 | 用户应用程序命名空间 | 基础设施运营商 | 用户应用程序与其 sidecar 代理和各自的 init 容器共享一个 Pod。因此，用户应用程序基础设施的运营商应该意识到，如果用户应用程序受到破坏，横向组件（如 sidecar 代理）也可能受到破坏。这可能会暴露命名空间内的路由信息和证书。 |
| 外部 | Linkerd 命名空间 | 内部攻击者 | 有权访问托管基础设施运营商 YAML 文件的外部服务的内部攻击者可能能够操纵底层基础设施。 |
| 用户应用程序命名空间 | `linkerd-viz` 命名空间 | 内部攻击者 | 访问权限仅限于应用程序命名空间的内部攻击者可以访问 Prometheus 端点以获取指标数据，这可以让他们深入了解他们原本无法看到的其他集群组件。 |

**表 2：** [我们 2022 年 Linkerd 全面威胁模型](https://github.com/trailofbits/publications/blob/master/reviews/Linkerd-threatmodel.pdf)中的示例威胁情景

我们的[出版物](https://github.com/trailofbits/publications) 存储库中其他的全面威胁模型报告包括更多的威胁参与者路径和我们用它们构建的发现；我们为 [Curl](https://github.com/trailofbits/publications/blob/master/reviews/2022-12-curl-threatmodel.pdf) 和 [Kubernetes](https://github.com/trailofbits/audit-kubernetes/blob/master/reports/Kubernetes%20Threat%20Model.pdf) 的报告是很好的例子。

## 应用结果

一旦我们绘制了你的整个系统，识别了其设计中的[安全控制差距](https://learnblockchain.cn/article/17457/#:~:text=Performing%20a%20threat%20model%20during%20the%20design%20phase%20of%20the%20software%20development%20lifecycle%20(SDLC)%20may%20have%20informed%20Bybit%20that%20their%20system%20contains%20the%20following%20control%20failures)，共同探索了潜在的威胁情景，并提供了我们的发现和建议，接下来是什么？

### 为进一步的安全审查提供信息

我们在内部使用我们的威胁模型的结果来为 Trail of Bits 对同一系统的进一步审查提供上下文和方向，从而提高后续审计的效率和结果。如果你对威胁模型的结果和我们提供的另一种安全参与类型都感兴趣，为什么不将这两个参与前后预订，首先进行威胁模型？从 2024 年我们与 OSTIF 合作的[这篇回顾性博客文章](https://learnblockchain.cn/article/17459/)中给出了几个这方面优秀的例子！

### 修复

我们的做法是在全面的威胁模型中为每个发现包括短期（立即停止）和长期（实现理想状态）的缓解建议。在可能的情况下，我们建议每个发现有几个重叠的缓解措施，因为[单一的缓解措施可能会失败或被足智多谋的攻击者破坏](https://how.complexsystems.fail/#2)。我们还在全面和轻量级威胁模型中都包括了我们建议的高级摘要。

### 更新你的威胁模型

威胁模型必须随着系统的发展而变化。我们为每份报告提供一个附录，其中包含指导，以帮助你定期修改威胁模型，使其在系统的设计和需求随时间变化时保持相关性。我们还将在[我们的下一篇文章](https://learnblockchain.cn/article/17458/)中讨论如何以及何时更新你的威胁模型！

## 我喜欢 TRAIL 威胁模型听起来的样子。我如何获得一个？

请使用我们的[联系表](https://www.trailofbits.com/contact/)与我们联系。我们很高兴了解你的系统和你的需求！

**特别感谢 Stefan Edwards、Brian Glas、Alex Useche、David Pokora、Spencer Michaels、Paweł Płatek、Artem Dinaburg、Ben Samuels 以及在 Trail of Bits 从事威胁建模工作的每一位员工，感谢你们的卓越表现以及对 TRAIL 发展的贡献。**

* * *

1. 我们将在[我们的下一篇文章](https://learnblockchain.cn/article/17458/)中介绍如何随着系统的变化以及修复安全问题来更新你的威胁模型！[↩︎](https://blog.trailofbits.com/2025/02/28/threat-modeling-the-trail-of-bits-way/#fnref:1)

2. [SDLC](https://en.wikipedia.org/wiki/Systems_development_life_cycle) 是一个常见的流程（我们希望你使用它！），它将人们在创建和维护系统时所做的工作组织成几个生命周期阶段：需求收集、设计、开发、测试、维护和重新评估。虽然有些人将 SDLC 与 Agile 联系起来，但使用 SDLC 来构建和衡量开发过程的进度不需要遵循 Agile 或任何其他过程或管理框架。[↩︎](https://blog.trailofbits.com/2025/02/28/threat-modeling-the-trail-of-bits-way/#fnref:2)

3. 正如 [Adam Shostack 之前所说](https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9238654)：“[威胁建模]为安全性提供了一种结构化、系统化、全面的方法。结构化的威胁建模技术可以识别可能出错的地方，并确保你是全面的。组织获得的是团队之间的协作，而不是冲突。”[↩︎](https://blog.trailofbits.com/2025/02/28/threat-modeling-the-trail-of-bits-way/#fnref:3)

4. 我们使用 [NIST SP 800-53](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf) 安全控制系列来分类我们在威胁建模评估期间编写的发现。此分类表明了发现详细说明的系统中的控制差距。你将在我们的威胁模型报告中看到每个安全控制系列的简要定义。[↩︎](https://blog.trailofbits.com/2025/02/28/threat-modeling-the-trail-of-bits-way/#fnref:4)

5. [不受欢迎的人](https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6834694)（威胁参与者角色）帮助我们描述谁在系统中（无论是合法的还是非法的）、他们拥有什么权限以及这些参与者的（滥用）用例。我们将编写简单的参与者角色作为 TRAIL 过程的早期步骤。[↩︎](https://blog.trailofbits.com/2025/02/28/threat-modeling-the-trail-of-bits-way/#fnref:5)

6. NIST SP 800-154 对攻击向量的定义（包括源组件和攻击者利用来访问目标组件中漏洞的数据）是我们威胁参与者路径概念的基础。[↩︎](https://blog.trailofbits.com/2025/02/28/threat-modeling-the-trail-of-bits-way/#fnref:6)

>- 原文链接： [blog.trailofbits.com/202...](https://blog.trailofbits.com/2025/02/28/threat-modeling-the-trail-of-bits-way)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

我们将我们的过程称为 TRAIL，它代表 T hreat and R isk A nalysis I nformed L ifecycle（威胁和风险分析驱动的生命周期）。TRAIL 使我们能够追踪和记录有缺陷的信任假设和不安全的设计决策对我们客户的架构以及支持它们的系统和流程的影响。缓解像这样的系统级发现可以消除整个漏洞类别，这意味着需要担心的零星错误报告和修复会更少。

什么是 TRAIL

多年来，我们都使用过各种威胁建模方法；每种方法都有其优势，但没有一种方法能完美地满足我们客户的需求，因此我们将我们所知道的最佳部分结合起来，并迭代构建我们自己的流程。TRAIL 最初将 Mozilla 的单组件快速风险评估 (RRA) 流程扩展到整个系统（无论大小），并结合了 NIST SP 800-154 数据中心威胁建模指南和 NIST SP 800-53 安全和隐私控制字典的部分内容。

为什么 TRAIL 威胁模型有价值

TRAIL 有三个目标：

记录当前系统架构层面和运营层面的风险；
对于每个风险，为我们的客户提供实用的短期缓解方案和长期的战略建议；
使我们的客户能够在缓解风险时自行更新威胁模型1，并且系统会随着时间的推移而发生变化。

在整个软件/系统开发生命周期（SDLC）2中，应用安全审查会产生更好的产品。SDLC 的设计阶段是进行协作式3 威胁建模练习的理想时机，该练习涉及安全工程师和构建系统的人员：还没有用户依赖于特定的系统功能，但需求主要已确定，因此更容易进行设计改进。但种植树的第二个最佳时间自然是现在。威胁建模工作在每个 SDLC 阶段都提供了价值，因为它提高了开发人员对设计选择后果的理解。

TRAIL 如何工作

模型构建

TRAIL 的基础是首先构建尽可能准确的模型。我们与客户合作以识别所有在范围内的系统组件。然后，我们将在安全控制4 限制组件之间连接的任何地方放置信任边界（或者按照安全要求和设计，应该放置）。我们将共享信任边界的组件分组到信任区域中。

我们将与客户进行广泛的交谈，并阅读他们的系统文档，以建立对系统及其 SDLC 的了解，从而发现并记录以前未书写的假设。然后，我们建立连接和威胁参与者5的相关组合，特别是对于那些跨越信任边界的连接。我们将这些连接-参与者组合称为威胁参与者路径 6。

威胁情景

从轻量级威胁模型中获得什么

轻量级威胁建模参与会产生系统设计中固有的风险的端到端、高级概述，并用一些威胁情景加上建议来说明。我们的客户通常使用轻量级威胁模型的结果来指导进一步的安全审查和修复。以下是 2023 年 Trail of Bits 对 Arch Linux 软件包管理器 Pacman 的评估中的一些威胁情景：

情景	参与者	组件
环境变量会影响 Pacman 软件包管理器的 libcurl 依赖项。例如，Pacman 通过 `http_proxy` 环境变量中定义的代理重定向其 HTTP 连接。如果攻击者将环境变量注入到 Pacman 的运行时环境中——考虑到它在安装期间以 root 身份运行，这是一个困难的前景——他们可能会导致 Pacman 表现出可利用或不良的行为。	- 本地 root	- Pacman 软件包管理器
攻击者尝试替换攻击，通过受感染的本地网络存储库或远程存储库提升流行软件包的版本。 Pacman 将始终安装其有权访问的所有存储库中软件包的最新版本。因此，如果用户同时启用了本地和远程存储库，则可以容易地诱导用户安装此版本的软件包，如果攻击者可以将相同名称、更高版本的软件包引入到其中一个远程存储库中。也可能通过 DNS 混乱实现类似的攻击（例如，如果攻击者注册一个镜像本地网络域名的域名）。请参阅这篇 GitHub 博客文章，了解针对 npm 的替换攻击。	- 存储库管理员<br>- 外部攻击者	- Pacman 软件包管理器<br>- 本地网络存储库<br>- 远程网络存储库
攻击者破坏了打包密钥并为软件包生成不同但有效的签名以引入恶意更改。在这种情况下，Pacman 会正常安装新的软件包版本，并且用户将完全没有意识到。目前，没有办法在软件包的签名更改时启用警告。	- 打包者<br>- 内部攻击者	- Pacman 软件包管理器<br>- 打包密钥

表 1： 我们 2023 年对 Arch Linux Pacman 的评估中的示例威胁情景

图 1：从 Arch Linux 信任根到运行 Pacman 的主机建模的软件包及其签名数据的数据流

更多轻量级威胁模型可以在我们的出版物存储库中的审计报告中找到，包括我们对 CoreDNS、Eclipse Jetty、Kubernetes 事件驱动自动缩放 (KEDA) 和其他产品的评估报告。

发现和后续工作

从全面的威胁模型中获得什么

在全面的 TRAIL 威胁模型中，我们将继续进行轻量级威胁模型的终点，将我们识别的威胁情景放在一起并进行更多的研究，最终提出发现和针对特定发现的建议。以下是我们 Linkerd 参与中的一些发现摘要：

在 Linkerd 参与时（2022 年），目标服务向 Linkerd 集成的 Kubernetes 集群中的 sidecar 代理提供路由信息，但缺乏内置的速率限制。这可能允许集群用户应用程序命名空间内的具有 sidecar 代理访问权限的攻击者通过重复请求路由信息来容易地导致拒绝服务，或者更改目标服务的可用性状态以强制更新 Linkerd 控制器组件。
我们还发现，没有什么可以阻止基础设施运营商使用 Linkerd CLI 工具通过未加密的 HTTP 获取 YAML 定义，包括敏感信息。这种明文数据流将削弱基础设施运营商系统的整体安全态势。
同样在当时，linkerd-viz Web 仪表板缺乏访问控制。这意味着任何攻击者只要通过简单地在 Linkerd 配置的 Kubernetes 集群上运行扫描工具就能了解 Linkerd 仪表板的网络地址，然后可以通过访问此仪表板获得关于集群中命名空间、服务、Pod、容器和其他资源的详细知识，并且可以使用此信息作为针对在集群上运行的软件的基础。

图 2：代表性的 Linkerd 部署的建模数据流

下表包括我们用于构建上述发现的一些威胁情景：

始发区	目标区	参与者	描述
外部	用户应用程序命名空间	基础设施运营商	用户应用程序与其 sidecar 代理和各自的 init 容器共享一个 Pod。因此，用户应用程序基础设施的运营商应该意识到，如果用户应用程序受到破坏，横向组件（如 sidecar 代理）也可能受到破坏。这可能会暴露命名空间内的路由信息和证书。
外部	Linkerd 命名空间	内部攻击者	有权访问托管基础设施运营商 YAML 文件的外部服务的内部攻击者可能能够操纵底层基础设施。
用户应用程序命名空间	`linkerd-viz` 命名空间	内部攻击者	访问权限仅限于应用程序命名空间的内部攻击者可以访问 Prometheus 端点以获取指标数据，这可以让他们深入了解他们原本无法看到的其他集群组件。

表 2： 我们 2022 年 Linkerd 全面威胁模型中的示例威胁情景

我们的出版物存储库中其他的全面威胁模型报告包括更多的威胁参与者路径和我们用它们构建的发现；我们为 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 发展的贡献。

我们将在我们的下一篇文章中介绍如何随着系统的变化以及修复安全问题来更新你的威胁模型！↩︎
SDLC 是一个常见的流程（我们希望你使用它！），它将人们在创建和维护系统时所做的工作组织成几个生命周期阶段：需求收集、设计、开发、测试、维护和重新评估。虽然有些人将 SDLC 与 Agile 联系起来，但使用 SDLC 来构建和衡量开发过程的进度不需要遵循 Agile 或任何其他过程或管理框架。↩︎
正如 Adam Shostack 之前所说：“[威胁建模]为安全性提供了一种结构化、系统化、全面的方法。结构化的威胁建模技术可以识别可能出错的地方，并确保你是全面的。组织获得的是团队之间的协作，而不是冲突。”↩︎
我们使用 NIST SP 800-53 安全控制系列来分类我们在威胁建模评估期间编写的发现。此分类表明了发现详细说明的系统中的控制差距。你将在我们的威胁模型报告中看到每个安全控制系列的简要定义。↩︎
不受欢迎的人（威胁参与者角色）帮助我们描述谁在系统中（无论是合法的还是非法的）、他们拥有什么权限以及这些参与者的（滥用）用例。我们将编写简单的参与者角色作为 TRAIL 过程的早期步骤。↩︎
NIST SP 800-154 对攻击向量的定义（包括源组件和攻击者利用来访问目标组件中漏洞的数据）是我们威胁参与者路径概念的基础。↩︎

原文链接： blog.trailofbits.com/202...

登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

本文参与登链社区写作激励计划，好文好收益，欢迎正在阅读的你也加入。