持续威胁建模：构建安全开发生命周期（TRAIL）的实践指南

调整威胁模型

虽然TRAIL威胁模型旨在为安全工程师和日常开发人员提供易用且实用的工具，但我们并不期望您维护报告中所有表格、图表和列表。我们特意使用您组织的命名和术语来标识系统组件、连接和信任区域，但报告详细展示了我们的工作过程，以便清晰说明我们在合作期间如何得出发现。您的团队现在需要决定报告中哪些内容需要持续维护。

需要更新的内容

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

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

当系统进入稳定状态（在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: Guide to Data-Centric System Threat Modeling
NIST SP 800-53: Security and Privacy Controls for Information Systems and Organizations
Mozilla’s Rapid Risk Assessment

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

Trail of Bits’ threat model reports
Mark Dowd, John McDonald, and Justin Schuh’s The Art of Software Security Assessment
Adam Shostack’s Threat Modeling: Designing For Security
Martin Fowler’s A Guide to Threat Modelling for Developers
Threat Modeling Manifesto
Microsoft’s STRIDE
CMS’s Threat Modeling Handbook
Bruce Schneier’s Attack Trees

SDLC是常见流程（我们希望您使用它！），将创建和维护系统的工作组织为几个生命周期阶段：需求收集、设计、开发、测试、维护和重新评估。 ↩︎

威胁建模本可以在设计和实施阶段识别Bybit的风险，帮助其开发人员从一开始就通过设计保护客户资金。 ↩︎

如果您认为威胁模型是机密信息，请审查工具或托管方法的安全和隐私声明。 ↩︎