本页内容

	本模块内容
	目标
	适用范围
	如何使用本模块
	开始操作之前
	威胁建模原理
	步骤 1：识别资产
	步骤 2：创建体系结构概述
	步骤 3：分解应用程序
	步骤 4：识别威胁
	步骤 5：证明威胁
	步骤 6：评估威胁
	接下来要做什么？
	小结

本模块内容

威胁建模使您可以对最可能影响系统的威胁进行系统地识别和评估。

威胁建模具有一种结构化方法，与在未准确知晓每个功能所要致力解决的威胁的情况下无计划地应用安全保护功能相比，使用此方法更节约成本、更有效。

阅读完本模块并将威胁建模方法学应用到 Web 应用程序后，您将能够基于对应用程序漏洞的充分理解而对现存的威胁进行识别和评估。通过此信息，您可以从代表最强大风险的威胁开始，按照逻辑顺序使用相应的对策来解决现存的威胁。

当 Web 应用程序暴露在非安全环境（例如 Internet、Intranet 和 Extranet）中时，没有一种方法可以确保系统的绝对安全。唯一可能的解决方案是承认威胁的存在，然后减少或处理相关的危险。威胁建模使您可以作出分析，并关注相关问题的资源，从而使投资回收最大化。

目标

使用本模块可以实现：

适用范围

Web 应用程序

如何使用本模块

本模块概述了识别并记录应用程序所面临的威胁的一般过程。为了充分理解本模块内容，请：

开始操作之前

启动威胁建模过程之前，需要充分理解以下基本术语：

让我们拿一所房子进行类推：房子中的珠宝相当于资产，窃贼相当于攻击者。门是房子的一种功能，而打开的门就代表一种安全漏洞。窃贼可以利用打开的门进入房子，并盗窃珠宝。也就是说，攻击者利用安全漏洞访问资产。此例中相应的对策是将门关闭并锁上。

威胁建模原理

威胁建模不应当是一次性的过程，而应是在应用程序设计的早期阶段启动、贯穿于整个应用程序生命周期的一个迭代过程。对此，我们给出两方面的原因：首先，它不可能一次性识别所有可能的威胁。其次，由于应用程序很少是静态的，它需要不断增强其功能并作出调整以适应不断变化的商业需求，因此，随着应用程序的发展，应当重复执行威胁建模过程。

过程

图 3.1 显示了威胁建模过程，您可以通过 6 个阶段完成此过程。

注意：下面的过程布局可以用于当前正在开发的应用程序和现有的应用程序。

图 3.1
威胁建模过程概述

输出

威胁建模过程的输出是一份提供给项目组各个成员的文档。它使这些成员可以清楚地理解需要解决的威胁问题以及如何解决威胁问题。威胁模型由应用程序体系结构的定义和用于应用程序脚本的威胁列表组成，如图 3.2 所示。

图 3.2
威胁模型的组件

步骤 1：识别资产

识别需要保护的资产。需要保护的资产范围从绝密数据（例如客户或订单数据库）到网页或网站不等。

步骤 2：创建体系结构概述

此步骤的目标是介绍应用程序的功能、应用程序的体系结构、物理部署配置以及构成解决方案的技术。您应当在应用程序的设计或实现中不断查找潜在的安全漏洞。

在该步骤中，需要执行以下任务：

识别应用程序的功能

识别应用程序的功能以及应用程序如何使用并访问资产。文档使用案例来帮助您和其他人理解如何使用应用程序，还可以帮助您避免应用程序被错误地使用。使用案例可以将应用程序的功能放在具体环境中考虑。

此处列出了用于某个自助员工人力资源应用程序的一些样例使用案例：

在上述案例中，您需要了解违反商业规则的含义。例如，假设某个员工试图修改其他用户的个人详细资料，则根据已定义的应用程序的要求，不应当授予他或她访问这些资料的权限。

创建体系结构图表

创建高水平的体系结构图表，用于说明应用程序的物理部署特性和应用程序及其子系统的组成和结构，例如图 3.3 中的图表。根据系统的复杂性，您可能需要创建附加图表，以着重说明不同部分。例如，一个图表用于构造中级应用程序服务器的体系结构模型，另一个图表用于构造与外部系统交互作用的模型。

图 3.3
样例应用程序体系结构图表

首先绘制一张草图，用于说明应用程序及其子系统的组成和结构以及应用程序的部署特性。然后，通过添加有关信任边界、验证和验证机制的详细信息来完善此图，并注明何时需要这些信息（通常在步骤 3 中分解应用程序时）。

识别技术

识别用于实现解决方案的特定技术。此阶段有助于您在此过程后期关注特定技术的威胁。还有助于您确定使用正确的和最恰当的缓解技术。最可能识别的技术包括：ASP.NET、Web 服务、企业服务、Microsoft.NET 远程和 ADO.NET。另外，还要识别应用程序将调用的任何未处理的代码。

使用类似于下面的表 3.1 来说明这些技术。

表 3.1 实现技术

步骤 3：分解应用程序

在此步骤中，您将应用程序分解，以便基于安全漏洞的传统领域，创建应用程序的安全配置文件。您还将识别信任边界、数据流、入口点和特权代码。对应用程序了解得越深入，就越容易发现威胁。图 3.4 显示了分解过程的各个目标。

图 3.4 应用程序分解的目标

在该步骤中，需要执行以下任务：

识别信任边界

识别包含应用程序的每个有形资产的边界。这些资产由应用程序设计确定。对于每个子系统，请考虑是否信任上游数据流或用户输入，如果不信任，请考虑如何对数据流和输入进行验证并授权。同时请考虑是否信任呼叫代码，如果不信任，请考虑如何对呼叫代码进行验证并授权。您必须能够确保相应的安全措施可以将所有入口点保护在特定的信任边界内，并确保容器入口点可以充分验证通过信任边界的所有数据的有效性。

从分析来自代码透视的信任边界开始。代表一种信任边界形式的程序集是一个很好的起点。哪些集合信任哪些其他集合？特定程序集是否信任其呼叫的代码？或者程序集是否使用代码访问安全来为呼叫代码授权？

同时请考虑服务器信任关系。某个特定服务器是否信任上游服务器对最终用户进行验证并授权？或者服务器是否为自己提供安全保护服务？另外，服务器是否信任上游服务器传输格式正确的数据？

例如，在图 3.3 中，Web 应用程序通过使用一个固定的信任身份（此案例中为 ASPNET Web 应用程序过程账户）来访问数据库服务器。在此脚本中，数据库服务器信任应用程序服务器对呼叫者进行验证和授权，并代表被授权的用户仅转发有效的请求数据。

注意：在 .NET 框架应用程序中，程序集将定义最小的信任单元。无论何时数据越过程序集边界（根据定义，它包括应用程序域、进程或设备边界），容器入口点应验证其输入数据的有效性。

识别数据流

简单的方法是从最高级别开始，然后通过分析各个子系统之间的数据流来反复分解应用程序。例如，先分析 Web 应用程序和企业服务应用程序之间的数据流，然后再分析各个服务组件之间的数据流。

越过信任边界的数据流是至关重要的，因为越过了自己的信任边界的代码应当假定数据是恶意的并执行数据有效性的完全验证。

注意：数据流图表 (DFD) 和顺序图表有助于对系统进行正式的分解。数据流图表 (DFD) 是数据流、数据存储以及源数据和目标数据之间关系的图形表示法。顺序图表显示了一组对象如何按照事件的排序进行通力合作。

识别入口点

应用程序的入口点同时提供了攻击的入口点。入口点可能包括用于侦听 HTTP 请求的前端 Web 应用程序。此入口点本来是要暴露给客户端。其他入口点（例如，由跨越应用程序各个层的子组件所暴露的内部入口点）的存在仅用于支持与其他组件之间的内部通信。但是，您应知道这些入口点的位置，以及它们接收的输入的类型，以防止攻击者试图绕过应用程序的前门而直接攻击内部的入口点。

对于每个入口点，您应当能够确定提供授权和验证级别的安全措施的类型。

逻辑应用程序入口点包括网页提供的用户界面、Web 服务提供的服务界面、服务组件和 .NET 远程组件以及提供异步入口点的消息队列。物理或平台入口点包括端口和 Sockets。

识别特权代码

特权代码用于访问特定类型的安全资源，并执行其他特权操作。安全资源类型包括 DNS 服务器、目录服务器、环境变量、事件日志、文件系统、消息队列、性能计数器、打印机、注册表、Sockets 和 Web 服务。安全操作包括无人管理的代码呼叫、映像、序列化、代码访问安全权限和代码访问安全策略的处理（包括证据）。

代码访问安全策略必须授予特权代码相应的代码访问安全权限。特权代码必须确保其包含的资源和操作不会暴露给不受信任的和潜在的恶意的代码。.NET 框架代码访问安全性通过执行堆栈通道来验证授予给呼叫代码的权限。但是，有时有必要覆盖此操作，不执行完全的堆栈过程。例如，当您想限制特权代码或隔离特权代码时。这样操作将开放您的代码以引诱攻击，在攻击中，恶意的代码将通过受信任的中间代码来呼叫您的代码。

无论何时您覆盖由代码访问安全提供的缺省的安全操作时，请谨慎，并采取相应的安全措施。有关查看安全漏洞代码的详细信息，请参阅模块 21 代码审查。有关代码访问安全性的详细信息，请参阅模块 8 代码访问安全的实践 和模块 9 ASP.NET 代码访问安全性。

说明安全配置文件

接下来，您应当识别用于输入有效性、验证、授权、配置管理的设计和实现方法，以及应用程序最容易受安全漏洞影响的其他领域。通过识别，您将为应用程序创建一个安全配置文件。

下表显示了对应用程序的设计和实现的每个方面进行分析时要询问的问题的种类。要查看程序体系结构和设计的详细信息，请参阅模块 5 体系结构和设计审查。

表 3.2创建安全配置文件

步骤 4：识别威胁

在此步骤中，您将识别可能影响系统并危及资产安全的威胁。开始此过程前，请将开发团队和测试团队的成员聚集在一起，在白板前召开一次研讨会以集思广益。这是一个识别潜在威胁的简单而有效的方法。如果团队由应用程序体系结构设计者、安全专家、开发者、测试者和系统管理员组成就更为理想了。

您可以使用两种基本的方法:

使用以下资源有助于理解威胁识别过程：

在该步骤中，需要执行以下任务：

识别网络威胁

这是网络设计者和网络管理员的任务。分析网络拓扑和数据包流，同时分析路由器、防火墙、交换机配置，并查找潜在的安全漏洞。另外请注意虚拟专用网络 (VPN) 末端。查看网络安全设置，以防止模块 2 威胁与对策中已识别的最常见网络层的威胁。

设计阶段最先考虑的网络威胁包括：

您必须同时确保由不安全设备和服务器配置而引起的威胁不会对网络进行攻击。例如，是否要关闭并禁用不必要的端口和协议？路由表和 DNS 服务器是否安全？服务器上的 TCP 网络堆栈是否不易攻击？有关预防此类型的安全漏洞的详细信息，请参阅模块 15 保护您的网络。

识别主机威胁

配置主机安全设置（也就是，Microsoft Windows 2000 和 .NET 框架配置）时，本指南通篇使用的方法是将配置分成几个类别，您可以按照结构化和逻辑方式应用安全设置。此方法还能够理想的用于检查安全性，准确确定安全漏洞的位置并识别威胁。所有服务器角色的一般配置类别包括补丁程序和更新信息、服务、协议、帐户、文件和目录、共享、端口以及审核与日志。对于每个类别识别潜在的易受攻击的配置设置。通过这些设置来识别威胁。

最先考虑的安全漏洞包括：

识别应用程序威胁

在前面的步骤中，您定义了应用程序的的体系结构、数据流、信任边界。您还创建了安全配置文件，用以描述应用程序如何管理核心区域（例如：验证、授权、配置管理）和其他区域。

现在请使用各类 STRIDE 威胁和预定义的威胁列表来仔细检查应用程序安全配置文件的每个方面。关注应用程序威胁、特定技术威胁以及代码威胁。要考虑的主要安全漏洞包括：

使用攻击树和攻击模式

使用攻击树和攻击模式是安全专家使用的主要工具。它们不是威胁识别阶段的基本组件，但您将发现它们很有用。它们使您可以更深层次地分析威胁，更好地帮助您识别其他可能威胁。

要点：如果使用以前准备好的已知的威胁分类列表，仅能发现常见的已知的威胁。使用其他方法（例如攻击树和攻击模式）可以帮助您识别其他潜在的威胁。

攻击树按照结构化和层次化的模式搜集并证明系统上存在的潜在攻击。树结构对攻击者用以危及系统安全的各种攻击进行描述性分类。通过创建攻击树，您将创建一个有助于集中精力的可重复使用的安全问题的描述。测试团队可以创建测试计划以确保安全设计的有效性。开发者可以在实现期间做出权衡，体系结构设计者或开发领导者可以对其他方法的安全成本进行评估。

攻击模式是在企业中捕获攻击信息的形式化的方法。这些模式可以帮助您识别常见的攻击技术。

创建攻击树

在实践中可以使用若干方法的同时，可接受的方法是识别攻击者要成功攻击需要采取的措施以及识别攻击者的目标和子目标。您可以使用层次化图表或简单布局来代表攻击树。最后，您是否拥有用以描述应用程序的攻击配置文件所需的工具也是很重要的。然后，您可以大致评估安全风险，可以通过使用相应的对策（例如，更正设计方法、加强配置设置及其他解决方法）来降低安全风险。

首先从创建代表攻击者目标的根节点构造攻击树开始。然后添加叶节点，叶节点是代表唯一攻击的攻击方法学。图 3.5 显示了一个简单的样例。

图 3.5
攻击树的表示法

您可以使用 AND 和 OR 标签对叶节点作标记。例如，在图 3.5 中，1.1 和 1.2 必须同时发生才可以导致攻击。

攻击树正如上述样例，并迅速复杂化。创建它们也是非常耗时的一项工作。一些团队热中的其他方法是使用布局（如下所示）来构建攻击树。

1.  目标一
1.1 子目标一
1.2 子目标二
2.  目标二
2.1 子目标一
2.2 子目标二

注意：除了目标和子目标外，攻击树还包括方法学和所需条件。

此处为实际中的一个布局方法样例：

#1 号威胁攻击者通过监测网络获得了验证证书
1.1 通过网络“与”传输清晰的文本证书
1.2 攻击者使用网络监测工具
1.2.1 攻击者识别证书数据

要获得完整的样例，请参阅本指南中“创建表单”一节中的“样例攻击树”。

攻击模式

攻击模式是通常发生在各种不同环境中的攻击的一般表示方法。模式定义了攻击发生必须的条件、执行攻击所需的步骤和攻击的结果，也定义了攻击的目标。攻击模式致力于攻击技术，但是基于 STRIDE 的各种方法致力于攻击者的目标。

例如，代码植入攻击模式就是攻击模式的一个样例，该模式用于以一般方式描述代码植入攻击。表 3.3 描述了代码植入攻击模式。

表 3.3 代码植入攻击模式

有关攻击模式的详细信息，请参阅本模块最后部分的“其他参考”。

步骤 5：证明威胁

要证明应用程序的威胁，请使用显示类似于以下属性的若干威胁属性的模板。威胁描述和威胁目标是最基本的属性。此阶段不进行危险评估。如果对已识别的威胁列表进行了优先级排序，此步骤将用于威胁建模过程的最后阶段。您可能想要包括的其他属性有：攻击技术（该技术也可以暴露被非法利用的安全漏洞）和解决威胁所需的对策。

表 3.4威胁 1

表 3.5 威胁 2

步骤 6：评估威胁

在此步骤中，您拥有将应用到特定应用程序脚本中的威胁列表。在最后的步骤中，您要基于威胁造成的风险进行威胁评估.这使您能够最先解决代表最大风险的威胁，然后解决其他威胁。实际上，从经济方面考虑，描述出所有已识别的威胁可能并不可行。您可能要忽略某些威胁，因为它们发生的几率很小并且如果发生所造成的损害微乎其微。

风险 = 可能性 * 潜在的损害

此公式表示特定威胁带来的风险等于威胁发生的可能性乘以潜在的损害，它代表了发生攻击时对系统造成损害的程度。

您可以将 1–10 这个比例用于威胁发生的可能性，其中 1 代表不太可能发生的威胁，10 代表几乎可以确定会发生的威胁。同样，可以将 1–10 这个比例用于潜在的损害，其中 1 表示最小的损害，10 代表灾难性的损害。使用这种方法，可以得出结论：发生的可能性低而潜在的损害高，这样的威胁带来的风险等于潜在的损害有限却极易发生的威胁带来的风险。

例如，如果可能性 = 10，潜在的损害 = 1，那么风险 = 10 * 1 = 10。如果可能性 = 1，潜在的损害 = 10，则风险 = 1 * 10 = 10。

这种方法带来的比例为 1–100，您可以将此比例分成三个区，这样就生成了高、中或低风险等级。

高、中和低等级

您可以使用简单的高、中或低等级对威胁进行优先级排列。如果威胁评估结果为高，则威胁将对应用程序造成显著的威胁，并且需要尽可能地解决。中级威胁需要解决，但是不紧急。根据解决威胁所需的努力和费用，您可能会决定忽略低级威胁。

DREAD

由于评估系统的简单化而引起的问题是团队成员通常无法对等级达成一致。为帮助解决此问题，增加了有助于确定安全威胁真正意味的影响的新的评估标准。在 Microsoft，DREAD 模型用于帮助计算风险。使用 DREAD 模型，您可以通过询问以下问题对给定的威胁活的风险等级：

您可以使用上述项目来评估每个威胁。为满足您的需要，您也可以对上述问题进行延伸。例如，您可以增加有关潜在名誉损害的问题：

名誉：风险有多高？是否存在名誉风险？名誉风险将导致失去客户信任。

无需大范围地逐个地进行威胁评估，因为这将很困难。你可以使用简单的模式，例如高 (1)、中 (2) 和低 (3)。

如果清楚的定义了评估系统中每个值所代表的含义，将有助于避免混淆。表 3.6 显示了一个等级表的典型样例，可用于团队成员对威胁进行优先级排列。

表 3.6威胁等级表

询问上述问题以后，请计算给定威胁的等级 (1–3)。结果的范围为 5–15。然后您可以将总体等级为 12–15 的威胁处理为高级风险，8–11 为中级风险，5–7 为低级风险。

例如，我们来考虑先前描述的两个威胁：

表 3.7 显示了两种威胁的 DREAD 等级的样例：

表 3.7DREAD 等级

一旦获得风险等级，您便可以更新已证明的威胁，并增加发现的评估等级级别，上述两种威胁的等级均为“高”。表 3.8 显示了一个样例。

表 3.8 威胁 1

接下来要做什么？

威胁建模过程的输出包括应用程序体系结构安全性方面的文档以及已评估的威胁列表。威胁模型有助于集中开发团队成员的力量，并集中解决最大的威胁。

要点：威胁建模是一个迭代进程。威胁模型是不断改进的文档，各个团队成员均可对其进行修改。

威胁模型可用于以下团队：

生成工作项目报告

根据初始威胁模型，您可以创建更正式的工作项目报告，该报告包括附加属性（例如故障 ID），该属性可用于将威胁附加在您喜欢的故障跟踪系统中。实际上，您可以选择在故障跟踪系统中输入已识别的威胁，并使用其报告工具生成报告。您还可以包括一个状态栏，用以指示故障是否已解决。您应当确保报告包括原始威胁编码以将其返回威胁模型文档。

按照网络、主机和应用程序类别在报告中组织威胁。这将使处于不同角色的不同团队成员更容易理解报告。在每个类别内，按照优先顺序显示威胁，从风险等级高的威胁开始，接下来是代表较少风险的威胁。

小结

虽然您可以减少攻击的风险，但您无法减少或排除真正的威胁。尽管您采取了安全措施并应用了相应的对策，威胁仍然存在。安全领域中的实际情况是：您承认威胁的存在，同时努力处理风险。威胁建模可以帮助您在团队中处理并交流安全风险问题。

将威胁建模作为一个迭代过程来对待。请将安全模型列为不断变化的动态项目，以适应不断发现的新威胁和攻击类型。威胁模型还应能够不断调整，以跟上应用程序的发展，因为需要不断增强和修改应用程序，才能满足不断变化的商业需求。