面向开发人员的威胁建模指南

本文提供了明确而简单的步骤来帮助希望采用威胁建模的团队。威胁建模是设计安全系统的一种基于风险的方法。它的基础是识别威胁，以便制定缓解措施。随着网络安全风险的增加和企业对其责任意识的增强，软件开发团队需要有效的方法来将安全性构建到软件中。不幸的是，他们经常很难采用威胁建模。许多方法需要复杂的、详尽的前期分析，这与现代软件团队的工作方式不匹配。因此，与其停止一切来创建完美的威胁模型，我鼓励团队从简单开始，从那里开始成长。

您正在构建的软件的安全要求是什么？找到一个好的答案出人意料地复杂。您希望在系统的整个生命周期内防止网络损失。但是，交付这一结果的具体故事、验收标准和技术范围是什么？这就是本指南所要解决的难题。

有些无益的是，网络专家经常会问：你的威胁模型是什么？这个答案非常不具体和不确定，很像是转过身来说这要看情况。更糟糕的是，威胁模型对于大多数人来说是晦涩难懂的技术术语，增加了不必要的神秘性。如果你研究威胁建模的主题，信息可能会不堪重负，而且很难采取行动。对于威胁模型或类似的东西，没有达成一致的标准。

那么，什么是威胁模型，什么是威胁建模？这个概念的核心非常简单。它是关于了解与网络安全损失相关的原因。它是关于利用这种理解以基于风险的方式保护您的系统。这意味着从你的特定情况下的潜在威胁开始，而不是仅仅遵循清单。

了解系统的威胁模型并非易事。您可以想象到对任何系统的威胁都是无限的，而且其中很多都有可能发生。威胁的现实是许多原因综合在一起。网络威胁以意想不到的、不可预测的、甚至是混乱的方式连锁。与文化、流程和技术有关的因素都起到了作用。这种复杂性和不确定性是网络安全问题的根源。这就是为什么软件开发团队很难就安全需求达成一致的原因。

真实入侵背后的故事表明，威胁和因果关系可能是多么复杂-通常细节是令人震惊的。NotPetya的故事就是一个很好的例子。民族国家恶意软件由一个名为影子经纪人(ShadowBrokers)的组织进行交易，然后被武器化。最终的影响几乎是随机地给组织造成了重大损失。船运公司米尔斯克(Mearsk)不得不停止船运进度。糖果制造商吉百利不得不停止生产巧克力。他们各自的威胁模型是什么？什么样的开发团队能想象出如此复杂的因果关系和侧凸损伤链呢？你的团队需要多长时间来模拟这一点，以及其他所有危险的可能性？

威胁建模是否过于复杂而没有价值？开发人员是否应该只遵循一份清单，祈祷他们能走运呢？怀疑可能是健康的，但我相信，学习威胁建模是开发人员的一项关键技能。我们需要的是正确的方法和工具来驯服复杂性。本指南就是本着这种精神编写的，并从三个理念开始，这三个理念使识别良好的、基于风险的安全需求变得更加简单。

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

广泛的威胁和威胁来源包括黑客组织、不良行为者、幻想破灭的员工、人为错误或新蠕虫样恶意软件的流行。这类原因来自世界各地，极具多样性、不确定性和不可预测性。它们与您的系统为您的组织和其他人提供的数据和服务的价值相关。这些都是很容易与非技术人员谈论的戏剧性风险。

技术威胁和漏洞要细粒度得多，例如软件中的特定弱点或缺少加密或授权等安全控制。这些类型的威胁来自您的团队正在构建的系统中固有的结构和数据流。通常，一堆技术威胁组合在一起，允许广泛的威胁影响您的系统。

通过遵循本指南，您将主要专注于查找技术威胁。这有助于简化精化过程，因为您可以确定系统的结构和数据流。但这也意味着您可以从您作为软件开发人员的现有优势出发，了解技术知识。与您可能知之甚少的威胁源高级风险分析相比，这是一个更好的起点。

不过，不要完全忘记大局。对可能存在的广泛威胁的务实和基于风险的理解有助于优先考虑一种技术威胁而不是另一种威胁。例如，简单的人为错误通常比民族国家攻击更有可能(参见侧栏)。这种想法可以用来选择首先开始检查的安全范围。当您首先专注于识别技术威胁时，就更容易将它们与更广泛的威胁联系起来，从而证明修复和其他控制是合理的。

第二个建议是采用协作的、基于团队的方法。确定安全需求并非易事，多样化的视角将带来更好的决策。总会有另一个漏洞或技术威胁需要发现，因此将各种不同的观点带到练习中会使头脑风暴变得更加健壮。它还增加了您识别最重要威胁的可能性。组中的威胁建模有助于从整体上解决风险，并帮助整个团队学习如何有效地思考和谈论安全问题。

从风险管理的角度来看，让产品所有者参与进来是一个很好的机会。产品所有者对用户行为和业务环境的洞察力是软件开发人员所缺乏的。他们应该了解特定服务对业务的价值，以及如果数据泄露或丢失会带来的影响。当网络安全损失发生时，就是业务损失。如果最坏的情况确实发生了，那么原因很可能特定于您的组织和您正在使用的技术。网络安全问题不仅仅是技术上的问题，它还关系到做出正确的投资决策来保护业务。

第三个建议是从少量且经常的威胁建模开始。与团队的每一次威胁建模会议都应该足够短，足够集中，以便能够快速消化为可以交付的内容。从分析系统中可能的最薄部分开始；就是您现在正在处理的内容。与其试图预先分析整个系统，不如一次一点点地通过威胁建模来建立团队的肌肉记忆。

需要完全指定的软件设计的实践与敏捷团队的工作方式不匹配。没有理由认为威胁建模必须是详尽的前期分析。团队经常被全面且高度结构化的威胁建模方法淹没[1]。我见过团队尝试这样的方法，在识别出任何真正的威胁之前就没有时间和耐心了-更不用说交付修复了！

与其创建和维护详尽的威胁模型文档，不如少且经常地进行威胁建模。当您以这种方式工作时，每个威胁建模会话都很小，影响很小。然而，这样做的累积效果具有巨大的影响。当你知道你会在每一次迭代中都这样做时，就不会有那么多的动机去尝试一次做所有的事情，而会有更多的动机去优先处理现在最重要的工作。

本指南的这一部分将使事情变得更加详细和具体，以便您可以计划与您的团队一起开始威胁建模。

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

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

在运行威胁建模会话之前，您需要弄清楚一些事情。以下几点应该会帮助你做好计划。

尝试让整个交付团队参与每一次会议，也就是说，既有技术角色，也有非技术角色。这为谈判桌带来了更多的视角和想法，但也建立了共同的理解。排除产品所有者、业务分析师和交付经理可能意味着修复安全漏洞的工作没有完成，因为其价值将不会被广泛理解。

您绝对不需要安全专家来开始威胁建模和发现有价值的安全范围。但是，威胁建模会议是与专家、安全架构师或您的风险管理团队协作的绝佳机会。这将完全取决于您组织中的角色和专业知识。

首先，我建议会议时长为90分钟。您需要给团队时间和空间来学习所涉及的结构和安全概念。然而，一旦你开始行动，事情应该会变得更快。我参加过的最具影响力的威胁建模会议只用了不到15分钟。一旦团队中的每个人都通过练习建立了肌肉记忆，短暂而快速的训练就成为可能。

经常有人问我，威胁建模会议应该多频繁。我不认为有什么正确的答案，这取决于你的团队。我认为威胁建模就像任何其他团队设计会议一样。我不会那么僵硬地说它必须是每一周。然而，我与许多团队合作过，他们的风险概况可以证明每一次冲刺的威胁建模都是合理的。在另一个极端，如果只是几次冲刺，没有任何威胁建模，那么这种做法显然不够连续，不足以被认为是成熟的。

面对面的威胁建模会议可以在会议室进行，或者更非正式地在团队的正常工作区进行-如果您有空间的话。典型的会议包括绘制图表来解释和探索范围，集思广益，然后确定积压的修复的优先顺序。然而，面对面的会谈并不总是可能的。

当您远程运行会话时，您只需计划稍有不同，这样每个人都可以虚拟参与。您将需要视频会议和协作工具。提前同意并设置这些工具。ThoughtWorks的团队已经成功地使用了各种工具，包括Mtal、Miro、Google Jamboard和Google Docs。

在会议开始前习惯使用您的工具，并让参与者测试他们是否拥有访问权限。无论您选择哪种工具，请确保您已获得组织的安全批准才能使用该工具。由于多种原因，威胁建模输出代表敏感信息，必须加以保护。

它可以帮助您在练习之前异步创建图表。这是因为在虚拟电路板上绘制图表会耗费大量时间。

更要注意建立对用来说明系统的概念和符号的共同理解。解释数字贴纸的图表符号、数据流箭头和颜色。

更有意识地确保每个人都参与到练习中来。也许可以使用一些与安全相关的脑筋急转弯来打破僵局。请参阅更广泛的远程促进指南。

如果您有一个很大的团队，那么创建较小的团队然后合并输出可能是有意义的。几个小会议比一个大会议更好，更可持续。

在面对面的谈话中，你需要更多的休息时间。远程工作很累人。

不管你的会议是远程的还是面对面的，你的目标都应该是按时完成。并带来了一些具体的结果！这需要促进纪律的时间安排，可以是由交付经理或有经验的人担当的角色，以确保研讨会成功。

为您的会议决定正确的重点和详细程度称为确定范围。在召集人们一起进行活动之前，请确保您已经决定了这一点。以当下最有价值的东西为指导。也许这仅仅是您在这个迭代中工作的用户故事？

不要试图一次咬掉太多的范围！如果您尝试一次对整个系统进行威胁建模，要么在可用时间内没有任何发现，要么会严重超支，并且没有胃口或预算再做一次。更好的做法是将威胁建模为可管理的块，执行少量且经常执行的活动。

无论您的团队选择什么范围，都要确保它不会太大，您无法在可用时间内完成。

本指南的其余部分使用实际功能来显示威胁建模所涉及的具体步骤。在一家零售机构，有一个开发团队正在搭建一个平台，销售送货上门的食品杂货。以下是他们在即将到来的Sprint中的史诗：

如果您曾经使用过在线商店，您将能够想象一个页面，该页面用于更新地址详细信息，或许还可以查看会员卡余额。

根据经验，这种规模的功能对于威胁建模会话来说是相当合理的范围。

图表是解释和探索软件是如何构造和设计用于通信的完美工具。本指南的这一部分提供了图表上的详细说明，该图表将作为您的威胁建模会话的基础。

画一幅画会让每个人都心中有数。在您开始考虑威胁、风险和缓解措施之前，您需要对您正在处理的软件或基础设施有共同的技术理解。

幸运的是，开发人员可以轻松地绘制图表来探索软件设计。在白板或活动挂图上画一张简单的技术图表，说明你同意的范围，充分利用这些既定技能。

没有什么需要是复杂或完美的-只需画出主要组件的方框并给它们贴上标签即可。

归根结底，系统的设计是为了让人们能够做事。用户很重要，因为他们是被授权访问系统中的东西的人。在您的图表上表示并标记它们。

某些用户可以比其他用户更受信任。例如，最终用户在系统中执行操作的自由通常比管理员少。如果多个用户组与会话范围相关，则表示并标记每个组。

并非所有系统都是面向用户的。如果您的系统是后端系统(可能是只接受来自其他系统的请求的下游微服务)，则表示授权与系统交互的协作系统。

信任本质上是关于谁或什么人应该有自由去做一件特定的事情。一定要说明这些演员，因为他们对安全很重要。

回到上面介绍的真正功能，让我们看看团队是如何选择演示新的客户详细信息页面功能的。他们画了下面的图。

有前端(BFF)服务的后端和前端UI(用Javascript和Reaction编写)。

本指南不需要详细了解这些技术，但这些事实说明了您在绘制图表时应该讨论的详细程度。

攻击者通常使用与合法用户相同的路径绕过系统。不同的是，他们滥用它们，或者以没人想到要检查的方式使用它们。因此，重要的是要显示系统周围的可信路径，以帮助了解真正的威胁可能发生在哪里。

显示数据流-使用箭头显示数据流，从用户和协作系统开始。目前，大多数数据流是请求-响应的，因此是双向的。但我建议您从发出请求的地方画方向箭头。根据经验，这使得以后对威胁进行头脑风暴变得容易得多。

威胁更有可能来自某些网络。网络配置为限制流量从一个地方流向另一个地方的自由。这种限制性(或开放性)将有助于确定哪些威胁是可能的或可能的。开放的互联网比保护完善的后端网络更危险(即使您的后端网络是您的云提供商托管的私有网络)。

用另一种颜色绘制虚线，以显示系统中不同网络之间的边界。这些通常被称为授权边界。有时，说明网关设备(如负载均衡器或防火墙)是值得的。其他时候，这些设备对于您在该会话中的范围并不是那么重要，这也是可以的。如果您不确定，邀请具有DevOps或基础架构知识的人参加您的下一次会议可能是有意义的。

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

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

在图表上快速指出具有业务价值的数据或服务所在的位置是很有帮助的。例如，这可能是您存储个人数据的位置。如果您的系统处理支付，可能是服务才能做到这一点。系统中的资产是需要保密或完好无损的信息，也是需要保持可用的服务。

不要在这一步上花太长时间。其目的只是提供一点背景信息来帮助集思广益和确定优先顺序。如果你在这上面花的时间超过5分钟，那么它可能太长了。

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

我们将以分期付款的方式发布这篇文章。未来的部分将介绍我们如何探索可能出错的地方，以及我们应该做些什么。

要了解我们何时出版下一期，请订阅网站的RSS源、Jim的Twitter流或Martin的Twitter流。

感谢Martin Fowler、Adam Shostack、Charles Weir和Avi Douglan为本文的早期草稿提供了详细、深思熟虑的反馈。任何复杂或细微的差别都要归功于他们。

感谢ThoughtWorks的Nalinikanth Meesala、Mona Fenzl和Sarah Schmid，他们帮助我提供了远程运行威胁建模会话的指导-指南的这一部分应该归功于他们！

感谢英国国家网络安全中心社会技术小组(以及RISCS下以开发者为中心的安全研究组合)的工作人员帮助我认识到威胁建模并不简单。

感谢参与OWASP威胁建模项目的每一个人，感谢他们的所有意见和公开分享。

..