持续威胁建模 - Trail of Bits 博客

作者：Spencer Michaels, Paweł Płatek, Kelly Kaoudis
发布日期：2025年3月3日
标签：威胁建模, 应用安全

调整威胁模型

需要更新的内容

对于大多数系统，我们建议随着系统设计和实施的推进，至少保持以下内容的最新状态：

• 信任区域
• 威胁参与者
• 信任区域连接（非单个组件间的连接）
• 安全相关假设

当系统进入稳定状态（在SDLC术语中称为维护阶段）时，重新审视并更新以下威胁模型部分：

• 组件
• 信任区域连接
• 威胁参与者路径
• 敏感数据（密钥、密码、令牌、PII、日志、账户等）
• 相关安全控制类别

需要添加的内容

调整后的威胁模型是跟踪已修复和已接受风险的绝佳场所。在处理每个发现或威胁场景时，记录修复方式及选择该修复方案的原因——或者选择接受风险的原因。

更新威胁模型以包含新发现的风险也很有帮助。例如，如果最近发现硬件供应链存在漏洞，可以创建新章节讨论该风险并记录潜在缓解措施。

存储位置

选择威胁模型的存储位置、结构方式以及用于更新的工具。根据团队需求选择最适合的方式——确保团队能够轻松地随时间更新威胁模型。例如，可以：

• 将威胁模型转换为Markdown文档，与代码存放在同一仓库中
• 将可编辑版本的威胁模型托管为Google Doc或HedgeDoc
• 在内部开发者wiki中添加新类别或页面
• 在团队运行手册中添加威胁建模章节
• 将报告内容转换为Threat Dragon、Threagile或STIX等威胁建模工具的输入
• 使用draw.io、Lucidchart或Mermaid等工具创建新图表

对于更新后的威胁模型的第一个版本，可以直接从我们的报告中复制粘贴相关数据。然后，随着时间的推移，可以根据团队风格调整结构。我们也愿意调整报告格式以更好地满足您的需求！

修订SDLC

下一步是完善团队流程，确保威胁模型保持最新（从而保持有用）。SDLC的每个阶段都应包括更新威胁模型。

每当开发人员提出影响系统工作方式的重大设计或实施变更时，负责方需要在合并前调查并记录该变更的架构级安全影响。威胁建模生命周期的具体细节取决于现有流程。

示例

如果设计和实施在主要拉取请求中同时进行，那么每个拉取请求在合并前都应包含"更新威胁模型"的步骤。

另一方面，如果重大变更在进行任何实施前需要经过设计评审，威胁建模至少应作为设计评审讨论的一部分（考虑包括具有安全知识和新鲜视角的无偏见第三方，比如我们！），并在变更完全实施前再次进行。

假设团队在工单系统中跟踪工作。那么，当项目负责人为系统添加新功能创建工单时，应包括团队中任何工程师都可以完成的工单，以确保在设计完成后、实施完成后等时间点更新威胁模型。

或者，应指定直接负责人（如具有团队和系统背景的安全工程师）负责在新功能设计和实施过程中保持威胁模型的最新状态。

更新威胁模型

考虑以下问题以决定何时更新：

是否添加了新系统组件（例如微服务、模块、主要功能或第三方集成）？

如果是：

• 将其添加到相关信任区域下的组件列表中，如果不适用则创建新信任区域。如果参与者获得该信任区域中另一个组件的访问权限也会隐式获得新组件的访问权限，则应将新组件添加到现有信任区域。
• 将新组件与现有组件之间的任何数据流添加到信任区域连接列表中。还要注意组件将如何向新组件发送数据或从中检索数据。为每个新数据流在信任区域连接列表中添加一个条目。
• 在威胁参与者路径列表中记录参与者可能获得新组件访问权限的任何方式。请注意，任何给定参与者可能有多种方式访问单个组件或信任区域。

是否添加了新信任区域（例如通过添加新网段）？

如果是：

• 根据需要将以不同方式访问的任何系统组件重新分类到新信任区域。如果添加了新的身份验证检查或权限级别，则可能已添加新信任区域。如果服务在现有网段之间移动或重新分配了现有访问角色，可能只需将相关组件移动到不同的现有信任区域。
• 对于任何此类重新分类，更新信任区域连接列表和威胁参与者路径。

是否引入了新威胁参与者（例如新用户角色）？

如果是：

• 将新参与者添加到威胁参与者列表中。
• 识别新威胁参与者应具有访问或交互权限的信任区域和组件，并更新威胁参与者路径列表。

是否在跨越信任区域边界的系统组件之间添加了新连接（例如现有服务器实例上的新应用服务，可由不同区域的服务调用）？

如果是：

• 将新连接添加到信任区域连接列表中。务必注意连接是否加密、使用的加密类型以及连接成功所需的任何身份验证或授权数据。
• 识别哪些威胁参与者可以直接访问此新连接起源的信任区域，并将其添加到威胁参与者路径列表中。

在进行上述任何威胁模型更改时，记得相应更新系统图。

使用威胁模型

识别缺失或薄弱的安全控制

使用更新后的威胁模型作为系统地图，识别不足的安全控制，这应指导添加进一步控制或纠正任何现有控制的实施。

考虑组件之间的每个新连接：

• 是否违反任何先前持有的安全假设？
• 新连接是否跨越任何信任边界？
• 如果新路径跨越信任边界，为其设置了哪些安全控制？
• 任何先前未考虑的威胁参与者是否可以遍历该路径？
• 遍历新路径是否允许任何现有参与者获得新权限、访问新组件或数据，或建立先前无法进行的外部连接？

团队应迭代新路径，并根据威胁模型中定义的假设和控制进行考虑。如果发现任何实际风险——即未缓解的威胁——应修订系统设计以确保其尊重预期的安全属性以缓解这些风险。如果无法缓解风险，记录原因并创建响应程序。

最后，实际实施——代码和配置更改——必须正确执行设计的安全控制。例如，如果信任区域由网络访问控制划定，请确保相关网段确实应用了预期的入口/出口规则。考虑进一步与Trail of Bits合作编写自定义静态和动态分析规则，以检查这些控制是否正确实施。

威胁模型的其他用途

最新的威胁模型可以：

• 指导新设计变更。团队可以在SDLC早期避免风险。
• 指导和增强安全软件开发。工程师有资源推理系统安全性。
• 帮助团队规划事件。桌面演练和事件响应规划可以基于威胁模型。
• 优先处理即将进行的安全审计。威胁模型非常适合确定应进一步进行安全调查的方向。
• 提升安全审计。外部和内部审计员有良好的文档作为起点。
• 为最终用户提供真实文档。用户了解他们可以期望和不能期望从系统获得的安全保证。

后续步骤

没有一刀切的解决方案：从TRAIL威胁模型开始，构建自己的方法。在进行重大架构 overhaul——或任何时候需要第二双眼睛时——随时预订我们的办公时间以审查威胁模型更新，或聘请我们审查系统设计的较大变更。

随着您和团队继续发展和改进应用安全实践，以下是一些学习威胁建模的额外资源：

• Threat modeling the TRAIL of Bits way
• NIST SP 800-154: 以数据为中心的系统威胁建模指南
• NIST SP 800-53: 信息系统和组织的安全与隐私控制
• Mozilla的快速风险评估

然后，您可能想继续学习这些资源：

• Trail of Bits的威胁模型报告
• Mark Dowd、John McDonald和Justin Schuh的《软件安全评估艺术》
• Adam Shostack的《威胁建模：为安全设计》
• Martin Fowler的《开发者威胁建模指南》
• 威胁建模宣言
• Microsoft的STRIDE
• CMS的威胁建模手册
• Bruce Schneier的攻击树

脚注：

1. SDLC是一个常见流程（希望您使用它！），将创建和维护系统的工作组织为几个生命周期阶段：需求收集、设计、开发、测试、维护和重新评估。
2. 威胁建模本可以在设计和实施阶段识别Bybit的风险，帮助其开发人员从一开始就通过设计保护客户资金安全。
3. 如果认为威胁模型是机密信息，请审查工具或托管方法的安全和隐私声明。

分享选项： Twitter | LinkedIn | GitHub | Mastodon | Hacker News

最近文章：

• 非传统创新者奖学金
• 劫持您的PajaMAS中的多代理系统
• 我们构建了MCP一直需要的安全层
• 利用废弃硬件中的零日漏洞
• EthCC[8]内幕：成为智能合约审计员

© 2025 Trail of Bits. 使用Hugo和Mainroad主题生成。