我们的威胁模型

在GitHub，我们花了大量时间思考和构建安全产品-其中一个关键方面是威胁建模。此实践涉及将安全和工程团队聚集在一起讨论系统，最终生成提高系统安全性的行动项。威胁建模帮助我们更好地在安全和工程团队之间进行沟通，使安全审查流程变得更加主动，并导致更可靠、更安全的系统设计。

在我们深入了解如何在GitHub进行威胁建模之前，让我们先就什么是威胁建模达成一致。定义过程的目标可以帮助参与其中的每个人设定对结果的期望。

在GitHub，威胁建模不一定是一个特定的工具或一组可交付成果-它是一个帮助安全和工程团队围绕新的或现有系统进行持续讨论的过程。威胁模型是一种协作安全练习，我们在其中评估和验证新服务或现有服务的设计和任务规划​。本练习涉及对可能对您的服务产生负面影响的潜在安全漏洞进行结构化思考。

首先，深入研究提议的或现有的体系结构，确保每个人都了解系统是如何工作的。(如果没有别的，现在你知道了！在此期间，请将其记录下来。)。

然后，从整体上评估整个表面积，并找出最可能的折衷点。这是关键的交付成果。

针对每个折衷点制定要实施的缓解策略。因为没有人拥有无限的资源，所以这些资源很可能是优先的。

在GitHub，我们通常与每个功能团队按照设定的节奏进行威胁建模，并且在发布任何对架构进行重大更改的新功能之前。根据对功能进行的工程量的不同，您可能需要较快的节奏(每隔几个月)或较慢的节奏(每年一次)。如果您有一个现有的软件审查节奏，我们发现将其与那些现有流程集成可以帮助每个人适应添加新的安全流程。无论你的时间安排如何，都要制定指导方针，并保持灵活性。

威胁建模通常是一项协作练习，因此产品的工程团队和安全团队将聚在一起讨论体系结构和潜在的安全问题。我们的安全团队将提前向工程团队提供有关有效威胁建模的文档和示例。我们通常要求每个工程团队预先生成一个模型，涵盖系统的重要部分，作为单个威胁建模对话的一部分进行审查。及早设定这些期望(并做好功课)有助于确保会议有效。

虽然过程和讨论比具体的输出更重要，但在GitHub，我们要求工程团队带来一个在微软的威胁建模工具或OWASP的Threat Dragon中开发的威胁模型(两者都是完全免费的！)。这些工具使团队能够清楚地显示威胁模型的重要信息，如API、信任边界、依赖关系、数据存储、身份验证机制等。除了在团队之间提供一定的一致性外，如果您需要满足各种安全合规性要求，这些文件还将作为重要的辅助材料与任何审核员共享。

到了查看威胁模型的时候，我们通常安排一个小时的会议，分为两个部分。每次会议的前5到10分钟用于与工程团队一起了解正在审查的系统的设计。这一次确保每个人都站在同一立场上，并帮助澄清之前准备的威胁模式中的任何模棱两可的地方-包括正在使用的技术和任何设计怪癖。*在每个人都一致之后，我们可以直接进入安全讨论。

在安全讨论的这一点上，我们发现使用框架有条不紊地解决不同的漏洞类别是很有帮助的。我们经常使用的方法之一是微软的STRIDE模型-欺骗、篡改、否认、信息泄露、拒绝服务、特权提升-一种涵盖应用程序中可能发现的常见攻击载体的助记符。在查看总体系统的同时遍历这些类，使安全团队能够从整体上查看正在分析的系统，并确保它们涵盖了最可能的威胁。随着谈话的扩大和系统更多部分的打开，紧随其后的大步走满了一小时的剩余时间。

当发现潜在的安全漏洞或设计缺陷时，安全团队会注意到它们以及潜在的补救措施。这样我们就可以生成一个潜在更改列表，供工程团队在会议结束后考虑进行。我们发现，随着威胁建模在整个GitHub中变得越来越普遍，团队在开发系统时学会了让安全团队参与进来-这更好，因为它有助于在手按下键盘之前提前解决潜在问题和解决重大架构更改。这反过来又通过安全设计原则帮助安全团队深入部署更好的防御。

随着会议接近尾声，我们将讲述团队应该做出的主要发现和改进，并为这些发现和改进生成跟踪项目。摘要将分发给参与者，任何人都可以自由提出后续问题，以更好地充实行动项目。

正如我在上面提到的，我们发现威胁建模有很多好处，可以推动组织的注重安全的文化。在我们的案例中，我们看到了三个显著的好处：

坐下来全面讨论系统这一简单行为为每个人讨论底层系统提供了一个很好的机会。团队之间的知识共享帮助每个人增长了对环境中系统的了解。这也有助于针对威胁模型审查期间发现的问题制定漏洞缓解策略，从而改善了整个组织的安全态势。

随着威胁建模的成熟，我们致力于“左移”，或者在开发过程的早期进行，并在产品发布之前设置会话。通常，安全团队需要在发现问题时做出响应。但是，随着组织将威胁建模的时间提前到流程的早期，安全团队有时可以帮助指导工程团队从可能会带来未来漏洞的系统设计中进行指导。

对于工程和安全团队来说，这一优势是一个令人难以置信的转变。由于它定期将他们聚集在一起，因此威胁建模有助于在这些团队之间建立联系，从而更容易在两个方向上进行联系。

总而言之，我们介绍了一些有助于改进GitHub威胁建模的关键活动。以下是我们流程的快速总结：

通过遵循这些步骤，我们发现我们可以提高正在开发的系统的安全性，主动与工程团队接触(在发货之前！)，并在参与软件开发的团队之间建立牢固的联系。

我们很想听听您对您最好(或最差)的威胁建模实践的看法！用#GitHubThreatModeling标签在推特上告诉我们你的想法。