使用-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是否切合实际。首先，请注意神奇的数据源或数据接收器：数据不是凭空臆造出来的。确保对于每个数据存储，都有用户作为读取者或写入者。其次，注意数据传输过程所起的灵魂作用。换句话说，应确保始终有一个进程读取和写入数据。数据不是从用户的大脑直接进入磁盘，也不是从磁盘直接进入用户的大脑。第三，将单个信任边界内的相似元素收缩为单个元素，以便于建模。如果这些元素是采用相同的技术实施的，并且包含在同一条信任边界内，则可以对它们进行收缩。第四，注意信任边界任一侧的建模细节。目标是在信任边界的两侧同时建立每个元素的模型。比较好的做法是绘制具有上下文环境的DFD和详细分解图，这样就可以显示更详细的信息。这里所讨论的系统同时在单个模型中表示客户端系统和服务器系统。请记住，攻击者没有义务使用您的工具或遵守您的协议。修订数据流关系图将这些规则考虑进去后，图7中的DFD可能就是一个更好的表示形式。此处的变化很显著。我们已经将收集进程和分析进程合二为一。这并不必然意味着这两个进程需要一起实施—其意义在于不要“捡了芝麻，丢了西瓜”。考虑一下尚未实施的“主要功能”。图7较好的DFD我们还将客户端表示为只不过是一些外部交互方，这是一项极其有效的变动。这反映出攻击者随心所欲进行攻击的事实。因