使用 STRIDE 方法发现安全系统设计缺陷Word文档下载推荐.docx

1、攻击模式 总结 无论您是构建新系统还是更新现有系统，都需要考虑入侵者攻击系统的可能方式，然后在系统的设计和实施阶段构建适当的防御手段。Microsoft 通过称作威胁建模的技术来进行安全系统设计，这种技术对系统设计和体系结构进行系统化的检查，以发现和更正设计级的安全性问题。威胁建模是安全性开发生命周期 （Security Development Lifecycle） 项目不可或缺的一部分。可以采用多种方法进行威胁建模，如果有人说他的方法是唯一正确的，毫无疑问他自己就大错特错了。至今还没有任何已确定有效的方法来衡量威胁模型的质量，甚至对于术语“威胁”的解释也各不相同。当然，这个领域确实还远谈不上

2、成熟；即使在较为成熟的密码领域，许多通用算法也未经证明是安全的。然而，尽管通常我们无法证明给定的设计是安全的，但我们可以从自己的错误中汲取教训并避免重复犯同样的错误。这就是威胁建模的本质。在本文中，我们将介绍一种系统化的威胁建模方法，这一方法是由 Microsoft 的安全性工程和通信 （Security Engineering and Communications） 小组开发的。与安全性开发生命周期的其它容类似，威胁建模也会继续发展，并将应用于新的环境中。当您建立自己的流程来开发安全代码时，这一方法或许能够很好地作为您的基准。设计安全软件设计好的软件本来就足够困难了，确保安全性更是难上加难！

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

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

5、用它吗？很幸运，我们对于安全性的含义确实有一定的了解。这意味着系统具有自己的属性，即性、完整性、可用性、对用户正确进行身份验证和授权、以及事务处理不可否认等。图 2 介绍了每个属性。您希望系统具有上述所有属性，但没有完整性或可用性 API。该怎么办呢？ Figure 2 Security Properties属性说明性数据只限应具有权限的人员访问。完整性数据和系统资源只限适当的人员以适当的方式进行更改。可用性系统在需要时一切就绪，可以正常执行操作。身份验证建立用户身份（或者接受匿名用户）。授权明确允许或拒绝用户访问资源。认可用户无法在执行某操作后否认执行了此操作。威胁建模和 STRIDE一种确

6、保应用程序具有这些属性的方法是使用 STRIDE 进行威胁建模，STRIDE 是 Spoofing（假冒）、Tampering（篡改）、Repudiation（否认）、Information Disclosure（信息泄漏）、Denial of Service（拒绝服务）和 Elevation of Privilege（提升权限）的字母缩略词。图 3 将威胁映射为防护它们的属性。 Figure 3 Threats and Security Properties威胁安全性属性假冒篡改否认信息泄漏拒绝服务提升权限为了遵循 STRIDE，您可以将系统分解成相关的组件，分析每个组件是否易受威胁攻击，并

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

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

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

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

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

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

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

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