开发人员威胁建模指南

从技术开始

第一个建议是**首先主要关注技术威胁而不是广泛的威胁**，至少一开始是这样。

• **广泛的威胁和威胁来源**包括黑客组织、不法分子、心怀不满的员工、人为错误或新型蠕虫式恶意软件的流行。这些类型的事件从世界各地出现，变化多端、不确定且不可预测。它们与您的系统数据和服务对您组织和其他人价值有关。这些是您很容易与非技术人员谈论的戏剧性风险。
• **技术威胁和漏洞**要细化得多，例如软件中的特定弱点或缺少安全控制，例如加密或授权。这些类型的威胁来自您团队正在构建的系统的结构和数据流。通常，许多技术威胁会结合在一起，使广泛的威胁影响您的系统。

通过遵循本指南，您将主要关注查找技术威胁。这有助于简化阐述过程，因为您的系统的结构和数据流是您可以确定的东西。但这也意味着您可以从您作为软件开发人员的现有优势开始，了解技术内容。这是一个比高级风险分析威胁来源更强大的起点，您可能对此知之甚少。

但是，不要完全忘记更大的图景。对可能出现的广泛威胁的务实和基于风险的理解有助于优先考虑一个技术威胁而不是另一个技术威胁。例如，简单的人为错误通常比国家级攻击更可能发生（参见侧边栏）。这种想法可以用于选择首先检查哪些安全范围。当您首先专注于识别技术威胁时，将它们与证明修复和额外控制的更广泛威胁联系起来就容易得多。

采取协作方法

第二个建议是**采用协作的、基于团队的方法**。识别安全要求并不容易，不同的观点将带来更好的决策。总会有另一个漏洞或技术威胁要发现，因此在练习中引入各种观点可以使头脑风暴更强大。它还增加了您识别最重要威胁的可能性。在团队中进行威胁建模有助于全面解决风险，并帮助整个团队学习如何有效地思考和谈论安全问题。

从风险管理的角度来看，让产品负责人参与是一个很好的机会。产品负责人对用户行为和业务背景有软件开发人员所没有的见解。他们应该了解特定服务对业务的价值以及如果数据泄露或丢失的影响。当发生网络安全损失时，它们就是业务损失。如果最糟糕的情况发生，那么原因很可能与您的组织和您使用的技术有关。网络安全问题不仅仅是勾选技术框，而是做出明智的投资决策来保护业务。

“少量多次”的威胁建模

第三个建议是**开始“少量多次”地进行威胁建模**。与团队进行的每次威胁建模会议都应该简短且集中，以便可以快速消化成可以交付的东西。首先分析您系统中最薄的一层；您现在正在处理的内容。与其尝试从一开始就分析整个系统，不如通过一次一点地进行威胁建模来培养团队的肌肉记忆。

需要完全指定软件设计的方法与敏捷团队的工作方式不符。威胁建模没有理由需要进行详尽的前期分析。团队经常会被全面且高度结构化的威胁建模方法所压倒[1]。我见过团队尝试过这种方法，但在识别出任何真正的威胁（更不用说交付修复）之前就耗尽了时间和耐心！

与其创建和维护详尽的“威胁模型”文档，不如“少量多次”地进行威胁建模。当您以这种方式工作时，每次威胁建模会议都很小，影响很小。然而，这样做带来的累积效应却影响巨大。当您知道您将在每次迭代中都这样做时，您就更没有动力一次性完成所有工作，而更有动力优先考虑现在最重要的工作。

三个关键问题

了解威胁建模会议的简单结构，并进行一些计划，对于获得出色的结果大有帮助。

首先要介绍的是一个简单灵活的威胁建模结构[2]。这基于三个关键问题。记住这个结构会有所帮助。无论何时需要评估威胁，您都可以使用三个问题结构作为指南。就像骑自行车一样，一旦您掌握了基础知识，您就可以应用和发展这些技能。

本指南遵循三个问题结构。在每次威胁建模会议中，您应该将大约三分之一的时间用于回答每个问题。然后您将获得有用的结果。本指南的其余部分将把这个基本结构分解成更详细的步骤、指针和解释，以帮助您运行成功的威胁建模会议。

实际考虑因素

在运行威胁建模会议之前，您需要弄清楚一些事情。以下指针将帮助您进行计划。

面对面会议与远程会议

面对面的威胁建模会议可以在会议室进行，或者更非正式地在团队的正常工作区域进行（如果有空间）。典型的会议包括绘制图表以解释和探索范围、集思广益威胁，然后为待办事项列表优先排序修复。但是，面对面的会议并不总是可行。

当您远程运行会议时，您只需要稍微调整一下计划，以便每个人都能虚拟参与。您将需要视频会议和协作工具。提前商定并设置这些工具。Thoughtworks 的团队在使用各种工具方面取得了成功，包括 Mural、Miro、Google Jamboard 和 Google Docs。

在会议之前熟悉您的工具，并让参与者测试他们是否可以访问。无论您选择哪种工具，请确保您已获得组织的安全批准才能使用该工具。威胁建模输出出于多种原因代表着敏感信息，必须受到保护。

以下是一些在远程工作时需要牢记的更多要点

• 在练习之前异步创建图表会有所帮助。这是因为在虚拟白板上绘制图表会消耗大量时间。
• 更加注意创建对您用来说明系统的概念和符号的共同理解。解释图表符号、数据流箭头和数字便签的颜色。
• 更加有意地确保每个人都参与到练习中。也许可以使用一些与安全相关的脑筋急转弯作为破冰游戏。参考有关远程促进的更广泛指南。
• 如果您有一大群人，创建更小的组，然后整合输出可能更有意义。几个小型会议比一个大型会议更好，也更可持续。
• 您将需要比面对面会议更多的休息时间。远程工作很累人。

无论您的会议是远程还是面对面，您都应该争取按时完成。并取得一些具体成果！这需要纪律——促进时间安排可以由交付经理或经验丰富的确保研讨会成功的人员担任。

来自 Thoughtworks 德国的 Mona Fenzl 和 Sarah Schmid 在使用名为 Mural 的协作工具方面取得了一些成功。他们使用它创建了一个威胁建模模板，以帮助其他团队开始使用该工具。

确定会议范围

确定会议的正确重点和详细程度被称为“确定范围”。确保您在让大家聚在一起执行活动之前已经决定了这一点。以目前最有价值的东西为指导。也许只是您在本迭代中正在处理的用户故事？

不要试图一次性处理太多范围！如果您试图一次性对整个系统进行威胁建模，那么要么您在可用时间内没有发现任何结果，要么您会严重超时，而且不会有兴趣或预算再做一次。最好将威胁建模按时间段划分为可管理的块，以“少量多次”的方式执行活动。

以下是一些运作良好的范围示例

• 当前迭代中的范围。
• 即将推出的安全敏感功能，例如新的用户注册流程。
• 持续交付管道和交付基础设施。
• 特定微服务及其协作服务
• 系统的高级概述，用于识别安全技术债务。

无论您的团队选择什么范围，请确保它不会大到您在可用时间内无法覆盖。

一个已完成的示例：范围

本指南的其余部分使用一个真实的功能来展示威胁建模中涉及的具体步骤。一家零售组织的开发团队正在构建一个平台，用于销售家庭送货的杂货。以下是他们在即将到来的冲刺中拥有的史诗

作为客户，我需要一个页面，让我可以看到我的客户详细信息，以便我可以确认它们是否正确。

如果您曾经使用过在线商店，您将能够想象一个用于更新地址详细信息以及查看积分卡余额的页面。

根据经验，这个大小的功能对于威胁建模会议来说是一个相当合理的范围。

绘制“低保真”技术图

绘制图片可以让每个人都站在同一页面上。在您开始考虑威胁、风险和缓解措施之前，您需要对正在处理的软件或基础设施有一个共同的技术理解。

一个已完成的示例：低保真图表

回到上面介绍的真实功能，让我们看看团队如何选择说明新的“客户详细信息页面”功能。他们绘制了以下图表。

它说明了对系统的理解

• 基于微服务架构
• 已经有一个身份提供者，允许客户进行身份验证。
• 有一个用于客户详细信息的后端服务（用 Java 编写）。
• 有一个后端到前端 (BFF) 服务和前端 UI（用 Javascript 和 React 编写）。
• 有希望编辑其个人资料的用户，他们是客户。

不需要详细了解这些技术来遵循本指南，但这些事实说明了在绘制图表时应该讨论的细节级别。

展示数据流

添加细节以显示数据如何在您的系统中流动非常重要。

一个已完成的示例：显示数据流

在我们的例子中，添加了箭头来说明从希望查看其详细信息的客户到 UI，然后到 BFF 服务，然后到客户详细信息资源服务器以获取或更新数据的数据流。还有一个到身份服务器的数据流，该服务器发出授权会话的令牌。

还有一个授权边界，因为 UI 在互联网上，而其他组件在组织的云托管中。

一个已完成的示例：显示您的资产

该团队将客户服务存储的个人可识别信息 (PII) 和身份提供者中的凭据存储确定为具有最大业务价值的资产。

使用 STRIDE 帮助

如果您的团队从威胁建模开始，STRIDE 是完美的。STRIDE 是一个非常轻量的框架，可以帮助您开始集思广益安全威胁。它是一个记忆术语，每个字母代表一个安全概念。重点不是对您发现的内容进行分类，而是帮助您有效地集思广益。

在开始之前，花一些时间与团队一起了解和讨论这六个安全概念。为了帮助学习，Thoughtworks 创建了一套 STRIDE 提示卡。这六张卡片在下面直接链接。它们还在背面包含示例列表。

在互联网上，没有人知道你是一条狗

数据会溢出并变成指令吗？

如果没有证据，很容易否认事件发生

还有谁可能在看？

服务可能会被关闭吗？

绕过保护措施有多容易？

恶意头脑风暴

想出攻击、破坏或破坏特定软件的方法是威胁建模的本质。它也可能很有趣！

一个已完成的示例：已识别的威胁

使用之前创建的图表，团队使用 STRIDE 围绕系统中的每个数据流进行集思广益。

当我们在软件机制中发现潜在威胁时，将它们写在便利贴上，并注释低保真图表。

这是他们在会议的集思广益部分结束时想出的内容

数据流

威胁

客户→身份服务

• 身份验证基于密码，没有双因素身份验证

客户→UI

• 基于 DOM 的跨站点脚本 (XSS) 攻击

UI→Bff

• 身份令牌验证的缺失/薄弱
• 注入攻击，例如 SQL 注入、存储型 XSS
• 缺乏对呼叫者身份的记录
• 配置不当的 TLS 传输加密
• 在生产环境中启用了配置不当的 GraphQL 自省
• 来自僵尸网络的网络层流量泛滥
• 无法阻止经过身份验证的用户访问他人的详细信息
• 缺乏定期修补可能导致远程代码执行

Bff→客户服务

• '服务器到服务器' 身份验证的缺失或薄弱
• 缺乏对呼叫者身份的记录
• 过于宽松的安全组允许从互联网访问客户服务
• 无法阻止经过身份验证的用户访问他人的详细信息

请注意，许多威胁发生在数据流跨越从互联网到系统的授权边界的地方。但是，也在基于浏览器的 UI 和后端网络中识别出了威胁。

按风险优先级排序威胁

i. 分享对优先排序有用的知识

了解我们对系统风险状况的了解，这会有所帮助。在这方面不要花费超过 5 分钟。大致来说，在优先考虑威胁时，有两种类型的知识很有用。产品负责人或安全团队通常有很好的见解可以分享。

• 业务价值 - 导致组织目标陷入危险的损失是什么？是客户数据库被盗吗？由于业务损失而造成的声誉影响？
• 更广泛的威胁 - 对于这个组织来说，由于网络安全问题而导致的损失的可能根本原因是什么？我们担心欺诈吗？恶意内部人员？特别有能力的黑客？

如果小组中没有人对更广泛的风险有任何见解，那也没关系。访问此知识不是先决条件。您可以仅根据技术风险进行优先排序，并且仍然可以从威胁建模中获得很大益处。

ii. 每个人都投票选出风险最高的威胁！

对于任何以前在回顾或研讨会中进行过“点投票”的人来说，这应该很熟悉。每个人都获得一些投票，并将它们投给风险最高的威胁。也许从您的第一次会议中每个人三个投票开始。但这取决于小组中有多少人以及您发现了多少威胁。目标是缩减到最值得关注的威胁。请记住，风险不仅与威胁发生的可能性有关，还与潜在损失的规模有关。

每个人都根据他们自己对风险的感知，使用点来投票。

每个人都需要通过在便利贴上标记点来投票。每个人获得固定数量的投票。如果您认为合适，您可以对同一威胁投票多次。

以这种方式投票将产生良好的低投资风险决策，反映了小组中不同的观点。人们对风险有直观的理解，并且能够在最少的提示下投票。

iii. 识别风险最高的威胁

您需要统计每个威胁的投票数，并以某种方式标记投票数最高的威胁。也许用笔圈出风险最高的威胁。

我经常被问到我们在一次会议中应该识别多少威胁。第一次，三个可能是一个好数字。这为投入的时间提供了良好的平衡。但请使用您的判断并进行实验。可能有一个非常危险的项目 - 现在，只解决它是有意义的。同样，四五个威胁也可能来自单次会议。

iv. 拍摄注释图表的图片，并记录威胁

在此阶段使用手机摄像头拍摄照片，以捕捉集思广益和优先排序的输出。如果您使用的是远程工具，则可以截屏或导出。将图像上传到您的 Wiki 或将其存储在某个存储库中非常有意义。

将修复添加到您的待办事项列表

团队的投资必须导致后续工作。软件团队已经拥有强大的方式来表示和排序活动以交付软件：积压工作。现在是时候确定您实际需要哪些修复来降低风险。使用团队现有的流程和工作方式来支持此操作（参见侧边栏）。

反思和持续改进

反馈和持续改进是管理风险的核心。正如我在本指南开头强调的那样，我们构建的系统和它们面临的威胁都不是简单的。每个团队都不同——拥有不同的技能、工具、约束和个性。没有单一的方法可以进行威胁建模，本指南只是提供了一些入门基础。就像测试驱动开发或持续交付一样，威胁建模会奖励投资。

改进的一种方法是在运行几次会议后对您的威胁建模工作进行回顾。询问哪些方面做得很好，哪些方面可以改进。时机是否合适？范围是否过于细化？不够细化？您使用的地理位置或远程工具怎么样？会议结束后出现了什么问题？范围需要多长时间才能交付？通过提出这些问题，团队将随着时间的推移而适应并建立精通，加倍努力地进行有效的工作，并摒弃那些价值不大的工作。

随着时间的推移，您可以培养最适合您的团队或组织的实践。以下是一些后续步骤的建议

• 尝试使用不同类型的图表。对于像 OAUTH2 身份验证流程这样的东西，UML 序列图可能比简单的组件图更好。
• 使用特定领域的威胁库。有很多资源可以帮助您集思广益。OWASP 在移动或 API 方面提供了一些很棒的资源。最近对使用 ATT&CK 框架产生了很大的兴趣。
• 没有一种实践是万能的。威胁建模不是查找基本编码或依赖项问题的有效方法。使用软件交付管道中的自动化工具来补充威胁建模。
• 就像软件中的其他一切一样，如果它没有经过测试，那么您就不能认为它已经完成。使用威胁建模来发现要测试的故障条件。
• 对您的系统的风险概况进行一次会议。这种类型的分析通常侧重于您正在处理的数据类型以及您的服务对其他人的价值——在安全术语中，深入了解您的“资产”的商业价值。
• 对您系统面临的更广泛的威胁进行一次会议。通常会根据最佳可用信息（例如威胁情报、真实攻击技术的文档以及来自类似系统的真实事件）分析潜在攻击者的能力和动机。
• 加入威胁建模社区，例如 OWASP Slack 上的威胁建模频道，或关注威胁建模 SubReddit。在 Twitter 上关注其他进行威胁建模的人。

总结

安全中的许多“解决方案”似乎旨在将安全置于开发人员之外。这并不意味着它们是糟糕的解决方案。管道中的自动化检查在查找漏洞方面非常有效——您应该使用它们。渗透测试可以发现您自己无法发现的问题。具有安全默认值的平台可以消除许多常见威胁。但是，每个“解决方案”只解决一类有限的威胁。而网络风险不是一件简单的事情，它是多方面的，并且不断变化。了解这种风险是有效管理风险方法的核心。

威胁建模的杀手级应用是促进整个团队的安全意识。这是让安全成为每个人责任的第一步。就像业务成果、质量、集成和基础设施一样，安全可以成为团队考虑软件交付方式的核心。而不是在最后附加的东西。根据我的经验，一个拥有威胁建模肌肉记忆的团队是一个主动管理网络风险的团队。

我记得有人告诉我，威胁建模对于大多数开发团队来说太难了。我只是不愿意接受这种情况。我理解改进开发人员解决安全问题的方式的机会。从那时起，我帮助大量团队开始进行威胁建模，并帮助他们正确理解安全。我从未遇到过一个发现威胁建模或安全太难的团队。特别是当以一种易于理解的方式解释时。这正是我在本指南中试图做的事情。

我相信威胁建模是软件开发团队的一种变革性实践。一种协作且基于风险的实践，可以持续应用。如果您是软件团队的一员，请将本文发送给您的团队，并建议进行一次威胁建模会议。或者将其转发给您组织中负责软件安全的人员。通过抽出一点时间来运行一次会议，您可以开始。通过开始了解您的系统所需的威胁、风险和安全修复，您正在朝着有效的网络安全迈进了一步。

我希望本指南能帮助您的团队开始进行威胁建模。至少，一次会议应该立即提供价值——将良好的安全故事和验收标准添加到您的待办事项列表中。这种方法帮助 Thoughtworks 许多客户的开发团队采用了一种全面的网络安全方法。我希望它对您也有用。