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

《使用 STRIDE 方法发现安全设计缺陷》由会员分享，可在线阅读，更多相关《使用 STRIDE 方法发现安全设计缺陷（18页珍藏版）》请在金锄头文库上搜索。

1、使用STRIDE方法发现安全设计缺陷使用STRIDE方法发现安全设计缺陷Shawn Hernan and Scott Lambert and Tomasz Ostwald and Adam Shostack本文讨论：,威胁建模的重要性本文使用了以下技术：，如何使用数据流关系图建立系 统STRIDE模型,如何抑制威胁目录设计安全软件威胁建模和STRIDE数据流关系图示例系统将STRIDE应用于Fabrikam分析程序数据库分析数据流和数据存储分析进程抑制威胁查找威胁的表现形式攻击模式总结无论您是构建新系统还是更新现有系统，都需要考虑入侵者攻击系统的可能方 式，然后在系统的设计和实施阶段构建适当的

2、防御手段.Microsoft通过称作威胁 建模的技术来进行安全系统设计，这种技术对系统设计和体系结构进行系统化的检查，以发现和更正设计级的安全性问题。威胁建模是安全性开发生命周期(Security Development Lifecycle)项目不可或缺的一部分。可以采用多种方法进行威胁建模，如果有人说他的方法是唯一正确的，毫无疑 问他自己就大错特错了。至今还没有任何已确定有效的方法来衡量威胁模型的质 量，甚至对于术语“威胁”的解释也各不相同。当然，这个领域确实还远谈不上成 熟；即使在较为成熟的密码领域，许多通用算法也未经证明是安全的。然而，尽管 通常我们无法证明给定的设计是安全的，但我们可以

3、从自己的错误中汲取教训并避 免重复犯同样的错误。这就是威胁建模的本质。在本文中，我们将介绍一种系统化的威胁建模方法，这一方法是由Microsoft 的安全性工程和通信(Security Engineering and Communications)小组开发 的。与安全性开发生命周期的其它内容类似，威胁建模也会继续发展，并将应用于新的环境中。当您建立自己的流程来开发 安全代码时，这一方法或许能够很好地作为您的基准。设计安全软件设计好的软件本来就足够困难了，确保安全性更是难上加难系统中内嵌的缺 陷在平常使用过程中可能会遇到，也可能不会遇到。实际上，平常使用时，某些缺 陷确实无关紧要。但在安全性环境

4、中，缺陷所产生的影响确实很大，因为攻击者可 能会通过设置触发缺陷所需的特定性高的条件，以引起故障。某些事情随机发生的 几率可能只有十亿分之一，此时您可能认为它不相关而置之不理。但如果该缺陷涉 及到安全性，您可以确信攻击者将利用它。设计安全软件的其中一个问题在于，不同的团体考虑安全性的方式不一样。软 件开发人员认为安全性好坏主要取决于代码质量，而网络管理员考虑的是防火墙、 事件响应和系统管理。学术界大多数人可能按经典的Saltzer和Schroeder设计 原则、安全性模型或其他抽象概念来看待安全性。当然，所有这些对于构建安全的 系统都是非常重要的。有关Saltzer和Schroeder的设计原

5、则的概述，请参阅图 1。但是，可能唯一一个最大的问题是缺乏安全性成功准则。如果我们要避免出现 安全性故障，这就意味着我们必须对于什么是安全性成功有一定的概念。Figure 1 Security Design Principles解释原则开放设计假设攻击者具有源代码和规格。故障安全预设值出故障时自动关 闭;无单点故障。最低权限只分配所需的权限。机制经济性保持简单、易懂的特性。分离权限不允许根据单一条件执行操作。总体调节每次检查所有内容。最低公用机制注意保护共享资源。心理可接受性他们将使用它吗，很幸运，我们对于安全性的含义确实有一定的了解。这意味着系统具有自己的 属性，即机密性、完整性、可用性、对

6、用户正确进行身份验证和授权、以及事务处 理不可否认等。图2介绍了每个属性。您希望系统具有上述所有属性，但没有完 整性或可用性API。该怎么办呢，Figure 2 Security Properties说明属性机密性 数据只限应具有权限的人员访问。完整性 数据和系统资源只限适当 的人员以适当的方式进行更改。可用性系统在需要时一切就绪，可以正常执行操 作。身份验证建立用户身份（或者接受匿名用户）。授权明确允许或拒绝用户访 问资源。认可用户无法在执行某操作后否认执行了此操作。威胁建模和STRIDE一种确保应用程序具有这些属性的方法是使用STRIDE进行威胁建模，STRIDE 是 Spoofing（假

7、冒）、Tampering（篡改）、Repudiation（否认）、Information Disclosure （信息泄漏）、Denial of Service（拒绝服务）和Elevation of Privilege（提升权限）的字母缩略词。图3将威 胁映射为防护它们的属性。Figure 3 Threats and Security Properties安全性属性威胁假冒身份验证篡改完整性否认认可信息泄漏机密性拒绝服务可用性提升权限授权为了遵循STRIDE，您可以将系统分解成相关的组件，分析每个组件是否易受 威胁攻击，并减轻威胁所带来的影响。接着，重复这一过程，直到您对于剩下的任 何威胁都感

8、到放心为止。如果完成了这一步一将系统分解成组件并抑制所有威胁 对于每个组件的影响一您就可以理直气壮地说系统是安全的。现在，问题的关键在于我们无法证实这种方法行之有效。这些组件自身可以免 受假冒威胁攻击，但当它们组合成一个系统时，组件之间的交互作用能否不受假冒 威胁攻击呢，这一点未经证实。实际上，威胁常常是在将多个系统联合起来以创建 更大的系统时才真正体现自己的破坏作用。在大多数这类情况下，真正将子系统组 合成较大的系统时，将涉及到违反子系统所依据的原始前提。例如，如果系统在设 计时从未考虑过要用在Internet上，当将系统用于Internet时，新的安全性问题将不断地涌现。在任何情况下，以下

9、观点都是正确的:如果系统的任何组件易受 假冒威胁攻击，您就不能说已对所有用户进行了适当的身份验证。数据流关系图数据流关系图（DFD）通常用于以图形方式表示系统，但只要您采用下述同一 种基本方法，您就可以使用其他表示方式（如UML图表）：将系统分解成部件，并证 明每个部件都不易受相关威胁攻击。DFD使用一组标准符号，其中包含四个元素: 数据流、数据存储、进程和交互方，对于威胁建模，我们另外增加了一个元素，即 信任边界。图4显示了这些符号。数据流表示通过网络连接、命名管道、邮件 槽、RPC通道等移动的数据。数据存储表示文件、数据库、注册表项以及类似项。 进程指的是计算机运行的计算或程序。Figur

10、e 4 DFD Symbols符号项数据流数据存储进程多进程交互方信任边界交互方指的是系统的端点:人、Web服务和服务器。通常，他们是数据提供方，或处于系统范围之外但与系统相关的用户。信任边界或许是所有元素中最主观的一个:它们表示可信元素与不可信元素之 间的边界。信任是一个很复杂的问题。您可能会信任您的机修工保养您的汽车，信 任您的牙医治疗您的牙齿，信任银行家保存您的钱，但您可能不会信任您的牙医更 换您的汽车火花塞。使DFD正确是确保威胁模型正确的关键所在。请花足够的时间设计您的DFD,确保图中显示系统的所有项。您是否注意到应用程序触及了所有文件和注册 表项，您是否正在从环境中读取数据，每个元

11、素（进程、数据存储、数据流和交互方） 都具有一组自己易受攻击的威胁，如图5所示。此图表以及DFD为您提供了一个 框架，供您调查系统可能失败的方式。将这项调查工作分配给主题专家，并建立检 验清单以确保不会再次犯同一错误，这可能是个不错的主意。例如，您可以让您的 网络团队调查信息泄漏威胁应用于您的网络数据流的方式。他们了解相关的技术， 很适合进行有关安全性的调研工作，因为这与应用程序中他们所负责的部分密切相 关。Figure 5 Threats Affecting Elements假冒篡改否认信息泄漏拒绝服务提升权限元素数据流数据存储进程交互方示例系统比如说，您需要一个系统来收集销售人员的会计文件

12、，在数据库服务器上计算 销售收据，并生成每周报表。我们将此系统称为Fabrikam分析程序数据库。目标 很简单:从一组系统中获取文件，并在一台中央服务器上对文件进行一定的分析。 这是客户所要求的业务目标，但您需要将此问题描述转换为规格和计划。此系统存在许多明显的潜在威胁，其中的很多威胁源自问题描述中的隐含安全 性要求。仅仅是搜集进程就会带来很多问题。收集信息意味着要将信息从一个位置 移到另一个位置。如何保证数据在传输过程中的安全性呢，您将处理会计文件，这些文件本质上属于敏感信息，通常应符合法律要求。而 且，您需要确定一组特定的用户一销售人员。您怎样了解他们，问题描述隐含着 许多安全性要求：,必

13、须对数据进行保护，以防止在传输和存储时不经意地泄漏。,需要对销售人员进行身份验证和授权。,应用程序必须从容地应对依赖于恶意输入的攻击，如SQL指令植入式攻击 和缓冲区溢出。,服务器需要能够至少每周执行一次计算。客户可能从来不会明确提出这些要求，因此，设计人员必须找到问题描述中内 在的安全性要求。当然，还有大量不太明显的安全性要求也需要得到满足。如果 销售人员可能为了隐瞒一笔可疑的销售而覆盖服务器上的文件时，该怎么办，如果 一位销售人员要将其他销售人员的销售业绩据为己有，该怎么办，而且，我们”到底指谁，如果Contoso Corporation能够将自己伪装成 Fabrikam服务器来欺骗Fab

14、rikam销售人员，该怎么办,请记住，攻击者无需遵守 您的协议或使用您的工具来访问您的服务器;他将花费超出您能想象的时间来查找 缺陷，而且，他可能拥有大量的计算机可用于执行复杂的计算。此时，如果组件是一个低风险系统，或者您对于类似系统具有大量的经验，您 可以决定已经满足了相关要求，开始计划抑制威胁。这就行了。但是，如果这是一 个高风险组件，该怎么办呢，您怎样了解您所不知道的问题呢，如果您在此时停止，威胁模型将受到限制，其中只考虑了您了解的风险，以及 您在设计此模型时碰巧记住的相关信息。您不仅必须从一个攻击者角度来看待风险 问题，还必须“同时”从所有攻击者的角度来全盘考虑安全问题。将STRIDE

15、应用于Fabrikam分析程序数据库现在，我们可以尝试根据问题描述来创建数据流关系图。最初的尝试可能如图6所示在服务器端有两个进程、两个数据存储和三个数据流。在系统的服务器端与 客户端之间存在一条信任边界，并且对于每个客户端都有一个数据流跨过信任边 界。对于每个客户端，都有一位销售人员、一个会计应用程序、会计数据和发送进 程。图6针对分析数据库初步的DFD但这是正确的DFD吗，这是能够生成最完整威胁图的DFD吗，从一些简单的常 识来判断，这可能不是正确的关系图。首先，这里有一个数据接收器。数据进入分 析数据库，但从未读取。客户从未明确提到有关读取数据的任何要求，因为这与当 时的问题没有关联。设

16、计人员可能会说出“问题的这一部分超出范围”这样的话。 但是，从安全性角度来看，这根本没有超出范围。因此，您需要以某种方式向读者 展示数据。以下介绍了一些常规规则，可用于判断您的DFD是否切合实际。首先，请注 意神奇的数据源或数据接收器:数据不是凭空臆造出来的。确保对于每个数据存 储，都有用户作为读取者或写入者。其次，注意数据传输过程所起的灵魂作用。换 句话说，应确保始终有一个进程读取和写入数据。数据不是从用户的大脑直接进入 磁盘，也不是从磁盘直接进入用户的大脑。第三，将单个信任边界内的相似元素收 缩为单个元素，以便于建模。如果这些元素是采用相同的技术实施的，并且包含在 同一条信任边界内，则可以对它们进行收缩。第四，注意信