系统安全设计的方法--威胁建模

一个IT系统是复杂的，随着提供更多的业务功能它会变得越来越复杂。这意味着一个IT系统的设计决策需要考虑到越来越多的情况，包括安全的情况。因此催生了DevSecOps、SDL的发展，以期规避可能导致影响业务结果的潜在安全威胁。这时除了要对IT系统进行功能建模、性能建模之外，还需要对系统安全进行建模，威胁建模是常见的一种安全建模方式。

**1.**什么是威胁建模

威胁建模的最早尝试始于攻击树(attack trees)方法的上世纪90年代，为此，微软公司发布了一份名为《The Threats to Our Products》的文件，被广泛认为是对威胁建模过程的第一个正式描述。

简单的说，威胁建模是一种帮助识别IT系统相关的威胁、漏洞以及应对策略的方法。对公司当前应用系统来说，我们可以将它限制为检查系统操作的设计，以及数据如何跨子系统边界流动，最终识别安全目标、相关的威胁、相关的漏洞和对策的方法。

**2.**威胁建模概述

我们将威胁建模抽象成图1所示的五个主要步骤。图1中，可以通过重复执行步骤2到5来逐步完善威胁模型。随着应用程序开发生命周期的推进，我们可以添加更多的细节，并发现更多关于应用程序设计的安全信息。

图1 威胁建模示意图

对图1中各步骤的初步说明如下：

步骤1：确定安全目标。明确的目标有助于帮助关注威胁建模活动，并确定在后续步骤上的工作安排和成本安排；

步骤2：创建应用程序概览。详细说明应用程序的重要特征和参与者有助于在步骤4中识别相关的威胁；

步骤3：解析应用程序。对应用程序机制的详细了解可以更容易地发现更多相关和更详细的威胁；

步骤4：识别应用威胁。使用步骤2和步骤3中的详细信息来识别与应用程序场景和上下文相关的威胁；

步骤5：识别应用漏洞。查看应用程序的各个层，以确定与威胁相关的漏洞/弱点。使用漏洞类别来帮助我们关注那些最经常犯错误的领域。

随着应用程序开发生命周期的推进，我们会逐渐向威胁模型添加更多的细节，并发现有关应用程序设计的更多细节。因为从性能和功能的角度来看，威胁建模中确定的关键资源也可能是功能和性能的关键资源，所以我们可以在平衡所有需求时重新审视和调整模型，这是正常的，也是这一过程的重要成果。

**3.**威胁建模活动的具体说明

 （假设我们当前以敏捷方法进行一个Web系统的开发工作）根据图1，总结了一个简单的敏捷威胁建模方法，如表1所示。以敏捷开发为背景，它是迭代的、增量的，并且专注于在评估各种用例/用户故事风险的同时循环提升、细化威胁模型。

表1 威胁建模活动汇总表

3.1****确定安全目标

安全目标是与数据和应用程序的保密性、完整性和可用性相关的目标和约束。它们包括: 保密：防止未经授权的信息泄露；完整：防止未经授权的信息更改；可用性：包括即使在受到攻击时也能提供所需的服务。

  特定的安全目标是项目目标的子集，通过确定关键安全目标，还有助于了解潜在攻击者的目标，并专注于应用程序中需要密切关注的领域。

从个人的经验出发，要确定安全目标，应考虑以下问题：需要保护哪些客户（端）数据？有法律法规遵从性的需求吗？有具体的服务质量要求吗？有需要保护的无形资产？

**3.2 **创建应用程序概览

在这一步中，依据概览中应用程序的功能要示，确定出应用程序的关键功能、特征和客户。这有助于在步骤4中识别相关威胁。需要注意的是，威胁建模是一个迭代过程，不要让这一步阻碍向下的步骤。即，应确定尽可能多的细节，然后随着设计的发展添加更多的细节。例如，如果当前正在进行设计，并且还没有考虑物理部署，那么我们仍然可以执行这个步骤，尽管可能利用的数据较少，但也要尽快列举所能列举的。

**3.3 **解析应用程序

  在这一步中，我们将解析应用程序以确定信任边界、数据流、入口点和出口点。我们对应用程序的机制了解的越多，发现威胁和漏洞就越容易。

**3.4. **识别应用程序威胁

在这一步中，我们将识别可能影响应用程序并危及安全目标的威胁和攻击，这些威胁会对应用程序产生不良影响。

通常我们可以使用两种基本方法。

1.从常见的威胁和攻击开始。使用这种方法，可以从按应用程序漏洞类别分组的常见威胁列表开始。然后，将威胁列表应用到应用程序架构中。例如，使用确定的场景来检查数据流，特别注意入口点和跨越信任边界的地方，我们能够立即消除一些威胁，因为它们不适用于应用程序的某些场景或边界；

2. 使用问题驱动的方法。问题驱动的方法可以帮助识别相关的威胁和攻击。可以使用STRIDE模型来询问与应用程序的架构和设计的各个方面相关的问题。这是一种基于目标的方法--考虑攻击者之考虑。例如，攻击者能够伪造身份来访问服务器或Web应用程序吗？有人会篡改网络上或数据存储中的数据吗？等等。

**3.5. **识别应用程序漏洞

在这一步中，将检查Web应用程序安全框架，并明确查找漏洞。像在上一步中识别威胁时一样，重点关注漏洞类别。一种有用的方法是逐层检查应用程序，考虑每层中的每个漏洞类别。

漏洞的识别和应用是一个事件的两个步骤，首先，通过询问问题来识别通常的功能漏洞，然后，查找功能是否有漏洞列表中的漏洞。

例如，对于一个身份验证的功能，首先，通过询问以下问题来识别身份验证漏洞: 凭证是否已存储？如果储存，它们是如何存储和保护的？然后，通过查找以下常见漏洞列表来检查身份验证: 通过未加密的网络链接传递身份验证凭据或身份验证cookies，这可能导致凭据捕获或会话劫持/使用弱密码和账户策略，这可能导致未经授权的访问/混合个性化和身份验证。

**4.**威胁建模活动之后的活动

完成威胁建模活动后，我们应当注意视情况执行以下操作:

1. 如果我们文档化了威胁模型，应保持文档轻量级并避免过度格式化，以便可以轻松地更新它。关键内容应该包括安全目标、关键场景、受保护的资源、威胁列表和漏洞列表；

2. 利用这些漏洞来帮助塑造安全设计和实现。例如，开发人员应该注意与已识别的漏洞相关的反模式，并使用模式来解决问题；

3. 使用漏洞来计划和确定系统测试的范围。例如，测试人员应该针对漏洞进行测试，以验证开发团队修复或解决了所有漏洞；

4. 跟踪系统中的漏洞并确定其优先级；

5.如果没有可跟踪和采取行动的漏洞，我们发现的威胁很容易被忽略。如果我们有高优先级威胁，而没有相应的漏洞，此时需要做出决定，是进一步调查以确定漏洞，还是将其排除在范围之外，或者接受风险？

**5. **结语

受制于篇幅，对第三节中的内容无法完全展开更详细的说明；或受制于表达能力和行文时间，上述描述也必有值得商榷之处。总的来说，威胁建模是要消耗时间成本的，但对于系统安全来说是值得的，因为面对来自方方面面的系统安全威胁，如果我们能“料敌于先”，堂堂正正做好防御措施，总比听天由命式的仓促应战更有胜算吧。