快速风险建模
大部分程序开发人员都懂得在软件开发生命周期（SDLC）早期发现问题的重要性。现有团体也创造了多种方法论，用来帮助我们把安全纳入到SDLC中去，这些方法论包括（并不仅限于）：
- 开放式软件保证成熟度建模
- 建立安全成熟度模型（BSIMM） (BSIMM)
- 微软的安全开发生命周期（SDL） (SDL)
所有的这些方案都建议，在设计层上的风险建模过程中设置一些变量。在广泛的范围来看，风险建模其实就是从黑客的角度来看系统设计的过程。大体上，我们可以将风险建模分解成以下主要步骤：
- 评估黑客关注什么。
- 列举系统可能存在的潜在漏洞。
- 评估这些潜在漏洞的危险：它们存在的可能性，如何去成功破解，它们如何帮助黑客完成在步骤1中的目的。
- 判断哪些对策是系统必须有的，以用来防止这些漏洞。
优势
风险建模提供了一些主要优势：
- 在设计上预防漏洞，而不是在SDLC中，从而减少了损失。
- 了解什么样的攻击和对策会与协同真正相关。
- 根据危险等级判定安全对策的等级。
我们可以从执行上区分风险建模具体行为：一位成熟敏锐的测试人员，会在试图攻击一个目标之前，在脑海中创建非正式的风险模型。 当我们试图在团队项目开发中引进风险建模时，依靠的是唯一的安全专家记忆中的破坏模型。正因如此，一些组织就有了规范化风险建模流程的想法。微软的流程无疑是最流行的几种之一，他们的SDL 风险建模工具也为其提供了支持。
正式风险建模
经过多年的经验，我们有机会执行和观察多个客户的风险建模过程。在许多实例中，综合的风险建模会消耗大量的时间，且效率非常低。在许多实例中，一些组织会选择一种正式风险风险评估流程用于专注他们的项目业务。大体上这些公司会执行以下步骤：
- 定义系统中所有数据类型，包括保密性，完整性和有效性（CIA）上的需求——比如：信用卡数据，身份验证，用户联系信息等。
- 定义所有有风险的人员——比如：外部恶意黑客，内部恶意黑客，活动分子、企业级间谍行为等。
- 定义所有用实例——比如：创建帐号，下订单等。
- 对每个用户实例，定义应用流程如何在系统组件中进行。组件可以是高层次的，如物理服务器；或是低层次的，比如设计层的构建——具体例子如：商业逻辑层，展现层等。并且记录哪些数据将在该用户实例中调用，以及相应的CIA需求。
- 对于每种操作，罗列涉及到的攻击载体，并查看这些载体在你的系统中是否存在。比如：如果一个用户实例包含数据库连接，那么SQL注入是一种很可能的攻击载体。你可以参考外部资源：OWASP ASVS、WASC风险分类，或以SANS/CWE的前25位风险为参考建议。
- 评估每种潜在风险的危险性并定义策略，比如使用存储过程来防止SQL注入。
- 在一份统一报告中记录所有这些内容，并在程序员开始编码前提交给他们。
尽管风险建模的优势可以简单地表述出来，但是执行这么一个花费时间的活动，通常意味着开发团队并不愿意去承担来自风险建模的重担。正因为这样，非常不幸的是，在我们的经验范围只有极少数组织真正执行风险建模。
反流程运动
随着敏捷的不断发展，开发讨论会对重量级流程的抵制呼声越来越大。Facebook前总管Yishan Wong在一系列文章中指出：外部强制流程（从上面而来）更难执行，而且更有可能被束之高阁，进而造成了多余的组织性惰性。即使在使用传统瀑布式开发的组织，他们也很少添加这么大，这么耗费时间的流程，除非是其投资回报率特别有说服力。尽管我们能够举出风险模型其价值的论据，但是非常明确的是，它将是一场苦战。就像我前期项目安全课程中一位学生所说：风险建模看起来非常棒，但是没有任何商业组织会为其设定目标。
作为一个行业，我们深陷于一种困境：不单单是风险建模很低效，会增加项目安全费用，更多的是许多组织并不愿意在这种新的、耗费时间的流程上耗费财力。
敏捷风险建模
经过对我们的客户和各大企业分别在风险建模和更常用的危险分析流程进行调查，我们发现了一个具有创造力的闪光点：Thomas Peltier的便捷式风险分析流程（FRAP）。FRAP是针对敏捷对于软件开发定义的风险评估。FRAP包含与利益相关者进行的会议，还有针对企业简单地列举主要风险。FRAP是一种正式的风险评估而非针对瀑布的粗略地敏捷：更少的规定，更少的综合，更少的时间消耗，更少的文档，还有更多的一致性。我们决定在这一点上采用FRAP方式来做风险评估，然后将其用于威胁建模。其结果就是我们创造了“快速威胁建模”。
快速威胁建模简介
一个快速威胁建模是由核心利益相关者根据商业优先级协助定义威胁和决策的单一的、持续4个小时的会议。
快速威胁建模(TME)来自以下几个核心理念，TME应该：
- 团队活动
- 快速并且可能依靠并不完整的信息
团队活动
风险建模能够帮助我们理解在商业上什么是重要的，获取一个应用所包含的技术细节，及其相关攻击载体。根据我们的经验，最有时效的方法就是把所有三个利益相关者召集到一个房间里讨论，其中包括商业/应用/产品所有者（在技术人员中经常被称为“业务人员”），架构师和/或主要程序员，一位应用安全问题专家。TME，从基本来说就是基于团队的。它帮助我们从权益三方相关者那入手，降低了对是否在项目中包含安全控制决定的抵制。我们建议安排4个小时的完整会议来讨论这个话题。如果安排上有冲突，无法实现，那就尽量安排一个尽可能长的会议—很多情况下，很可能只有一个小时。
快速
正式的风险建模需要记录项目所有数据类型，技术栈，用户实例和攻击载体。根据我们的经验，要收集大型企业级项目所有这些数据是不可能，原因如下：
- 只有少数几个组织会对他们所有数据类型进行分类。 而那些已对他们所有数据进行分类的企业在其维护更新上也非常吃力。
- 只有少数几个组织会维护整洁完整的项目用户实例库。这些知识往往分散在多个人之间。
- 对于项目技术栈深入的文档极少能在单一的文档中找到。
- 没有一个人能够评测出所有可能的攻击载体。而且每一个出名的攻击载体库，比如Common Weakness Enumeration(CWE)，对于能在使用合理时间分析出一个我们想要的结果是总是太庞大。
TME依据我们需依靠最容易获取的信息的原则。换句话说，将那些能轻易获取的文档带入会议，如果没有，那就根据人们脑海中的那些信息吧。我们总能在会议之后明了我们在理解上的主要差别。通过减少TME预期需求，我们可以加速该过程。随着我们对系统，其使用和攻击载体的理解更深入，进而更容易重现该过程。TME因而也与敏捷流程中“早发布，发布频繁”理论相符。“快速”理论的另外一个结果就是：TME只需维护轻量级文档。其最终结果应该是两个具有优先级的简单列表：风险和对策。如果我们需要更多的文档，比如为了审计，我们可以考虑做会议记录或对会议录音。
关注那些难以捕获的风险
TME会议是讨论领域特殊风险最好时机，比如特权提升。讨论领域特殊风险——比如跨站点脚本和SQL注入——将会非常有用，尤其是当我们现在所做的安全验证就是黑盒渗透测试。 换言之，如果你的程序员已经意识到SQL注入的危险，而你们也有另外一种验证方式，比如静态分析SQL注入。那么，讨论SQL注入在快速建模会议中就不是合理利用时间的表现。以我们的经验，想最有效利用有限的TME会议（尤其那些小于2小时的会议），就要讨论那些我们现有工具不能自动捕获的风险。
TME步骤和实例学习
在以下这一部分我们详细记录了TME的各个步骤。为了将其进一步具体化，我们将引入一个实例，该实例是我们与客户一起执行的一系列真实的TME的总和。
实例学习
Eastcoast United Bank是国内最大金融机构之一。近期，Eastcoast United的首席安全官启动了一项策略性方案。即引入SDLC安全。作为大型项目的一部分，我们将TME部分协助贯穿于多个商业产品线。商业银行部门当时正将研发他们现有主要网络应用的新版本，在线商务银行，并打算在设计阶段就将风险考虑在内。
TME步骤1：明确目——确定执行TME会话的原因
执行TME会话的主要原因，要么是帮助客户在应用设计时就考虑安全因素，要么是帮助在渗透性测试和/或源代码审查时关注那些与商业最相关的威胁。
实例学习步骤1：
我们的目标是在设计阶段就明确主要安全威胁。
TME步骤2： 收集信息
熟练去了解应用的目标，用户实例，部署和用户群，对于现有应用，最有效的方法就是使用应用本身。
实例学习步骤2：:
鉴于应用已经建立，我们主要通过真正使用该应用去准备TME会话，并不时地同某些程序员对话。这样就能够在短时间内掌握重要信息：
- 该应用的目标就是允许他们客户的财务部门监督其商业银行交易，允许与其他商业银行进行交互。
- 主要用户实例包括：
- 查看账户交易历史，包括支付与存储。
- 执行特定用户的特定类型的交易，包括查看异常活动的报告。
- 管理用户与其它应用的交互，比如：工资单，账单支付，提醒，电汇等。
- 将数据导入到主要会计业务软件包中。
- 该应用是基于互联网的，在全国范围内部署。用户主要是来自各个不同商业范畴的中小型公司的财务或会计部门。
TME步骤3：举行会议
当TME的准备工作已就绪，就举行会议。首先将会议定义为4小时，可以将其缩小至你能成功完成该会议目标的范围。在会议前，明确告诉会议参与者你的目的，并建议他们在会前尽力去了解相关背景知识，以有效利用会议时间。保证与会者中有可分别代表业务利益，开发团队和安全视角的人出席。对于大型应用，你可能需要不同的技术领导或架构师来展示不同技术组件。指定一位协调者，如果是你来引导该TME流程，那么通常就是你。
实例学习步骤3:
想要寻求能够召开4个小时的会议在Eastcoast United几乎不可能。取而代之，我们预订了一个2个小时的会议，并邀请了来自安全实践，风险实践，架构师，主要程序员和业务分析师的代表。
TME步骤4：列举威胁
你应该理解来自步骤2中的用户实例。为与会者针对每个用户实例进行解释，然后告诉他们：“如果我是一位有动机的黑客，那么会如何利用该用户实例。”这里的关键点不是讨论针对业务的特定威胁，而是关注如何利用该流程。而查看一组具有优先级的可能动机往往会有帮助。
- 对人身安全造成伤害
- 获取商业利益
- 窃取个人记录
- 获取有竞争力的优势
- 进攻组织中的利益相关者
- 削弱决策力
- 中断业务活动
通过使用与技术无关的方式去分析衡量风险，能使你关注“什么将发生”，而非怎么发生。可能更重要的是，它允许业务相关者参与到会议中，而不会在技术的术语中迷失。花多数时间在具有高攻击动机的项目上，而将少数时间花在那些低动机项上。将每个风险写在白板或翻转图片上用以讨论。在这个步骤的最后，你将会有一系列针对你应用的商业逻辑风险，而你可以在每次发布新功能，进行渗透性测试，或代码审查时去重新评阅他们。
以五分钟为限来讨论每一个风险。收集那些时间较长的讨论，在会议最后，由协调者来决定是否组织额外的临时讨论。
这里值得重申的是你不应该讨论与特殊技术风险相关的内容。根据我们的经验，这点对于某些安全技术人员和开发人员把握起来有些难度；因为一直以来他们都是被训练去考虑技术问题，而从高层次看待风险而不去考虑那些实质上的“如何”是有一定难度的。其实就是要提醒与会者，该会议的一部分就是要获取每个人的意见，包括非技术参与者。尽管如此，在列表中的风险还会在未来的发布中出现，并与未来新攻击技术出现时息息相关。
用例学习步骤4：
Eastcoast United开发人员并不同意攻击动机。与会者同意获取商业利益明显是主要的攻击动机，但是对于接下来会遇到什么还并不清晰。与其将前期时间浪费在建立共识上，我们听取了每个人的意见，并强制形成了一种工作优先级：
- 获取商业利益
- 查看他人财务数据/窃取个人记录
- 对Eastcoast United的客户造成财务上的损失
紧接着，我们开始关注特定的用户实例，将他们与攻击动机结合起来。比如：从用户实例“查看账户交易历史，包括支付与存储。”，我们获取以下几点：
- 对于“获取财务利益”动机，我们确定了一些具有创造性的风险:
- 恶性债权人试图改变支付历史以否认一已经实现的支付，进而获取二次支付。
- 恶性员工违法查看别的员工的数据。
- 恶性员工违法查看工资表或承包商的支付支出，以要求涨薪。
- 对于“查看他人财务数据/窃取个人记录”的用户实例，其风险更直观：
- 恶性用户查看其他用户帐号的交易历史。
我们继续为每个用户实例和攻击动机展开以上分析。我们确保不去否认任何想法，不论他们是否牵强人意。在某些用例上，我们看起来对某一特定的用户实例-攻击动机组合花费了太多了的时间，我们会将该问题打住，而移到下一问题。在另外一些实例上，则无法清楚地将攻击动机和某一实例联系起来。
最终，我们产生了一份风险列表，Eastcoast United能在每个应用的安全评估上重新使用。
TME步骤5：将风险与漏洞对应
在这一点上你可以请业务代表离开会议。现在我们可以关注于“如何——找出哪个技术上的漏洞会带来该风险。
对于步骤4中获取的每种风险或如何产生该风险。不要去关注于你是否有足够的控制力来阻止这些漏洞。比如：就算你已经在数据库中正确使用存储过程，SQL注入还是要作为风险来考虑。
在这里拥有一个针对你系统的潜在攻击媒介的清单会非常有用。如果你面对的是网络应用，那么网络应用安全联盟的Threat Classification project就是一个很好的起点。紧随着步骤4，对每个风险的讨论定时为5分钟，如果超过则将该问题打包。
如果你已经拥有如动态或静态软件等工具用来捕捉与领域无关的漏洞，那么就将这些时间用于关注与领域相关的漏洞，比如参数操纵。
用例学习步骤5：
在Eastcoast United，有安全意识的员工抓住了机会，开始列出那些可能会造成更高风险的漏洞。
他们找到了漏洞包括如下几点：
- 通过大量请求来拒绝服务
- SQL注入
- 跨站点脚本
- 终端用户的认证控制不足（如：强制检测，密码复杂性不足等）
- 跨网站伪造请求（CSRF），意在为在步骤4中简述的交易伪造
- 参数操纵，意在为在步骤4中简述的对权限升级的操作
- XML注入用以下行web服务
- 在服务期间，验证不充分的SOAP web服务请求
TME 步骤6：评定风险攻击等级
绘制一幅二维的坐标图。横坐标为影响，纵坐标为可能性。这个图标代表了风险，其左上角代表最高风险，右下角代表最低风险。现在，团队查看步骤5中所定义的每个漏洞，并根据风险划分等级。由于是漏洞之间彼此对比，坐标比例不再重要。通常这一步骤会花费很长时间去讨论，所以必须确保在分析单个漏洞是所花费的时间不超过2分钟。同时也应忽视在分级时所存在的干扰。这点非常重要，你是在对你系统可能存在的漏洞评定优先级。在这个时候，你无法确定已经存在一种特定的对策。
在这一步骤最后，你将获得一份针对系统带有优先级的漏洞列表，同时也从步骤4中获得了相应一组商业逻辑风险。
用例学习步骤6：
对于风险等级的讨论是非常激烈的。在大部分漏洞评定上几乎不可能达到共识。与会人员总是希望将大部分风险至于最右上端的象限里。我们总是需要提醒他们将所有风险指定为高风险，意为着没有优先级。尽管被迫评定优先级很困难，却也很重要。几乎所有人都同意SQL注入是风险最高的漏洞。在跨站点脚本和对权限升级参数操纵上产生了最激烈的论战。两位开发人员坚持说，权限升级参数操纵对他们的应用不具有攻击性。我们提示他们在这一步骤中与策略是否存在并无关系。
TME步骤7：列举策略
最后一步是决定步骤6中每个漏洞相应的解决策略。你将会发现Common Weakness Enumeration对这一目的非常有用。正因为在步骤6中已经针对漏洞进行风险排序了，其相应的策略也顺应优先化了。现在你就可以根据风险，完成针对你业务真正在乎的漏洞的策略。
用例学习步骤7：
这一步骤是最简单的，而且也少有争议。在经历过许多安全审计之后，Eastcoast United的开发人员大体上知道如何提供策略。比如：
- 对于数据库交互，总是使用绑定了正确变量的存储过程，以避免跨站点伪造请求
- 执行上下文输出编码以避免XSS
- 在服务器上强制部署多层认证模式以避免权限提升
这些特性将纳入到新版本的设计中。毋庸置疑会减少，但不会完全消除将被完成并通过安全测试的应用中的漏洞数。
挑战
快速建模并不适用于每个人。它在严谨和正式程度上约束不那么严格，这会造成遗漏某些重要风险。其轻量级分析意味着它适用于某些类型的应用，比如使用特定编程语言的企业级互联网应用。但是对那些有更复杂风险的程序，比如操作系统，就不适用。尽管如此，TME默认你已经有一位安全问题专家可以参加这个4小时的会议。在某些环境下这是不可能的。这些挑战意味着TME对你并不适用，而你可以考虑其他方法论，比如：Microsoft’s SDL或Octotrike。
总结
快速风险建模是一种轻量级技术，用以优先化应用的安全工作。基于4个小时会议模式，TME弥补了安全设计完全缺失设计和复杂完整设计之间的空白。TME建立了共识：主要利益相关者在商业上的风险，领域无关及领域特定风险，领域特定风险通常需要人来分析才能发现。
我们已经成功为多个不同领域内的客户执行了TME会议。它为我们在测试工作上提供了有用的优先级信息，也帮助开发团队关注安全开发和设计工作。
TME在定义明确的问题空间上最成功，比如使用特定编程语言的互联网应用。TME不像其他方法论那么严格，但要求你所创建应用的安全部分需要安全问题相关专家。
最后，TME最好应用在那些由于投入市场时间压力而无法执行更严格方法的项目，或在敏捷环境中用以避免重型流程的项目。
资源
- Open Software Assurance Maturity Model
- Building Security-In Maturity Model
- Microsoft’s Secure Development Lifecycle
关于作者
Sahba Kazerooni，Security Compass Profession Services主管，负责管理Security Compass在北美和全球最新型的咨询和培训活动的国际咨询师。Sahba的能力涉及渗透测试的一手评估，风险建模，源代码审核，以及安全顾问和技术培训。他在软件开发生命周期和Java编程语言上有丰富知识。Sahha同时也是国际上知名的安全话题讲师。他在世界各地的会议中做过演讲。他在SANS机构进行Java安全编码培训。他同时也通过ISC2对其授权信息安全专家精英社区提供了大量演讲。你可以通过邮件方式联系到他： [email protected] 。
Rohit Sethi，SD Elements 的产品副总裁。是向软件开发生命周期加入安全控制的专家，Rohit是一位SANS的课程开发者和J2EE安全开发的指导者。他曾经在FS-ISAC、RSA、 OWASP、Shmoocon、CSI National、Sec Tor、Infosecurity New York and Toronto、TASK、ISC2的安全领袖系列会议以及其他地方做过演讲和讲师。Sethi先生为Dr. Dobb's Journal、TechTarget、Security Focus以及Web Application Security Consortium (WASC)写过很多文章，他已经被ITWorldCanada 和 Computer World认证为应用安全领域专家。他同时也领导着OWASP设计模式安全分析项目。你可以通过邮件方式联系到他：[email protected]。
[i] 注意：我们并没有明确地定义“威胁”的概念。在我们收集的经验中，曾经听过也看过对危险至少是多种解释。在我们看来，那些用来调查和定义文字意义的时间，完全可以用来完成一个TME任务。同时也可理解，有些人不同意这种想法，在这种情况下，你应该想出一种内部定义，并在会议之前一直维持这一定义。