重振您的威胁建模过程

核心提示：目录 威胁建模方法速成威胁模型掌控完成时机推动威胁建模过程相机而动：应变请帮我解惑！我的同事 Ellen 总是说每个人都在假想威胁的出现，我们都会想象机场出现危险，重振您的威胁建模过程，假想自己的家园出现意外，设想自己资产可能会受到威胁：我们的家庭、珠宝以及那些代表着丰富情感的老照片，先将材料分解开来，它不仅会带来单纯

目录

威胁建模方法

速成威胁模型

掌控完成时机

推动威胁建模过程

相机而动：应变

请帮我解惑！

我的同事 Ellen 总是说每个人都在假想威胁的出现。我们都会想象机场出现危险。假想自己的家园出现意外。设想自己资产可能会受到威胁：我们的家庭、珠宝以及那些代表着丰富情感的老照片，一旦损坏就无法弥补（在我们那个年代还没有数字照片）。我们可以根据体系结构来构想威胁：当我们忘带钥匙的时候，我们可以利用现成的一面墙、一扇观景窗和一棵很容易攀爬的树。还可以根据攻击者构想威胁。我们会担心窃贼和掉入池塘的小孩儿。还会担心天气、是不是会发生地震、大雪或龙卷风。

如果我是一位管理顾问，我会说您使用了一套成熟、多元化的评价流程，它十分依赖直观推断和几率很低的实例重复性。同时，很可能您的考虑尚不周全，采取的防御措施也有漏洞。也不太可能制定一项家庭防御管理计划或针对您的家园进行渗透测试。

当我们构建软件时，不管我们所处的环境是灵活多变，还是上行下效，我们都需要在构建的内容、不构建的内容以及保障措施上达成一致。在过去的几年中，人们一直认为威胁建模是一项非常繁重的工作，在流程上墨守成规。进一步添加流程有几条充分的理由；我想谈谈这些理由、从这些流程中学到的心得，以及提高威胁建模的趣味性，使其成为一项灵活高效的活动，任何人都可以参与。

威胁建模的方法

威胁建模的覆盖面很广。考虑自身的需求、技能和计划，然后采用最适合您的一种方法，而不是费力去找什么万能良方。在建模过程中，有人会问“您的威胁模型是什么”、“您已经完成对该组件的威胁建模了吗”，这两个问题一个是需求启发，一个是设计分析。在 Microsoft，我们基本上是侧重后一项技术。

除了我在本专栏中提及的之外，还有很多威胁建模方法。其目标也是多种多样。您的威胁建模过程追求的是效率还是深度？应当侧重于安全完整，还是易于使用？每次会议是否应邀请专家或开发人员？您需要遵守一定的组织或业界规则？如 Microsoft® 安全开发生命周期 (SDL) 或者针对医疗设备制造商的规则。更高的目标应该是提早了解安全问题，以便您可以在设计阶段加以解决，而不是在更晚的时候去克服设计缺陷。

处理威胁建模活动有以下几种主要方式：

资产 资产驱动的威胁建模非常类似于考虑您要保护的家庭财产。您先列出软件具备的相关资产，然后考虑攻击者可能危及这些资产安全的方式。例如，存储客户信用卡的数据库或包含加密密码的文件。

有些人可能会将资产解释为威胁建模图表的一个元素，认为 Web 服务器本身就是一种资产。这是很不准确的。数字资产是攻击者想要读取、篡改或拒绝您使用的内容。

攻击者 攻击者驱动的威胁建模考虑的是盯着您资产的人，它由对攻击者能力的了解推演出对他们可能的攻击方式。如果敌方是一支已暴露了战略方针、在一定地域活动并且武器系统开发周期长的外国军队，那么非常适合采用这一方式。如果敌方是一群组织松散的匿名黑客，它的作用就要逊色得多。

一般来说，这种威胁建模对软件是否有用还不是很清楚。当然，一定有人将“从攻击者角度考虑问题”视为设计分析的有效内容。而且，更无把握认为能再现这一过程以向人员提供培训。如果您要从攻击者着手威胁建模，标准集可能值得一用。它有助于描绘出一小部分这样的反面角色。

软件设计 设计驱动的威胁建模以您围墙和窗户所在的环境为出发点。您绘制了图表，而又担心图表中出现任何漏洞（这就是现代 SDL 威胁建模过程的本质，因为每个软件用户都知道如何在白板上绘制图表）。

软件中的各种攻击面就相当于围墙和窗户，如文件分析程序或网络监听服务—套接字、远程过程调用 (RPC) 服务、Web 服务描述语言 (WSDL) 接口或 AJAX API。它们是信任边界，您应预期攻击者将首先在那里取得立足点。

速成威胁模型

威胁建模不一定是繁琐之事。图 1 中所示的流程描述了基本威胁建模过程，它将引导您快速、轻松地完成这一过程：

使用图表描绘您的应用程序，并在白板前面利用该图表讲述应用程序的发展历程（请参见图 2）。使用圆圈表示代码、方框表示代码之外的事物（人员和服务器）、用鼓形表示存储。我们的团队使用外观滑稽的平行线表示数据存储。使用虚线绘制几条信任边界来划分区域。

集思广益，找出威胁。如果您遇到问题，请针对应用程序的各元素应用 STRIDE 威胁模型（如图 3 所示）。不要担心出现改变，尽量放飞您的思路。

考虑威胁是聚中于一点还是完全分散，确定是否需要重新设计。不管怎样，您都可能想设计或添加一个组件来将它们一网打尽。如果所有威胁集中于一个位置，可能意味着前门是您的关注点，而其他位置则不必担心。

抑制一级威胁。注重广度而非深度。按顺序考虑威胁和抑制措施是一种极有效的方法。一级威胁是打开门。一级抑制措施是锁。二级威胁是有人撬开或砸开锁。二级抑制措施包括正确安装牢靠的锁和坚固的门。三级防御措施可以是门上的报警系统、以及为防止有人切断电线，沿电线设立报警消息。以此为例，如果您首先担心的是有人切断警报系统的电话线，然后才关心门锁，那么您的顺序有误，设计软件威胁建模时也是如此。

对错误进行归档，以便您可以修复发现的威胁建模问题。

图 1 威胁建模过程

图 2 用图示描述应用程序以帮助威胁建模

图 3 STRIDE 威胁模型

威胁	属性	定义	示例
假冒	身份验证	模仿其他事物或其他人。	假扮成以下任一项：billg、microsoft.com 或 ntdll.dll。
篡改	完整性	修改数据或代码。	修改磁盘或 DVD 上的 DLL，或者在遍历 LAN 时修改数据包。
否认	认可	声称尚未执行操作。	“我没有发送该电子邮件，”“我没有修改该文件，”“天哪！我确实没有访问该网站。”
信息泄漏	机密性	向无权查看信息的人泄露信息。	允许某人读取 Windows 源代码；将客户列表发布到网站上。
拒绝服务	可用性	拒绝用户服务或降低其级别。	Windows 或网站故障，发送数据包并大量占用 CPU 时间，或将数据包路由至黑洞。
提升权限	授权	在没有合理的授权的情况下获得功能。	允许远程 Internet 用户执行命令是一个典型的示例，但从一个受限用户升级到管理员也属此列。

掌控完成时机

如果您的图表显示出了系统的所有相关部件，并且您对图中的每元素都应用了 STRIDE 模型，那您的工作很出色。（如果您能记下每个漏洞的出错点，那就锦上添花了。）

但是，这有点象是在您通过检查确定所有门窗均已上锁后，对您说工作完成了。可能这样做已经足够了。也可能这是您有时间能完成的事。或者您正在想再进一步，考虑是否会出现绕墙而入的局面。

您的组织或客户承受风险的能力决定措施的深入程度。同时发挥作用的还有您的预算和经验。您可能想体验一下威胁建模，在验证了它的成功性后在适当时机迅速退出。或者您正在为某些存在安全隐患的事物设计控制系统，需要花费一定的时间做深入研究。

所以要想掌握完成时机，需要平衡诸多因素。首先需要考虑那些对您的行为程度有所规定的策略和法规。其次要评估所开发系统的风险。最后还要考量有多少时间和资源可用于威胁建模和随之产生的抵制和测试操作。

推动威胁建模过程

威胁建模不能仅凭自身完成。必须要有外部推动因素。推动因素对其工作方式有着重大的影响。如果您周围有一个甚至几个人对安全感兴趣，他们就能在组织内推动威胁建模。

问题是如何让他人参与进来，或者是否需要他人的参与。这既是一个文化问题，也是一个资源问题。如果热心于此道的人能为所有事物建立威胁模型、共享成果并修复检测到的问题，那真是太棒了！哪还用其他人介入啊？

遗憾的是，有时候那些安全粉丝们另有重任，您必须要找其他人帮忙。Microsoft 发现威胁建模最好有安全专家的协助，但不一定能经常具备这一条件。

您的专家就是那些脑子里时刻装着安全，并且能有条有理地完成这项工作的人。就是那个告诉您在您的设计环境中什么是否认威胁的人。您的专家可能拥有某种证书。他可能指出您的代码和操作中的安全缺陷。她可能参加（或想要参加）SANS 或 BlackHat 这类会议，或者已在 Microsoft 安全公告中受到称赞。

通过为人们提供架构和工作反馈，并将其分割为容易处理的小片段，每个都能自检并有一定的规则，会有相当不错的效果。但是，如果分割过细、规则过多（或规则错误），整个过程会变得十分烦琐，全无乐趣。因此，专家的数量和他们能投入的时间决定着分割的程度。

相机而动：应变

计划更改。这是不可避免的。如果出现这种情况，就要花费成本使文档与每个人头脑中的诸多真实计划步调一致。无论您的灵活性有多大，任何大型项目总是有一些体系结构方面的文档。它可能是一套描述一堵高墙尺寸的 Visio® 图表，或是一块无法擦除的白板。

出于威胁建模的需要，您想知道什么时候您的操作会向该体系结构中加入新的信息边界。在执行这些操作时，您必须要考虑这些新威胁的影响。

有时，威胁是直接的。比如，您将组件更改为侦听端口 80。如果威胁是直接针对该组件的，您可以很容易地发现并解决它们，然后继续。

而有时威胁是间接的。比如您决定从 Active Directory® 和轻型目录访问协议 (LDAP) 中得到配置数据。这很可能产生新的组件（您切换用的目录接口和抽象层），但它还会造成对配置数据的更改。以前，数据由管理员用户输入您的 GUI。现在是通过网络使用几种不同的协议来传输。可能您需要非常仔细的检验抽象层中的数据，并且在读取和操作配置数据时采取更为谨慎的方式。

请帮我解惑！

您可能正坐在桌前冥思苦想该采取什么措施。或者在理解整个过程方面遇到困难。也许您的迷茫就是一个步骤所致。这里列出了一些我们在 SDL 团队发现的问题和摆脱困境的方法：

有些团队在绘制图表方面有所不足。如果您不了解系统的功能，请向专家咨询，或分割威胁建模过程，然后用心研究您所负责的那一部分。

如果您不了解系统应有的功能（可能您正在处理的是一个新系统，您有两套不相上下的设计），威胁建模能帮您理清决策制订。绘出两套设计，找出漏洞最大的那项设计。

如果您不了解如何表示元素，别为此担心。您可能使用了错误的元素类型，但会逐步纠正。但牢记一点，从本质上讲，您负责的所有代码（无论由谁编写）都是一个过程。您所读取和写入的所有数据都保存在数据存储中。

您可能还会在列举威胁方面遇到问题。首先，千万不要让一个威胁缠住手脚。先把它标出来，稍后再做处理。如果没有效果，请查看 Larry Osterman 在威胁建模方面的论述，它会对您很有帮助 (go.microsoft.com/fwlink/?LinkId=118281)。Michael Howard 的著作《编写安全代码》和《安全开发生命周期》也是很好的参考资料。

如果在验证威胁模型和抑制计划方面有问题，请查看图例是否表示了代码，以及开发人员和测试人员是否就此达成了一致。检查您是否针对每个元素列出了各类威胁（请参阅 2006 年 11 月刊《MSDN® 杂志》中的文章“使用 STRIDE 方法发现安全设计缺陷”，网址为 msdn.microsoft.com/magazine/cc163519）。最后，检查您是否针对每项威胁记录并修复了程序错误。

如果您身边有专家，记得向他请教。我们的专家也是彼此求教的。如果没有，想办法通过雇用或在博客上发表问题找一位专家。

不要让自己被一个问题困扰。威胁建模是一项不容忽视的工作。记得要从中寻找乐趣。先将材料分解开来，它不仅会带来单纯分解组装的乐趣，还会产生趣味横生的效果。