使用 STRIDE 方法发现安全系统设计缺陷.docx
《使用 STRIDE 方法发现安全系统设计缺陷.docx》由会员分享，可在线阅读，更多相关《使用 STRIDE 方法发现安全系统设计缺陷.docx（24页珍藏版）》请在冰豆网上搜索。
使用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
我们还将客户端表示为只不过是一些外部交互方，这是一项极其有效的变动。
这反映出攻击者随心所欲进行攻击的事实。
因此，我们只将此威胁模型限于服务器端—一个完善的威胁模型应包含对于客户端系统的类似表示，这样，就能将服务器表示为只不过是一系列外部交互方。
这就是信任边界的真正定义—不相信另一端的任何事物。
现在，我们可以在列表和表中表示所有内容，并开始将大问题分解成一系列较小的问题。
分析数据流和数据存储
首先来看数据流。
共有三个数据流，如图6中所示。
每一个数据流都会受到图3中所列威胁的攻击。
我们来看看每个进程如何易受攻击。
数据流1：
销售到收集销售数据传送到收集进程，在这一期间内可能发生篡改攻击。
换句话说，数据在通过Internet传输时可能会被修改，尤其是数据来自采用各种安全性设置的笔记本电脑时。
另一种风险是信息泄漏。
数据在传输过程中可能被不应具有访问权限的人读取。
收集进程还可能成为拒绝服务攻击的牺牲品；攻击者可能会阻止销售人员访问收集服务器。
（如果攻击者在一个季度的最后一天进行这种攻击，则可能会给公司带来严重影响。
）
数据流2：
销售系统列表到收集对于销售系统列表收集进程，存在类似的威胁。
某人通过将新的系统插入销售人员的列表中（而这一系统可能允许输入错误的数据），从而能够篡改数据。
删除系统可能会使销售人员无法登记销售数据。
（这种情况在模型中也属于拒绝服务攻击。
我们称之为篡改。
无需过多沉迷于这一技术。
）
当您考虑对于此数据流的威胁时，可能尚未确定用于验证销售人员身份的身份验证系统。
如果身份验证系统不完备，则销售人员可能会遭受假冒威胁。
确保威胁得到记录和解决。
当您考察针对销售人员的假冒威胁时，您也可能面临同一威胁。
一定程度的冗余至关重要。
Fabrikam的竞争对手可能会对销售人员名单感兴趣。
当发生解雇时，内部人员也可能会对该列表感兴趣，因此，信息面临的威胁也很严重，需要予以解决。
千万不要沾沾自喜，因为您根本想象不到其他人为何需要您的数据。
您只需认为有人需要您的数据。
根据Fabrikam的规模以及销售人员更改数据的频率，拒绝服务可能不是非常严重的攻击。
在检查威胁时进行某种程度的风险分析是很好（甚至是明智）的做法。
但请记住，您与客户相距越远，就越难以知道客户对于不同风险的承受程度。
不要对客户的情形或风险承受程度做过多的假设。
数据流3：
分析进程到分析存储此处我们遇到的是令人感兴趣的发生篡改攻击的情形。
此处的数据流完全包含在一条信任边界内。
在这种情形中，铁杆安全性理论家可能认为绝对无需担心完全包含在一条信任边界内的进程—毕竟，您信任这些进程。
然而，另一方面，铁杆安全性实干家可能会针锋相对，认为任何事情都可能失败，此处没有什么不同。
我们对于这两种观点都表示认同，但最重要的是解决此问题。
与数据流3相比，数据流1遭到攻击的程度明显要高，因此应该花更多的努力检查数据流1，以反映其更易受攻击的本质。
但数据流3也不是完全没有风险。
例如，如果分析数据库存储在另一台计算机上，该怎么办？
所编写的威胁模型似乎暗示着收集进程与数据库位于同一台计算机上，但实际上可能并非如此。
可能建模人员所做的假设不正确，或者尚未决定。
如果事实证明分析数据库存储在远程计算机上，则数据流4与数据流1很可能具有相似的威胁情况。
最后，即使您依赖于信任边界，也不要忘记情形已发生了变化。
深层防御可能是一项很值得的投资。
此处面临的威胁也是信息泄漏和拒绝服务。
实际上，这种情形与篡改威胁相同。
换句话说，信任边界是否可靠并已正确地进行设置？
如果没有，则需要考虑这些威胁。
现在，我们来看数据存储。
数据存储1：
分析数据库此数据存储易受篡改威胁攻击，特别是由于尚未完全指定数据库中的内容。
这是包含订单履行和销售人员奖金的数据库吗？
它是生成销售预测的预测数据库吗？
不同的数据类型吸引不同的攻击者。
请注意，攻击者可能是内部人员，而不是外部人员。
他们可能具有合法的访问权限，可以访问数据库以完成自己的工作。
信息泄漏问题正在变得越来越严重。
如果Fabrikam以信用方式从用户处获得销售订单，数据库中可能存在社会保障号码或信用卡号。
数据库中可能还具有竞争对手想查看的专有信息。
如果Fabrikam销售保健产品或医药产品，则可能受HIPAA隐私条款限制。
拒绝服务也是一种威胁。
谁使用该数据库，目的是什么？
填满数据库就是一个简单的攻击。
当数据库已满时，通常的反应是停止处理新的请求，或覆盖原有数据。
当拒绝服务攻击导致无法实现业务目标时，所带来的破坏作用就极其严重了。
数据存储2：
销售系统列表此处的一种威胁是篡改。
攻击者可能会添加可造成危害的销售人员，或者删除销售人员并阻止销售人员完成自己的工作。
此处面临的实际威胁也是信息泄漏和拒绝服务。
数据存储3：
笔记本电脑对笔记本电脑进行篡改攻击可能使攻击者能够窃取数据或访问控制信息，如密码、密钥或证书。
攻击者可能会安装间谍软件，以使自己能够持续访问系统。
这可能会使威胁模型与其他项目产生交叉影响，但如果您设计的是一个无法合理管理的系统，则可能会让您的客户或用户面临更大的安全风险。
如果攻击者控制了笔记本电脑，则电脑上的所有信息都将成为攻击者的囊中之物。
而且，此处的威胁可能并不仅仅涉及到威胁模型的这一部分。
分析进程
伪装成收集进程的进程（假冒）可能会收集销售部门试图提交的所有数据。
这会导致信息泄漏和拒绝服务。
许多威胁一旦被利用，就可能会带来其他威胁。
例如，如果您伪装成管理员（假冒），则可以关闭系统（一种拒绝服务威胁）。
同时，如果攻击者在此篡改数据并损坏数据，或者读取内存，可能导致拒绝服务或提升权限威胁。
然而，请不要太执迷于跟踪后续的所有结果。
否认是收集进程易受攻击的一种威胁，其实质是说谎。
否认威胁指的是您可能执行了某个操作，却冠冕堂皇地否认您已经执行该操作。
举例来说，在我们探讨的情况下，否认威胁可能涉及到提交修订的销售数据来覆盖现有数据，但声称自己并没有这样做。
针对进程的信息泄漏威胁可能采用欺骗手段—在正常情况下，您认为这些威胁只影响数据流和数据存储。
但是进程在内容中保留了大量的重要数据。
如果攻击者能够从进程的内存中读取数据，他可能就无需侵入数据库。
类似地，如果攻击者发现有关程序内部结构的信息，这些信息将有助于他进行其他类型的攻击。
例如，如果信息泄漏攻击使得入侵者能够发现某些变量的内存地址，这种攻击对于入侵者进行进一步攻击是一个非常重要的跳板。
此处也很可能发生拒绝服务攻击和提升权限攻击。
内部人员和竞争对手可能为利益驱使而试图阻止进行正常的数据收集，这一点可以通过多种方法实现。
例如，攻击者可以使收集进程运行他们编写的代码，从而进行假冒、篡改或拒绝服务攻击。
收集进程可能直接面对Internet，因此，编写适当的安全代码显得非常重要。
您可以继续针对每个威胁和DFD中的每个元素进行这类分析，直到您敢确定您已经针对所有数据流和数据存储解决了篡改、信息泄漏和拒绝服务威胁；针对所有进程解决了每种STRIDE威胁（共6种）；针对所有交互方解决了假冒和否认威胁；并解决了影响信任边界的独特威胁。
上述这些措施不能保证您的系统是安全的，但无疑可以让您晚上睡得更香。
抑制威胁
理想的情形是使用功能强大的、易于理解的解决方案来抑制威胁。
例如，适当地利用功能强大的密码技术被公认为是一种强有力的、可对抗多种类型的信息泄漏威胁的手段。
您可能永远无法证明某种防御措施是完美的。
然而，STRIDE模型很好的一点在于，它能够让您洞察您所需的抑制措施的本质。
只需根据现有的技术重塑图3，您就能了解您需要什么样的抑制措施。
然而，选择技术可能也颇富挑战性。
一般来说，我发现提出以下两个简单问题可能会有所帮助：
此技术能否用于抑制威胁？
是否能够真正用于您所关注的场合中？
查找威胁的表现形式
既然您已经将大问题分解成若干小问题了，怎么解决这些小问题呢？
我们已经做了一些调查研究。
您应找到有关您所使用的技术先前的故障模式。
例如，如果数据流将通过TCP使用远程过程调用（RPC），则不仅需要找出数据流中的一般故障类别，还要找出特定于TCP和RPC的已知故障。
一种了解威胁如何表现自己的极好方法是参阅安全性开发生命周期中的第22章，本书作者为MichaelHoward和SteveLipner（MicrosoftPress®，2006），其中针对四种标准DFD元素的每一种，对于STRIDE威胁开发了威胁树。
例如，一种威胁树探讨了篡改威胁在一般情况下如何在数据流中展现自己。
树的展示方式为：
树中的叶节点建议将实现威胁的攻击。
其宗旨是将威胁树的叶节点作为最主要的问题—与先前您集思广益的方式类似。
例如，我们假设篡改威胁攻击“销售到收集”数据流。
查看安全性开发生命周期中的问题列表，第一个与篡改数据流相关的问题如下所示：
是否采用了诸如时间戳记或计数器等此类反重播防御手段来保护数据流（哈希、MAC'd或签名）？
这意味着一个简单的攻击—即重播有效消息—而在我们的整个探讨中却被完全忽视了！
此攻击不是新出现的，也不是先前未知的攻击。
只是在问题描述中并未明确指出，这种攻击很简单，甚至连经验丰富的安全专家也会忽视。
此攻击在这种情形下的影响为：
如果销售人员两次提交一组销售数据，该怎么办？
想像一下Vishal和Eric竞争夏威夷旅游销售奖励。
Eric可能想两次提交一组数据，以使其销售业绩看起来相当不错，从而赢得旅游奖励。
您可能会认为会计系统应能发现此问题，毕竟这是会计系统功能的一部分。
但您怎么知道呢？
这毕竟只是一个报告系统，可能从该系统中生成的数据并不经过仔细检查，就成为正式的会计数据。
可能攻击在一定程度上受到抑制，也可能没有受到抑制。
但了解是否会发生攻击并发现以前未考虑过的攻击，这是威胁建模主要目标的一部分。
对于这一新发现的威胁，您现在面临一项新任务：
了解此威胁是否已被抑制。
最后，这类调查的可能结果是文件将用相关的信息（实际上就是一个随机数字）来唯一地标识。
现在，您需要制定业务决策：
是与风险共处，还是需要一个功能更强大的解决方案？
在Microsoft，使用预构建的威胁树在许多情形下证明是行之有效的，可以确保不会忽略已知的攻击。
随着不断地发现新攻击，威胁树中不断地加入这些新的威胁，自身也在不断地壮大。
这样，威胁树可能会形成一种系统化的知识。
但请记住，它们本质上是非常普遍的。
整个攻击类别适用于一种技术，但不适用于另一种技术。
例如，在数据流的情况下，TCP的安全性属性不同于用户数据协议（UDP）的安全性属性，初始序列号和窗口大小
升级会员 