将威胁建模作为战略开发工具 - Optimism

在加密技术中的安全角色需要稳定、有条不紊的工作。弄清楚一个复杂协议的安全性确实具有挑战性，而有效的威胁建模是一种结构化的方法，可以及早发现薄弱点，以便你可以修复它们。这是一个简单的过程，利用工程师和业务人员对风险和优先级的了解，创建一条通往更强大产品的清晰路径。

在 OP Labs，我们有一个庞大的安全团队。即使拥有我们所有的专业知识，我们也并不总是有直觉来判断应该将安全工作重点放在哪里。威胁建模指导我们，并增强我们对发布的信心。

在本文中，我将向你展示我们如何进行威胁建模，以便你也能获得信心，确信自己正在解决正确的安全漏洞。

这个过程旨在易于理解和参与，特别是如果你喜欢学习新方法和培养技能的话。让我们开始吧。

威胁建模如何适应安全策略

让我们介绍一个基本的安全模型，以便我们了解威胁建模的适用范围。

当我们编写一个功能时，我们会添加多层安全措施。其中最基本的是全覆盖单元测试。当你进行单元测试时，会有一种诱惑，只测试每个参与者都按照预期行事的“愉快路径”。也就是说，测试你的代码是否能完成它应该完成的事情，我们认为这才是最重要的部分。

但是，当你进行全覆盖的单元测试时，你也在测试该功能是否没有做它不应该做的事情。你在检查当某些参与者做错事时，是否会有一个受控和预期的结果。

通常，在测试过程中，你会发现存在参与者会做出意想不到的事情的风险，并且你希望将其行为造成的损害限制在他们自己、其他参与者或你的功能本身。

这种控制意外情况的过程对于保护应用程序至关重要。几乎不可能知道产品可能出现的所有问题，但是通过减少意外结果的空间，我们可以大大降低风险。

在单元测试之后，我们会定期添加更多安全措施。我们进行模糊测试（fuzz testing）、符号执行、形式化验证、审计、竞赛和漏洞赏金计划。所有这些都旨在发现你的功能产生意外结果的新方法。

但是，你怎么知道你需要哪些安全措施？你怎么知道你已经拥有足够多的安全措施？你怎么知道它们覆盖了正确的组件？你怎么知道是否需要构建自定义安全措施？

对此的答案是威胁建模。这就是我们确信已在正确的位置应用了足够多的安全措施，以达到我们需要的信心水平的方式。

头脑风暴可能的结果

开始威胁建模的最佳方法是考虑该协议可能发生的最坏结果是什么。对于从事加密技术安全工作的人来说，这个列表通常会盘踞在他们的脑海中。

当我在 Yield Protocol 工作时，我们最关心的是用户资产被盗，但我们也担心在从用户那里转移资产时，将他们丢弃在某些无法找回的位置，以及其他一些令人讨厌的结果。

现在在 OP Labs，我们首先担心桥中的资产，然后是链长时间停滞不前，然后是其他较小的不愉快结果。

一旦你花时间写下所有内容，任何负面结果的列表都可以很容易地按照损害程度从最坏到最轻进行排序。然后，你将从最可怕的结果开始进行威胁建模，因为它们最有可能产生需要执行的紧急缓解措施。

构建结果树

让我们从头开始构建一个威胁模型。首先是一个小的，然后是一个更复杂的。构建这些模型的方法有很多，但在本文中，我们将遵循我们在 OP Labs 使用的非常简单的过程。

我们的威胁模型是树。在每个根节点中，你都有一个我们想要防止的结果。例如，我们的桥被耗尽，或者一条链停止足够长的时间以至于我们的用户注意到。

从每个结果开始，我们包括可能导致它的所有事件。这些通常是系统内的组件故障，但它们也可能是任何性质的外部要求。

在以下示例中，对于一个非常简单的链上无需许可的交易所，我们有一个想要避免的结果，即池中的资产被耗尽。我们将每个池中的代码任意分为两个组件，即支付函数和转移函数，因为我们了解到这两个组件中的任何一个出现故障都可能导致池被耗尽。

这是一个任意的划分，但这没关系。只要叶子不重叠，将复杂系统划分为更简单的系统将有助于你找到风险所在。你应该依靠构建该功能的工程师，他们通常可以用孤立的组件来解释它。

还有一些缺失的组件，我们也可以将其包括在内。如果底层区块链软件中存在错误怎么办？随意包括你认为相关的任何内容，稍后你将发现它是否重要。

为了继续，让我们构建一个更复杂的树。在这个树中，我们有一个链上代币化的金库，它使用外部预言机来计算其资产的价值，并且我们已经决定应该更详细地研究这个组件。

这一个更复杂，但它是以相同的自上而下的方法构建的，直到我们认为我们已经深入到足够的特定组件中。请注意，我们可以描述两个必须同时失败的组件才能导致更高级别的组件失败。当某些安全功能已经实现时，这种情况很常见。

这棵树可以从叶子中读取为组件故障和外部事件的级联，这些故障和事件导致用户可以感知到的结果。这棵树应该具有合理的易读性和描述性。应该很容易理解发生了什么，并且不应滥用抽象。

例如，你可以说外部预言机下的数据处理中的故障会导致外部预言机向支付函数提供不正确的数据，这可能导致池被耗尽。

在上面的示例中，如果我们的数学模块失败，则不变量模块也需要失败，支付函数才能出现故障。

你也可以向上构建树。你可以获取任何孤立的组件并调查如果它失败会发生什么。此组件故障可能会导致更大的系统发生故障，直到用户注意到它，那时你已经达到了一个结果。如果应该有安全措施来捕获此级联故障，请将其添加为节点并假定它也失败。

无论你从哪个方向构建树，以及如何将你的产品划分为系统和组件，你最终都会得到许多树。对于每棵树，你都将拥有一个想要避免的结果，以及一个组件层次结构，这些组件的故障会导致该结果。

如果相同的组件和子树导致不同的结果，则可能会出现重复。在这些情况下，我们专注于最严重的结果。让我们看看如何评估它。

计算事件的可能性

在 OP Labs，我们对每个事件使用四个级别的可能性：

• 肯定会在短期内发生（紫色）

• 很可能在一年内发生（红色）

• 可能会在两年内发生（黄色）

• 几年内不太可能发生（绿色）

在为结果分配可能性时很难确定，但是通常更容易推断我们对较小组件的逻辑的理解程度。只要明确或多或少正确就足够了，负责系统各个部分的专家就可以很好地为较小组件分配故障可能性。

可能性会在树的节点中向上组合，以达到结果的可能性。具有两个不同可能性的叶子的节点的可能性，如果与默认的 OR 组合，则取最有可能的，如果与 AND 组合，则取最不可能的。

在下面的树中，即使二级节点是紫色的，它也与黄色节点进行了 AND 运算，因此它们的组合可能性是黄色，并且被来自三级节点的红色覆盖。根的结果将至少是红色（很可能在一年内）。

如何避免灾难

现在我们知道各个组件的故障如何导致不良结果，我们可以专注于这些故障并提出缓解措施。

在我们的示例中，假设我们很高兴金库在第一年内没有被耗尽，因为我们知道到那时我们将制定一项长期计划。然后我们需要以红色或紫色的可能性为目标，我们有其中两个。

假设我们问开发人员如何更安全，他们建议为红色叶子实施校验和，并为紫色叶子实施形式化验证。

但是，我们知道紫色叶子与黄色叶子进行了 AND 运算，因此我们不需要该缓解措施。似乎如果我们实施校验和，我们将达到所需的风险水平。这是生成的树：

可以重复此过程，直到我们制定一个工作计划，以将每个结果的风险降低到所需的风险水平。

结论

在 OP Labs，我们已经在几个版本中使用了这种威胁建模系统的变体。在每次威胁建模练习之后，我们都会识别出具有不可接受风险的组件，并且我们将实施针对这些特定组件的缓解措施。

我们现在将此过程用于互操作，这可能是我们有史以来最复杂的版本。这种威胁建模使我们能够利用在各自组件上工作的各个工程师的专业知识，以了解我们对最小组件的了解程度，并为安全发布制定路线。

我们确定了许多要避免的独特结果，并且它们组合的威胁树具有一百多个节点。为了降低任何这些结果发生的可能性，我们正在实施数十项缓解措施。

使用本文中描述的过程，你应该能够增加你正在从事正确的事情以安全地发布软件的确定性，这对我们所有人都有好处。

在 OP Labs，我们正在招聘 准备在技术和安全的最前沿工作的人员。如果你想与世界一流的团队合作进行世界一流的项目，请联系我们！

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