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

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

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 （假冒）、Tampe

7、ring （篡改）、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通道等移动的数据。数据存储表示文件、数据库、注册表项以及类似项。进程指的是计 算机运行的计算或程序。Figure 4 DFD

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

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

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

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

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

15、序数据库I.VFJi 界现在，我们可以尝试根据问题描述来创建数据流关系图。最初的尝试可能如图6所示在服务器端有两 个进程、两个数据存储和三个数据流。在系统的服务器端与客户端之间存在一条信任边界，并且对于 每个客户端都有一个数据流跨过信任边界。对于每个客户端，都有一位销售人员、一个会计应用程序、 会计数据和发送进程。图6针对分析数据库初步的DFD但这是正确的DFD吗？这是能够生成最完整威胁图的DFD吗？从一些简单的常识来判断，这可能不 是正确的关系图。首先，这里有一个数据接收器。数据进入分析数据库，但从未读取。客户从未明确 提到有关读取数据的任何要求，因为这与当时的问题没有关联。设计人员可能会说出“问题的这一部 分超出范围”这样的话。但是，从安全性角度来看，这根本没有超出范围。因此，您需要以某种方式 向读者展示数据。以下介绍了一些常规规则，可用于判断您的DFD是否切合实际。首先，请注意神奇的数据源或数据接 收器：数据不是凭空臆造出来的。确保对于每个数据存储，都有用户作为读取者或写入者。其次，注 意数据传输过程