什么是威胁模型,如何制作?

信息安全 威胁建模
2021-08-08 09:56:57

当有人告诉我:

这取决于您的威胁模型。

什么是威胁模型?如何为我的应用程序制作威胁模型?

4个回答

FilipedosSantos 的回答很好地解释了例如Microsoft STRIDE 方法下的正式威胁建模练习。

另一个很好的资源是executionByFork 的 github 上的威胁建模课程大纲。


当我在这个网站上使用“威胁模型”这个词时,我通常指的是不那么正式的东西。我通常用它来回应新用户询问“这安全吗?” 好像“安全”是一个是/否属性。它通常是这样的段落的一部分:

这取决于您的威胁模型。“安全”不是一回事;防范什么你的小妹妹在你的 iPhone 上窥探?外国政府将芯片焊接到您的数据中心设备上?还是介于两者之间?

我非常喜欢电子前沿基金会的威胁建模框架,它专注于提出以下三个问题:

  1. 你在保护什么?
  2. 你在保护谁?
  3. 您可以投入多少资源来保护它?

我真的很喜欢 EFF 写这篇文章的方式,因为这些简单且易于回答的问题可以指导安全背景为零的人为他们找出“适当的安全量”。

可以在OWASP 页面关于威胁建模的摘录中找到一个很好的定义

威胁模型本质上是影响应用程序安全性的所有信息的结构化表示。从本质上讲,它是通过安全眼镜查看应用程序及其环境的视图。

如何制作威胁模型将完全取决于所应用的威胁建模方法。业内最常用的方法之一是Microsoft 的,它基于STRIDE 威胁模型

通常,威胁建模研讨会/会议是由所有开发人员、产品负责人、安全专家和主持人组成的圆桌会议(如果您不是在团队中工作,可以单独完成)。相关人员将按顺序执行他们的方法提出的步骤,结果将是线程模型文档/工件。

Microsoft 威胁建模方法之一定义了 5 个主要步骤:

  • 定义安全要求。
  • 创建应用程序图。
  • 识别威胁。
  • 减轻威胁。
  • 验证威胁已得到缓解。

我工作的公司使用类似的方法,并且所有正在开发的产品都需要它。我发现一个非常有趣的区别是,我们可以为整个产品制作威胁模型,或者我们可以为每个产品用例制作威胁模型。

最后,威胁模型是许多威胁建模会议的结果,开发团队、PO 和安全专家将集思广益以发现可能的漏洞,然后使用定义的方法创建威胁模型文档。

威胁模型回答了这个问题——具体软件(或“系统”)的合理预期威胁是什么。强调具体(==不是学术/理论)和合理(==不霸道,也称为偏执)

偏执的威胁模型可以(从字面上看)瘫痪一切(不限于软件)。学术/理论威胁模型可以将防御/缓解成本增加到无穷大。

威胁模型是关于您想要保护的内容以及您必须处理的内容与您的客户或“更大的系统”预期处理的内容的生死关系。你信任谁,为什么那“为什么”部分非常重要,答案不能是“因为”。你正在定义责任的边界。

防御和缓解计划不是威胁模型的一部分。缓解是如果某事不能合理防御或感知到的威胁基本上是胡说八道或时尚(过去几年有一些 - 成为头条新闻 - 国家安全局最新))

例子:

#1假设您正在为军事承包商编写服务器以对发动机(或整个设备/车辆)进行 FEM 分析。什么是合理预期的威胁?拒绝服务和保密。什么不是?欺骗、篡改、否认、特权提升。

为什么?

身份验证和授权以及(更强大的)加密由您的软件外部的系统处理(您有理由期望由客户的“环境”处理,通常情况下是这样)。破坏“完整性”是没有意义的(提交破碎的网格进行分析),否认你不关心(有人提交了一个“破碎的网格”或一个“不是真正'他们的引擎'的网格”然后否认它 - 无关紧要和没有您的业​​务)。

拒绝服务真的会伤害你(服务器不做工作==没有钱)并且是合理的(从谚语;“俄罗斯人”到街对面的竞争到“来自中国的一般网络攻击” - 已经发生,将会发生。损坏是真实的)。保密 - 你不能相信云 - 甚至 .gov Azure,即使你是美国公司(有人会将你的线框卖给洛克希德),更不用说你的客户是中国人、俄罗斯人、德国人还是英国人...... -你有图片

#2假设您正在编写/移植会计或银行软件以“作为服务”。什么是合理预期的威胁?欺骗、篡改、否认。什么不是?拒绝服务。也许是什么?特权提升(取决于您的软件的性质)。有什么复杂的?保密。

为什么?你必须去云端(它将处理 DoS),保密是该业务线的法律类别,受法律系统保护(或不受保护)(防御会向他女朋友吹口哨的“痣” CEO 不关你的事)。你的责任变得复杂,因为你正在回答相互矛盾的要求。你需要一个律师。

另一方面,不可否认性或多或少是您业务的基础,并且经常发生。您可能会被合同甚至法律要求启用过度审计。篡改是相关的(有人证明篡改是可能的 - 不可否认性已死)并且对攻击者非常致命和有吸引力(金钱。金钱,金钱)。一个人可以在不破坏(通常的)加密的情况下进行篡改——你的“篡改”有很多条腿——现在怎么办?

欺骗不是“身份验证”——它是第 3 方能够在没有任何人注意的情况下记录交互/交易(移动资金、销售记录、所有内容)。”欺骗的第二部分实际上是篡改(能够“动态”更改数据而无需任何人注意到)。实际的“中间人”攻击。“没有任何人注意到”是定义方面。一个人根本不必破坏身份验证,最好不要破坏 - 最终的“不注意” )。

特权提升可能是您的问题,也可能不是您的问题,具体取决于您的系统作为“有线”服务提供的服务与私有/安全通道(始终是其他人的问题),谁是您的客户以及您是否想要/必须集成进入更大的系统或编写自己的系统。您可能必须同时做这两件事,但重要的是要知道是什么以及为什么。

看看事情如何很容易变得非常不同?当有人问你“你有一个威胁模型”时,他是在问“你知道在你的非常特殊的情况下你必须捍卫什么”。

威胁建模是使用模型来考虑安全性。这可以非常简单,例如“我们考虑随机预言机威胁模型”,或者它可以是一种更加结构化和系统化的分析方法,例如使用数据流图对应用程序建模并使用 STRIDE 来发现针对它的威胁。

我提倡将四个问题的框架作为威胁建模的核心:

  1. 我们在做什么?
  2. 会出什么问题?
  3. 我们要怎么做呢?
  4. 我们做得好吗?

有很多方法可以回答这些问题——我们可以将 Web 应用程序建模为状态机。我们可以使用杀伤链来解决可能出现的问题。我们可以考虑消除/缓解/转移/接受作为处理它的策略,并且在缓解中,有很多优先级方法和策略,例如重构解析代码或添加 TLS。

这个框架之所以有效,是因为它从工程师可以理解和访问的东西开始——他们正在做的事情。它还有效,因为有明确的回顾时间,有时间进行调整并帮助您学习。

它还有效,因为它包含并构建了许多其他工作——与其说“我们使用 STRIDE 来威胁模型”,我们可以说“我们使用 STRIDE 来帮助我们找出可能出错的地方”,这让我们从讨论什么是威胁建模来讨论不同的方法。

这是一种以软件为中心的方法,也有以资产为中心和以攻击者为中心的方法。以资产为中心的方法往往会失败,因为资产盘点困难且耗时;列表通常包括一些分散的东西,比如声誉。当软件项目团队接受以资产为中心的方法时,它们也会失败,因为大多数资产都远远超出了项目的范围,或者在项目的唯一控制权中识别资产很困难。攻击者角色方法往往会失败,因为不可能采访大多数攻击者,而“采访参与者”是制作角色的关键步骤。他们也有问题,列出攻击者意味着你是路径依赖的。如果你不包括孩子、巨魔或民族国家,你就会错过重要的威胁。