什么是威胁建模？

开放Web应用程序安全项目（OWASP）将威胁建模描述为“用于识别、量化和解决与应用程序相关的安全风险的结构化方法”。它本质上涉及在构建或部署系统时，战略性考虑的威胁，因此在应用程序生命周期的较早阶段就可以实现对预防或减轻威胁的适当控制。

威胁建模让企业对最可能影响系统的各种网络威胁进行系统性识别和评价。有了这些信息，企业就可以按照一定的逻辑顺序，利用适当的对策来处理现存的威胁，并且从具有最大风险的威胁开始。

威胁建模主要包括三大主要元素：

· 资产：应保护哪些有价值的数据和设备

· 威胁：攻击者可能对系统实施的行为

· 漏洞：有哪些漏洞让攻击者对系统构成威胁

事实上，威胁建模当然并非什么新概念，但却很少有组织以认真的态度去实现它。ThreatModeler Software公司创始人兼首席执行官ArchieAgarwal认为，威胁模型的最佳实践仍在不断涌现。他说，

最大的问题是缺乏对威胁建模的理解。其实存在很多种方式来实施威胁建模，但是公司在构建的过程中仍然感到困难重重，主要原因是，企业对于威胁建模的整体构建过程缺乏清晰地认识，企业无法确定如何将其视为一个流程，以及如何扩展它。

根据Agarwal和其他一些安全专家的说法，人们在进行威胁建模时可能易犯如下七种错误：

威胁建模7大坑

1.过于以应用程序为中心

Agarwal指出，组织在构建威胁模型时，最易犯的错误之一就是只关注应用程序本身。他说，对于威胁建模而言，企业应该尝试了解整体情况，而不仅仅是一个孤立的应用程序。
企业还需要考虑基础架构、数据库、共享组件、第三方交互和部署环境等因素。威胁可能会因应用程序是内部部署还是正在云端运行，或可以通过移动设备和其他计算端点访问而有所不同。
如果企业正在转向云计算，则需要云计算的威胁模型。企业的应用程序和数据是否会运行在专用的基础架构或共享服务器和数据库上呢？需要记住的是，当威胁建模时，企业不仅需要关注应用程序，还需要关注与应用程序相关的所有事情。开发人员在构建应用程序和部署应用程序时，需要考虑到一些修复时会遇到的问题。

2.关注漏洞而不是威胁

IDC分析师PeteLind strom表示，组织可能犯的一个错误就是过分关注漏洞，而对威胁关注不足。查看数据流和控制流，并确定应用程序中可能存在哪些漏洞是非常重要的步骤。此外，企业需要更加明确地查看威胁，并确定输入和输出的位置，以便清楚地了解自己可能将面临的风险。企业还需要尽可能地考虑到所有攻击可能，以防攻击者破坏您的控件，影响数据的机密性、完整性、可用性、生产力和专有性。
Lindstrom解释称，

现在，人们正在谈论‘熔断’（Meltdown）和‘幽灵’（Spectre）对于数据保密性的严重影响。但是，其对于数据完整性或可用性影响如何呢？攻击者是否有能力操纵这些内存表或插入数据？需要谨记的是，企业有针对特定漏洞的控制措施，而这并不意味着攻击者不会找到利用漏洞的新方法。

3.过分关注实时威胁

SANS研究所新兴安全趋势总监John Pescatore表示，在构建威胁模型时，不要过分追求最新的威胁，或过分关注特定的威胁参与者或行为类型。勒索软件和加密软件可能是当前对企业安全性影响最大的威胁。但是，企业不要专门针对这些威胁进行建模，而要专注于控制，以缓解影响系统机密性、完整性、可用性的任何威胁。
Pescatore继续道，同样地，针对企业的威胁究竟是否来自中国、俄罗斯或是塞尔维亚的行为者并不重要。因为无论他们是谁，都明确地知道如何实践自己的攻击操作。对于企业而言，最重要的是要知道面临这些威胁时应该怎么办。

企业的重点应该放在建立可重复的流程上，以便能够在每次发生变故时及时做好应对准备。完成这一过程的关键，是拥有一套标准的流程或方法，无论威胁的新颖性如何，该流程/方法每次都能以相同的方式完成。此外，企业还需要知道自己想要保护什么，以及从哪里开始落实。

4.威胁建模的威胁映射错误

Agarwal说，如果企业对于构建威胁模型的想法，只是制定一系列威胁名单，并查看企业的应用是否存在任何威胁，那么可以说，其所做的一切只是“威胁映射”（threat mapping）而已。他举例解释道，

假设您有一个在线银行应用程序，并且问了一系列问题，诸如‘你在使用Flash吗？’或‘你在使用Java吗？’亦或‘你在做认证吗？’那么可以肯定地说，您在这里做的并不是威胁建模，因为您没有围绕威胁的上下文/背景。您不知道自己是如何使用Flash的，或者正在哪里使用Flash。

Agarwal表示，同样地，仅仅因为您有一个数据库，并不意味着您必须担心SQL注入攻击问题。只有当一个从外部源接收输入的web应用程序时，SQL注入才会成为潜在的问题。当您采用清单方法评估威胁时，这种细微差别很容易被忽略。

要构建适当的威胁模型，架构图很关键。它应该显示数据库、Web服务器、操作系统层以及应用程序将运行并通过其访问的基础结构。它还应该显示所有数据和通信的流向，入口点的位置以及来自这些入口点的输入。可以说，架构图能够同时为您展示全局和边缘视角。

5.不将用户引入威胁模型

企业通常存在这样一种情况：由于过于关注对手如何攻击自己的代码，而忽略了他们可以通过其他方式来访问您的应用程序和数据。Pescatore认为，

模拟恶意行为者攻击代码的方式，对于威胁建模而言是一个非常好的主意。但是，防范网络钓鱼攻击却并非是企业可以构建的。

企业需要将用户纳入威胁模型，并考虑用户操作可能影响安全性的不同方式。企业需要查看特权管理和基于角色的访问等内容。当用户访问超出其权限或涉及机密信息的系统时，企业需要考虑其可能造成的潜在威胁。

6.对威胁建模采取“一成不变”的方法

威胁模型不能是静态的。企业不能只挑一个重要的应用程序，只对其构建一次威胁模型，就认为自己已经完成了整个威胁建模任务。只要您的企业像大多数组织一样，存在持续开发的活动，那么企业的应用程序一定会发生变化，当然，其威胁配置文件也是如此。这就意味着，企业目前的威胁模型将在三个月内过时。

所以，要将威胁建模看成一个不断循环的过程。您的威胁模型应当是动态模型，应随着时间的推移不断更改，以适应发现的新型威胁与攻击。它还要能够适应应用程序为适应业务变更的需求而不断完善与更改的自然发展过程。

7.不考虑系统对他人的影响

当构建一个威胁模型时，最好考虑一下数字可信度。如果说，您已经了解了自己所面临的所有威胁，并找出了控制或减轻它们的方法，那么接下来请看看贵组织的系统将会如何影响与之接触的其他人。

Lindstrom表示，企业需要注意自己的产出如何影响他人的安全状态。举例来说，企业可能会安置一个黑市网站，或者有人可能会劫持企业的域名，或将DDoS数据包从企业的物联网系统中弹出。企业可能不会接受广告拦截器，但是如果其网站上的恶意广告感染客户系统会发生什么情况？当企业将内容或应用放到网上时，其责任是保持它们的安全和干净，以便下游用户不会受到感染。无论是从数字可信度还是责任角度来看，这也需要成为威胁建模的一部分。

作为威胁建模练习的一部分，企业需要确保了解与开源软件和第三方组件相关的风险，而不仅仅是针对自身企业，还需要包括企业服务的下游用户。例如，如果企业提供混搭服务，则需要考虑您的数据或服务如何影响其他人的输出。如果别人依赖来自企业的GPS数据，那么企业则需要考虑数据的完整性和可靠性等问题。