持续威胁建模 - 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的攻击树

如果您喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News

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