安全简报

SDL 威胁建模工具入门

Adam Shostack

目录

启动威胁建模过程
分析威胁
环境屏幕
跟踪报表
操作菜单
威胁建模会议
考虑资产

图 1 威胁建模过程

2008 年 11 月，Microsoft 宣布安全性开发生命周期 (SDL) 威胁建模工具的通用版本将在 MSDN 上提供免费下载。本专栏将跟随一个团队来体验 SDL 威胁建模方法的整个过程，并向您展示如何使用这一新工具来开发强大的威胁模型作为安全流程的主干。

本专栏并不是 SDL 威胁建模的初级读本。要了解基本内容，请参阅我在 2006 年 11 月刊的《MSDN 杂志》中与他人合著的关于使用 STRIDE 方法的文章“威胁建模：使用 STRIDE 方法发现安全设计缺陷”。图 1 简要概述了这一过程。

启动威胁建模过程

当您启动 SDL 威胁建模工具时，将会看到左下角与 Microsoft Office Outlook 非常相似，均包括四个屏幕：图表、分析、环境和报表（有关详细信息，请参见图 2）。请注意，这些屏幕与图 1 中所示的略图稍有不同，因为在威胁和缓解措施紧密相关的情况下将它们放在一起考虑是很有必要的。

在本章中，我将跟随 Deb（开发人员）、Paul（项目经理）和 Tim（测试人员）体验开发第一个威胁模型的过程，同时还将对此工具的各个屏幕逐一加以介绍。

“你好 Deb，我一直在研究这个威胁建模图表，想和你一起体验一下，以便确保我们得到了准确的细节。”

“没问题，Paul！来吧。”

Paul 拿出利用威胁建模工具的“Diagrams only”（仅图表）报表功能制成的打印输出图，如图 3 所示。

“Paul，我以前从来没有见过这些图表。它看起来非常简单，你能简单介绍一下不同形状所代表的含义吗？”

“具体含义是这样的，Carl（我们的普通客户角色）被绘制为一个外部实体（矩形）。他向我们的 Web 服务器发出命令（圆圈可以是任何运行代码，箭头指示通信方向）。Web 服务器将会咨询数据库（数据库与我们存储数据的任何位置一样，用两条平行线表示）。此系统称为数据流关系图 (DFD)。Wikipedia 曾就 DFD 撰写了一篇很翔实的文章。其中唯一没有涉及的内容是由不同人员控制的不同位置之间用虚线表示的信任边界。例如，您知道 IT 专业人员要求我们使用他们的 Active Directory 系统来注册登录信息，因此 Active Directory 显示在我们的控制范围之外。”

图 3 Paul 的 DFD 图

该工具启动后，将显示此图表屏幕。这是 Paul 使用 Visio 工具和提供的模板来绘制其 DFD 的位置（请参见图 4）。尽管这是 Paul 第一次使用，但他也感到得心应手，因为作为 SDL 的一部分，左侧的验证程序根据他使用威胁建模的体验为其提供了反馈。当他发现自己的绘图有些复杂时，他通过右键单击右上角的上下文文件夹添加了一些附加的详细信息，以便能够创建复杂的分层图。

图 4 图表屏幕

分析威胁

当 Paul 打开分析屏幕（请参见图 5）时，他有点犹豫了。屏幕中出现了一个很长的威胁列表，这些威胁都是从哪里来的呢？这些都是此工具使用被称为“依据元素的 STRIDE”的 SDL 方法构建的。其理念是软件通常会遇到可预测的一组威胁（如图 5 中所示的威胁）。一些安全专家希望先追击黑客，因为这种追击本身会很有趣。我认为要保护您的家庭财产，首先应确保各扇门窗都安装了某种类型的锁，然后再考虑报警系统。同理，首先应单击分析屏幕中的任意行，从“依据元素的 STRIDE”开始着手。

图 5 分析屏幕

Paul 首先在元素列表中选择了 database。他在屏幕顶部发现 "database" 是一个数据存储库，因此可能会遭到篡改、信息泄漏和拒绝服务攻击等威胁。他继续往下阅读，随后的问题可帮助他思考他人可能会采用什么样的手段来篡改数据，他意识到没有人指定哪些人能够连接到该数据库。白板图表和一些简单的规则揭示了第一个威胁！威胁建模得一分。

经过几分钟的讨论之后，他们意识到需要考虑访问控制和角色。Paul 在两个威胁中填充了几点注意事项。第一个注意事项是“无访问控制计划”。他还将工作项归档到其 Team Foundation Server (TFS) 数据库中。第二个注意事项是“访问控制计划需要角色列表”。Paul 然后开始研究 TFS，但又产生了依赖于第一个错误的另一个错误。

Paul 在研究信息泄漏时，意识到他们的访问控制计划需要一些只读帐户来进行审核和报表生成。他拿不准这算不算是一个新威胁，后来他认为不是，因为缓解措施完全相同，随后他在 TFS 中对该错误进行了编辑。接下来他决定证明此威胁在其他位置已有所缓解，并写下 "covered in TFS bug #235"。他并不十分确定这是否合适，但这的确是证书功能的目的（请参见图 6）。

图 6 证明威胁并未施加

他还对信息泄漏做了一些考虑，意识到备份磁带需要加密，但那属于实施作业（我稍后将介绍他如何对此进行跟踪，在那之前先介绍一个相关功能：位于顶部的“auto-generate threats for this element”（自动为此元素生成威胁）复选框）。

自动生成功能适用于一些大型团队，他们拥有许多威胁模型，同时还有办法确保测试人员和项目经理都关注威胁模型中的内容。因此，在这种情况下，Paul 可能会说是 Phil 负责他想要针对上下文显示的多个元素以及它们与此功能交互的方式。默认情况下，自动生成框会被选中，但 Paul 可以取消选中它并声明自己认为这是 Phil 的功能。

环境屏幕

由于担心加密备份磁带操作，Paul 打开了环境屏幕，看到了有关外部安全注意事项的部分（请参见图 7）。他在那里强调指出操作必须处理磁带备份。他必须确保操作具有该工具的副本。

图 7 外部安全注意事项

处在此屏幕中时，他想知道文档标头部分的内容，后来发现那里有很多指导文本，说明这里正是用来确定谁拥有该威胁模型的地方，另外还可以了解到威胁模型的用途等。他填充了相应的内容，并希望可以包括 Contoso 项目跟踪号码。

通过系统地遍历树中的各个元素，Paul 注意到对 SQL Server 和 Fabrikam Foxy Web Widgets 2.3 小组件库存在依赖性。Paul 添加了一个备注，让 Tim 对此进行调查，以确保它们都是最新的，并且会从 Fabrikam 获得安全通知。

跟踪报表

有五个威胁建模报表可供使用：

分析报表 此报表为安全顾问或咨询人员而设计，供其查看威胁模型，但实际上任何人都可以使用它来查看哪些图表验证问题已建立、哪些空白威胁尚未填充、哪些威胁没有任何缓解措施、哪些威胁已经证明或者已被标记为不生成威胁。

威胁模型报表 此报表包含输入到威胁模型中的信息，它们都显示在单个页面视图中。

仅图表 此报表设计用于简化图表的打印。有些人喜欢将工作所需的内容打印到纸上，这可以使其在只需要图表时不必打印整个报表。

错误报表 此报表显示已从威胁模型归档的错误及其状态。

模糊报表 模糊报表使用图表制作步骤中提供的体系结构信息来提供模糊目标的优先顺序列表。模糊化处理属于一种测试技术，它牵涉到为程序生成随机输入内容。令人吃惊的是，即使是不错的模糊化处理也可能会使任务崩溃，而其中的许多崩溃都是可被滥用的。（有关模糊测试的详细信息，请参阅为 Team System 创建自定义的测试接口提供程序或 Microsoft 模糊测试和会审流程。）

操作菜单

“Action”（操作）菜单下包含几个很有用的功能：缩略图视图、错误跟踪设置以及团队主管模式。缩略图视图使您即使在其他屏幕中，也可以轻松访问图表。如果您的图表非常复杂，而您又想在分析模型时在屏幕上显示它，则此功能会非常有用。它会自动调整缩略图的大小使其占用窗口的大部分区域，从而使您在重新调整其大小时整个图表都在可视范围内。

如果您只想记录错误而不输入任何错误信息，错误跟踪对话框将会弹出来提示您，但您也可以通过操作菜单随时调用此对话框。有一个非常简单的 XML 文件，利用它可以定义要填充的字段，或者也可以只编辑这些字段（假设“use template”（使用模板）框未选中）。记录下来的错误会被自动加上 "TM:[threat] affects [element]" 标题，而内容将根据威胁和缓解措施信息进行预填充。这些字段可以被删除，方法是选中它们并点击 Delete 键。

团队主管模式会在描述环境屏幕中显示一部分新内容，被称为“模板设置”。它允许团队主管更改指导问题并设置一个默认位置来保存威胁模型。团队主管还可以编辑文档标头信息中的字段，添加和删除一些内容以适合具体的环境。

由于希望早些完成这些操作，故 Paul 添加了 Contoso 项目跟踪号码作为新字段。在团队主管模式中保存的任何威胁模型都可用作模板。（实际上，任何威胁模型都可以用作模板来完成更多其他工作。）

更改指导问题包括编辑 XML 文件，此工作将从 SDL 威胁建模工具的 \Data 文件夹开始。其格式非常容易掌握。

威胁建模会议

当 Paul 给大家发送其威胁模型时，测试人员 Tim 非常不以为然。所有事情都突然涌向他，他问 Paul：“你们作为项目经理始终都认为一切都能正常运行，是吧？”

当您了解到测试人员及其怀疑态度可能会对威胁模型起到巨大的补充作用时，您可能感到非常惊讶。出于这个原因，许多团队都要求其测试人员来领导威胁建模过程。在本方案中，在 Tim 接手了威胁模型之后，他召开了两次威胁建模会议：一次的主题是同步过程并介绍图表，另一次的主题是审核并签字认可威胁。

在第一次会议中，Tim 花了 10 分钟的时间向所有人介绍了 SDL 威胁建模过程。然后，他提取出威胁模型图表并开始详细说明。不到五分钟，就找出了一个非常重要的缺失组件。

几分钟后，Tim 和 Paul 开始深入讨论 Web 服务器的实际构建方式。这并不是使会议进行下去的理想方法，但所有人最终都认为及早发现差异会为以后的工作节省大量时间。

在第二次会议中，团队遍历了这些威胁，讨论了一些解决方法，并针对威胁模型做签字认可。他们将文档签入到源代码控制中，然后继续进行开发。

考虑资产

一些已经建立了威胁模型的读者可能会注意到我们根本没有谈及资产。我们发现，许多软件工程师对其软件的了解要胜过对资产概念以及哪些资产可能会受到攻击者青睐的了解。

如果您要对房子进行威胁建模，可能会首先考虑您的家人或那些承载着丰富情感的照片或价值不菲的艺术品。也可能会首先考虑可能的入侵者以及当前的安全系统。或者会首先考虑一些地形，例如泳池或前廊。这些都与考虑资产、攻击者或软件设计相似。这三种方法中的任何一种都能发挥作用。

我们这里介绍的威胁建模方法要比 Microsoft 过去实现的方法简单得多。Microsoft SDL 团队发现这种软件设计方法对许多团队而言确实非常有效。我们希望这其中也包括您的团队。

请将您想询问的问题和提出的意见发送至 briefs@microsoft.com。

Adam Shostack 是 Microsoft 安全性开发生命周期 (SDL) 团队的项目经理。他负责开发 SDL 的威胁建模组件。