安全 - 持续性TRAIL

你刚刚和我们一起完成了一项威胁建模练习。你已经拿到了我们的最终报告。你甚至可能已经开始修复我们发现的问题了！但威胁建模只能记录评估时系统中存在的风险。随着你不断添加新的组件、安全控制和功能，我们的威胁模型是否仍然准确地描述你的系统？你的工作引入了哪些新风险？

你和你的团队应该随着系统的变化逐步更新你的威胁模型，将威胁建模集成到你的 SDLC1 的每个阶段，以创建一个威胁和风险分析指导的生命周期 (TRAIL)。在这里，我们将介绍如何做到这一点：如何进一步定制我们构建的威胁模型，如何维护它，何时随着开发的继续更新它，以及如何利用它。

调整威胁模型

虽然我们希望 TRAIL 威胁模型对于安全工程师以及每天在你的系统上工作的开发人员来说都是平易近人和有用的，但我们并不期望你维护我们报告中的所有表格、图表和列表。我们有意使用你组织的命名和术语来识别你系统的组件、连接和信任区域，但我们的报告详细展示了我们的工作，以便清楚地了解我们如何在参与过程中得出结论。你的团队现在需要决定从我们的报告中保留哪些项目以供将来使用。

要更新什么

对于大多数系统，我们建议至少保持以下事项的更新，因为系统设计2和实施在继续：

• 信任区域

• 威胁行动者

• 信任区域连接（不是单个组件之间的连接）

• 与安全性相关的假设

一旦你的系统稳定（在 SDLC 术语中，它进入维护阶段），请重新审视并更新以下威胁模型部分：

• 组件

• 信任区域连接

• 威胁行动者路径

• 敏感数据（密钥、密码、Token、PII、日志、帐户，等等）

• 相关的安全控制类别

要添加什么

你调整后的威胁模型是跟踪已修复和已接受风险的绝佳场所。在你解决我们披露的每个发现或威胁场景时，记录你是如何修复它的，以及为什么你选择该修复选项而不是其他选项——或者为什么你选择按原样接受风险。

使用新发现的风险更新你的威胁模型也可能很有帮助。例如，如果你最近发现你的硬件供应链容易受到攻击，你可以创建一个新部分来讨论该风险并记录潜在的缓解措施。

放在哪里

选择威胁模型将存储在哪里，如何构建它，以及你将使用哪些工具来更新它。以最适合你需求的方式进行此操作3——只需确保你的团队实际上乐于随着时间的推移更新威胁模型。例如，你可能决定：

• 将威胁模型转换为与你的代码位于同一存储库中的 Markdown 文档

• 将威胁模型的可编辑版本托管为 Google Doc 或 HedgeDoc

• 向你的内部开发人员 wiki 添加新类别或页面

• 将威胁建模部分添加到你的团队运行手册中

• 将报告内容转换为威胁建模工具的输入，如 Threat Dragon、Threagile 或 STIX

• 使用像 draw.io、Lucidchart 或 Mermaid 这样的工具来创建新图表

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

完善你的 SDLC

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

每次开发人员提出影响系统应如何工作的重要设计或实现更改时，负责方都需要在可以合并该更改之前调查并记录该更改的架构级安全影响。你的威胁建模生命周期的具体细节将取决于你现有的流程。

例子

如果设计和实现同时发生在主要的 pull request 中，那么每个 pull request 都应该包括一个“更新威胁模型”步骤，然后才能合并 pull request。

另一方面，如果大的更改在任何实现发生之前都要经过设计审查，那么威胁建模至少应该作为设计审查讨论的一部分进行（考虑包括一个公正的第三方，具有安全知识和新鲜的眼光，比如我们！）并且在更改被认为已经完全实现之前再次进行。

假设你的团队在票务系统中跟踪他们的工作。然后，当项目负责人创建票证以向系统添加新功能时，他们应该包括团队中的任何工程师都可以完成的票证，以确保在设计完成后、实现完成后等更新威胁模型。

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

更新你的威胁模型

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

此更改是否添加了新的系统组件（例如，微服务、模块、主要功能或第三方集成）？ 如果是这样：

• 将其添加到相关信任区域下的组件列表中，或者如果没有适用的，则创建一个新的信任区域。如果行动者获得对该信任区域中另一个组件的访问权限也会隐式地获得对新组件的访问权限，则应将新组件添加到现有信任区域。

• 将新组件和现有组件之间的任何数据流添加到你的信任区域连接列表中。还要注意组件将如何向新组件发送数据或从中检索数据。每个新的数据流在信任区域连接列表中添加一个条目。

• 在你的威胁行动者路径列表中记录行动者可能获得对新组件访问权限的任何方式。请记住，任何给定的行动者可能有多种方式访问单个组件或信任区域。

此更改是否添加了新的信任区域（例如，通过添加新的网段）？ 如果是这样：

• 根据需要将以不同方式访问的任何系统组件重新分类到新信任区域中。如果添加了新的身份验证检查或权限级别，则很可能添加了新的信任区域。如果服务在现有网段之间移动或现有访问角色被重新分配，则可能只需将相关组件移动到不同的现有信任区域中。

• 对于任何此类重新分类，请更新你的信任区域连接和威胁行动者路径列表。

此更改是否引入了新的威胁行动者（例如，新的用户角色）？ 如果是这样：

• 将新的行动者添加到你的威胁行动者列表中。

• 识别新的威胁行动者应具有访问或交互权限的信任区域和组件，并更新你的威胁行动者路径列表。

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

• 将新的连接添加到你的信任区域连接列表中。请务必注意连接何时加密、使用的加密类型以及连接成功发生所需的任何身份验证或授权数据。

• 识别哪些威胁行动者可以直接访问此新连接的发起信任区域，并将它们添加到你的威胁行动者路径列表中。

在进行上述任何威胁模型更改时，请记住也要相应地更新系统图。

使用你的威胁模型

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

像系统地图一样使用更新后的威胁模型来识别不足的安全控制，这些控制应指导添加更多控制或更正任何现有控制的实现。

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

• 它是否违反了任何先前持有的安全假设？

• 新的连接是否跨越任何信任边界？

• 如果新路径跨越信任边界，那么有哪些安全控制措施到位？

• 任何先前未被考虑的威胁行动者是否可以遍历该路径？

• 遍历新路径是否允许任何现有行动者获得新的权限、访问新的组件或数据，或者建立他们以前无法建立的外部连接？

你的团队应迭代新路径，并在威胁模型中定义的假设和控制的背景下考虑它们。如果你发现任何实际风险——即，未缓解的威胁——你应该修改你的系统设计，以确保它尊重你旨在减轻这些风险的安全属性。如果无法减轻风险，请记录原因并创建在发生时响应它的程序。

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

威胁模型的其他用途

最新的威胁模型可以：

• 为新的设计变更提供信息。你的团队可以在 SDLC 中尽早避免风险。

• 指导和加强安全软件开发。工程师有一个资源来推理系统的安全性。

• 帮助团队计划事件。桌面演练和事件响应计划可以基于威胁模型。

• 优先考虑即将到来的安全审计。 威胁模型非常擅长确定应该在哪里进行进一步的安全调查。

• 促进安全审计。外部和内部审计师都有良好的文档可以开始。

• 为最终用户提供真实的文档。用户被告知他们可以和不能从系统中获得哪些安全保证。

下一步

没有一刀切的解决方案：从你的 TRAIL 威胁模型开始，构建你自己的方法。如果发生重大的架构改造——或者任何时候你想有第二双眼睛——请随时预订办公时间与我们一起审查你的威胁模型更新，或者让我们审查对你的系统设计的更大改动。

随着你和你的团队不断发展和改进你的应用程序安全实践，以下是一些其他资源，用于了解威胁建模：

• TRAIL of Bits 的威胁建模方式

• NIST SP 800-154: 数据中心系统威胁建模指南

• NIST SP 800-53: 信息系统和组织的安全和隐私控制

• Mozilla 的 快速风险评估

然后，你可能想继续使用这些资源：

• Trail of Bits 的威胁模型报告

• Mark Dowd、John McDonald 和 Justin Schuh 的《软件安全评估的艺术》(The Art of Software Security Assessment)

• Adam Shostack 的《威胁建模：为安全而设计》(Threat Modeling: Designing For Security)

• Martin Fowler 的《面向开发人员的威胁建模指南》(A Guide to Threat Modelling for Developers)

• 威胁建模宣言

• 微软的 STRIDE

• CMS 的 威胁建模手册

• Bruce Schneier 的 攻击树

• • *

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

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

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

• 原文链接： blog.trailofbits.com/202...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～