使用 STRIDE 方法发现安全系统设计缺陷.docx

使用 STRIDE 方法发现安全系统设计缺陷.docx

《使用 STRIDE 方法发现安全系统设计缺陷.docx》由会员分享，可在线阅读，更多相关《使用 STRIDE 方法发现安全系统设计缺陷.docx（23页珍藏版）》请在冰豆网上搜索。

使用STRIDE方法发现安全系统设计缺陷

使用STRIDE方法发现安全设计缺陷

使用STRIDE方法发现安全设计缺陷

ShawnHernanandScottLambertandTomaszOstwaldandAdamShostack

本文讨论:

∙威胁建模的重要性

∙如何使用数据流关系图建立系统模型

∙如何抑制威胁

本文使用了以下技术:

STRIDE

设计安全软件

威胁建模和STRIDE

数据流关系图

示例系统

将STRIDE应用于Fabrikam分析程序数据库

分析数据流和数据存储

分析进程

抑制威胁

查找威胁的表现形式

攻击模式

总结

无论您是构建新系统还是更新现有系统，都需要考虑入侵者攻击系统的可能方式，然后在系统的设计和实施阶段构建适当的防御手段。

Microsoft通过称作威胁建模的技术来进行安全系统设计，这种技术对系统设计和体系结构进行系统化的检查，以发现和更正设计级的安全性问题。

威胁建模是安全性开发生命周期（SecurityDevelopmentLifecycle）项目不可或缺的一部分。

可以采用多种方法进行威胁建模，如果有人说他的方法是唯一正确的，毫无疑问他自己就大错特错了。

至今还没有任何已确定有效的方法来衡量威胁模型的质量，甚至对于术语“威胁”的解释也各不相同。

当然，这个领域确实还远谈不上成熟；即使在较为成熟的密码领域，许多通用算法也未经证明是安全的。

然而，尽管通常我们无法证明给定的设计是安全的，但我们可以从自己的错误中汲取教训并避免重复犯同样的错误。

这就是威胁建模的本质。

在本文中，我们将介绍一种系统化的威胁建模方法，这一方法是由Microsoft的安全性工程和通信（SecurityEngineeringandCommunications）小组开发的。

与安全性开发生命周期的其它容类似，威胁建模也会继续发展，并将应用于新的环境中。

当您建立自己的流程来开发安全代码时，这一方法或许能够很好地作为您的基准。

设计安全软件

设计好的软件本来就足够困难了，确保安全性更是难上加难！

系统中嵌的缺陷在平常使用过程中可能会遇到，也可能不会遇到。

实际上，平常使用时，某些缺陷确实无关紧要。

但在安全性环境中，缺陷所产生的影响确实很大，因为攻击者可能会通过设置触发缺陷所需的特定性高的条件，以引起故障。

某些事情随机发生的几率可能只有十亿分之一，此时您可能认为它不相关而置之不理。

但如果该缺陷涉及到安全性，您可以确信攻击者将利用它。

设计安全软件的其中一个问题在于，不同的团体考虑安全性的方式不一样。

软件开发人员认为安全性好坏主要取决于代码质量，而网络管理员考虑的是防火墙、事件响应和系统管理。

学术界大多数人可能按经典的Saltzer和Schroeder设计原则、安全性模型或其他抽象概念来看待安全性。

当然，所有这些对于构建安全的系统都是非常重要的。

有关Saltzer和Schroeder的设计原则的概述，请参阅图1。

但是，可能唯一一个最大的问题是缺乏安全性成功准则。

如果我们要避免出现安全性故障，这就意味着我们必须对于什么是安全性成功有一定的概念。

Figure1SecurityDesignPrinciples

原则

解释

开放设计

假设攻击者具有源代码和规格。

故障安全预设值

出故障时自动关闭；无单点故障。

最低权限

只分配所需的权限。

机制经济性

保持简单、易懂的特性。

分离权限

不允许根据单一条件执行操作。

总体调节

每次检查所有容。

最低公用机制

注意保护共享资源。

心理可接受性

他们将使用它吗？

很幸运，我们对于安全性的含义确实有一定的了解。

这意味着系统具有自己的属性，即性、完整性、可用性、对用户正确进行身份验证和授权、以及事务处理不可否认等。

图2介绍了每个属性。

您希望系统具有上述所有属性，但没有完整性或可用性API。

该怎么办呢？

Figure2SecurityProperties

属性

说明

性

数据只限应具有权限的人员访问。

完整性

数据和系统资源只限适当的人员以适当的方式进行更改。

可用性

系统在需要时一切就绪，可以正常执行操作。

身份验证

建立用户身份（或者接受匿名用户）。

授权

明确允许或拒绝用户访问资源。

认可

用户无法在执行某操作后否认执行了此操作。

威胁建模和STRIDE

一种确保应用程序具有这些属性的方法是使用STRIDE进行威胁建模，STRIDE是Spoofing（假冒）、Tampering（篡改）、Repudiation（否认）、InformationDisclosure（信息泄漏）、DenialofService（拒绝服务）和ElevationofPrivilege（提升权限）的字母缩略词。

图3将威胁映射为防护它们的属性。

Figure3ThreatsandSecurityProperties

威胁

安全性属性

假冒

身份验证

篡改

完整性

否认

认可

信息泄漏

性

拒绝服务

可用性

提升权限

授权

为了遵循STRIDE，您可以将系统分解成相关的组件，分析每个组件是否易受威胁攻击，并减轻威胁所带来的影响。

接着，重复这一过程，直到您对于剩下的任何威胁都感到放心为止。

如果完成了这一步—将系统分解成组件并抑制所有威胁对于每个组件的影响—您就可以理直气壮地说系统是安全的。

现在，问题的关键在于我们无法证实这种方法行之有效。

这些组件自身可以免受假冒威胁攻击，但当它们组合成一个系统时，组件之间的交互作用能否不受假冒威胁攻击呢？

这一点未经证实。

实际上，威胁常常是在将多个系统联合起来以创建更大的系统时才真正体现自己的破坏作用。

在大多数这类情况下，真正将子系统组合成较大的系统时，将涉及到违反子系统所依据的原始前提。

例如，如果系统在设计时从未考虑过要用在Internet上，当将系统用于Internet时，新的安全性问题将不断地涌现。

在任何情况下，以下观点都是正确的：

如果系统的任何组件易受假冒威胁攻击，您就不能说已对所有用户进行了适当的身份验证。

数据流关系图

数据流关系图（DFD）通常用于以图形方式表示系统，但只要您采用下述同一种基本方法，您就可以使用其他表示方式（如UML图表）：

将系统分解成部件，并证明每个部件都不易受相关威胁攻击。

DFD使用一组标准符号，其中包含四个元素：

数据流、数据存储、进程和交互方，对于威胁建模，我们另外增加了一个元素，即信任边界。

图4显示了这些符号。

数据流表示通过网络连接、命名管道、槽、RPC通道等移动的数据。

数据存储表示文件、数据库、注册表项以及类似项。

进程指的是计算机运行的计算或程序。

Figure4DFDSymbols

项

符号

数据流

数据存储

进程

多进程

交互方

信任边界

交互方指的是系统的端点：

人、Web服务和服务器。

通常，他们是数据提供方，或处于系统围之外但与系统相关的用户。

信任边界或许是所有元素中最主观的一个：

它们表示可信元素与不可信元素之间的边界。

信任是一个很复杂的问题。

您可能会信任您的机修工保养您的汽车，信任您的牙医治疗您的牙齿，信任银行家保存您的钱，但您可能不会信任您的牙医更换您的汽车火花塞。

使DFD正确是确保威胁模型正确的关键所在。

请花足够的时间设计您的DFD，确保图中显示系统的所有项。

您是否注意到应用程序触及了所有文件和注册表项？

您是否正在从环境中读取数据？

每个元素（进程、数据存储、数据流和交互方）都具有一组自己易受攻击的威胁，如图5所示。

此图表以及DFD为您提供了一个框架，供您调查系统可能失败的方式。

将这项调查工作分配给主题专家，并建立检验清单以确保不会再次犯同一错误，这可能是个不错的主意。

例如，您可以让您的网络团队调查信息泄漏威胁应用于您的网络数据流的方式。

他们了解相关的技术，很适合进行有关安全性的调研工作，因为这与应用程序中他们所负责的部分密切相关。

Figure5ThreatsAffectingElements

元素

假冒

篡改

否认

信息泄漏

拒绝服务

提升权限

数据流

数据存储

进程

交互方

示例系统

比如说，您需要一个系统来收集销售人员的会计文件，在数据库服务器上计算销售收据，并生成每周报表。

我们将此系统称为Fabrikam分析程序数据库。

目标很简单：

从一组系统中获取文件，并在一台中央服务器上对文件进行一定的分析。

这是客户所要求的业务目标，但您需要将此问题描述转换为规格和计划。

此系统存在许多明显的潜在威胁，其中的很多威胁源自问题描述中的隐含安全性要求。

仅仅是搜集进程就会带来很多问题。

收集信息意味着要将信息从一个位置移到另一个位置。

如何保证数据在传输过程中的安全性呢？

您将处理会计文件，这些文件本质上属于敏感信息，通常应符合法律要求。

而且，您需要确定一组特定的用户—销售人员。

您怎样了解他们？

问题描述隐含着许多安全性要求：

∙必须对数据进行保护，以防止在传输和存储时不经意地泄漏。

∙需要对销售人员进行身份验证和授权。

∙应用程序必须从容地应对依赖于恶意输入的攻击，如SQL指令植入式攻击和缓冲区溢出。

∙服务器需要能够至少每周执行一次计算。

客户可能从来不会明确提出这些要求，因此，设计人员必须找到问题描述中在的安全性要求。

当然，还有大量不太明显的安全性要求也需要得到满足。

如果销售人员可能为了隐瞒一笔可疑的销售而覆盖服务器上的文件时，该怎么办？

如果一位销售人员要将其他销售人员的销售业绩据为己有，该怎么办？

而且，“我们”到底指谁？

如果ContosoCorporation能够将自己伪装成Fabrikam服务器来欺骗Fabrikam销售人员，该怎么办？

请记住，攻击者无需遵守您的协议或使用您的工具来访问您的服务器；他将花费超出您能想象的时间来查找缺陷，而且，他可能拥有大量的计算机可用于执行复杂的计算。

此时，如果组件是一个低风险系统，或者您对于类似系统具有大量的经验，您可以决定已经满足了相关要求，开始计划抑制威胁。

这就行了。

但是，如果这是一个高风险组件，该怎么办呢？

您怎样了解您所不知道的问题呢？

如果您在此时停止，威胁模型将受到限制，其中只考虑了您了解的风险，以及您在设计此模型时碰巧记住的相关信息。

您不仅必须从一个攻击者角度来看待风险问题，还必须“同时”从所有攻击者的角度来全盘考虑安全问题。

将STRIDE应用于Fabrikam分析程序数据库

现在，我们可以尝试根据问题描述来创建数据流关系图。

最初的尝试可能如图6所示在服务器端有两个进程、两个数据存储和三个数据流。

在系统的服务器端与客户端之间存在一条信任边界，并且对于每个客户端都有一个数据流跨过信任边界。

对于每个客户端，都有一位销售人员、一个会计应用程序、会计数据和发送进程。

图6针对分析数据库初步的DFD

但这是正确的DFD吗？

这是能够生成最完整威胁图的DFD吗？

从一些简单的常识来判断，这可能不是正确的关系图。

首先，这里有一个数据接收器。

数据进入分析数据库，但从未读取。

客户从未明确提到有关读取数据的任何要求，因为这与当时的问题没有关联。

设计人员可能会说出“问题的这一部分超出围”这样的话。

但是，从安全性角度来看，这根本没有超出围。

因此，您需要以某种方式向读者展示数据。

以下介绍了一些常规规则，可用于判断您的DFD是否切