《威胁建模：设计和交付更安全的软件》—

本节书摘来自华章计算机《威胁建模：设计和交付更安全的软件》一书中的第2章，第2.2节,作者：［美］　亚当·斯塔克更多章节内容可以访问云栖社区“华章计算机”公众号查看。

2.2　集体研讨

集体研讨是列举威胁的最传统方法。召集经验丰富的专家集聚一堂，提供工作环境（白板和鸡尾酒餐巾纸都是很传统的），然后开始讨论威胁。集体研讨结果的质量与专家经验和所用时间有很大关系。
集体研讨分为产生创意、分析、选择创意三个阶段。集体研讨将会发现各种类型的可能发起的攻击。在产生创意阶段，应该禁止批评。如果你想要挖掘所有可能的潜在威胁，批评气氛会起到阻碍作用。可由一名会议主持人来不断推动研讨过程。
集体研讨的时候，关键是要有威胁建模技术方面的专家参与。不然，很容易陷入对威胁建模本身不能发挥多大效用的假设。不过，若是技术自信的专家在场，一定也不要到最后变成“自豪的父母”被“孩子”软件冒犯了，被别人纷纷说丑陋。一条有益的原则是：受到攻击的是软件，而不是软件设计师。同时，集体研讨最好能召集有领域经验且技术类型不同的专家参加。
集体研讨也可能讨论约定范围之外的攻击威胁。举例来说，如果你正在设计一个聊天软件，内存管理部件对CPU的威胁就属于范围之外的讨论，但是如果你正在设计主板，这些威胁也是你在威胁建模时所应关注的。一种解决方式是列举这些范围之外的威胁，例如“管理员是恶意的”或者“攻击者修改了其他系统的硬盘”，以及列举一些攻击有同等效力的威胁，例如“攻击者可以破坏堆栈和执行代码”，通过列举这些范围外的问题，能够使所有威胁识别者能对这些问题形成一致的认识并加以解决。集体研讨的另外一个目的是鼓励大家“像攻击者那样思考”，这在第18章中将更详细介绍。
在对Acme财务报表威胁建模时，集体研讨后的威胁类型包括突破互联网、让首席财务官喝醉、对守卫行贿或者可能发布预测报表的URL等。这可能有些混杂，我们会在接下来的部分为大家提供更为集中的方法。
2.2.1　集体研讨的变种方法
前面讨论的自由或者“常规”的集体研讨，是威胁建模的一种方法，也有一些更为特定的方法帮助你开展集体研讨。下面讨论几个经典的集体研讨变种：场景分析、事前剖析、电影情节法。
场景分析
集体研讨时重点关注事件场景。如果你在总体设计中使用书面场景，该从哪开始，询问哪里可能出错，或可以运用钱德勒（推理小说家）定律的变种（“一有犹豫，就会有人手上拿着枪走进门来”）。当然你不必局限于拿枪的人，你可以使用附录C里的任何攻击者。
以特定场景的集体研讨为例，对尝试将手机传给酒吧一个可爱的人这个场景进行威胁建模，这是很有趣的威胁建模练习。手机接收者可能给红十字会短信捐赠、给一个重要的人发短信“不要再骚扰我”，或者在Facebook上发布“我不需要提示”或者“我太令人恶心了”，更不要说偷走手机或直接扔到啤酒杯了。
该示例场景要基于适用于当前开发周期的产品场景或用例，应该包括故障转移和复制，以及在没有适当的验证和授权的情况下，如何实现服务渗透。
事前剖析
决策科学专家Gary Klein建议了另一种集体研讨技巧，他称为事前剖析（Klein，1999）。该想法是汇集所有决策内容，让其假设当项目截止期限刚过或者关键里程碑刚过，所有事情都很混乱。核心概念就是，心中想着“失败的假设”，找出为什么参与者认为这会变得混乱。事前剖析的价值在于其引入的框架。通常我们会对项目持乐观态度，如果我们是以失败做假设目标，才能给所有参与者提供表达怀疑想法的机会。在威胁建模中，假设某个产品已经被成功攻击了，这时你就可以表达怀疑和忧虑了。
电影情节法
集体研讨的另一个变种是电影情节回放。“常规的集体研讨法”和“电影情节法”的关键区别是能否鼓励人员对攻击产生大胆、自由的场景构建。可能类似科幻小说：不保护任何人，侵害人类尊严、自由和隐私。比较好的电影范例包括《十一罗汉》（Ocean’s Eleven）、《偷天换日》（The Italian Job）及邦德电影。如果你想要构建结构化的电影情节，可创建三个列表：有缺陷的主角、聪明的敌手、时髦灵通的设备。然后你可以把它们结合起来。
电影情节法当中的威胁范例可能包括针对Acme SQL的外国间谍编写的代码，第四次尝试连接以管理员权限进入、诡计多端的首席财务官攫取公司资产、试图从控制台非法进入数据库、用绳索从天花板进入以避免踩到地板里设置的压力垫。要记住，这些电影情节法同样对Acme及其用户适用。
电影情节法这个术语是一个备受尊敬的安全专家Bruce Schneier创造的。在一次电影情节威胁比赛仪式上，他表示：“这个比赛的目的虽有点荒谬、幽默，但是我希望能变得有意义。恐怖主义是真实的威胁，这要求我们能够正确猜出恐怖分子下一步行动并采取安全措施，否则我们的环境将变得不安全。”（Schneier，2006）其实，这并不只适用于反恐，这些生动形象的恐怖威胁也可能是我们威胁建模方法论中的一种威胁。
2.2.2　文献检索
在开始集体研讨之前（或者其他找到威胁的方法），了解类似的系统所受到的威胁对启动威胁建模工作是很有帮助的，可以利用搜索引擎或者翻阅学术文献，在看到学术文献的引文时可追溯其原文了解威胁信息。了解你的竞争对手或者相关产品也会非常有帮助。从开始检索你的竞争对手信息时，加上“安全”“安全漏洞”“渗透试验”“pwning”“黑帽”等词，并充分发挥你的想象力和创造力。本书给出了常见威胁，特别是在第三部分“管理和解决威胁”及附录中。另外，Ross Anderson著的《Security Engineering》（Wiley，2008）收集了大量现实世界中的攻击威胁以及总结出的工程教训。尤其是当你建立的威胁模型与书中威胁类型相似时可以参考。
有关针对数据库的威胁文献查阅可以更充分理解SQL注入攻击、备份失败、内部攻击，建议边查阅边做记录。文献查阅对那些正在锻炼自己威胁建模能力的人尤其有帮助。时刻记住，你遇到的很多威胁都是非常特定而具体的，需要结合更为通用的威胁案例，或者查找类似威胁类型及通过集体研讨来解决。
2.2.3　集体研讨方法的观点
集体研讨及其变种方法存在着各种问题。集体研讨经常产生难以或者无法解决的威胁分析结果。而且，集体研讨会往往不限定讨论范围或者界限，得出来的威胁也很大程度上取决于参与者以及研讨过程如何进行。当专家们坐到一起，往往是非系统化的讨论，这对专家来说是有趣的事，也经常产生有趣的结果，但是经常出现专家短缺现象。而工程师们会对结果的不一致性感到沮丧：“有两个专家，却得到三个答案。”
还有另外一个和集体研讨会议结束标准相关的事情要考虑：很难知道何时能够结束集体研讨，是因为讨论成果很好而结束还是只因大家都疲惫了而结束。项目管理可以通过评估项目进度做好项目计划，而这就很难把握。避免会议时间难以控制的最好办法就是简单地规定会议时间，并要求在此时间范围内完成研讨。但这种方法的可信赖程度不高，不能保证发现所有有趣的威胁。
考虑到采用漫无边际的集体研讨方法分析威胁存在一定困难，并且很难定义研讨会议结束标志，就需要考虑使用其他威胁建模方法，使威胁建模过程更规范、正式、可重复，较少依赖于参与者的主观态度和知识。这些就是本章后面要涉及的内容，在本书第二部分中也会讨论到。