一切模型都是错误的,不过有些是有用的。
——George Box(20世纪著名统计学家)
在构建软件系统时,人们会遇到很多可以预见的安全威胁,对此,本书描述了一些有用的威胁模型,可以用于消除或减轻这些潜在威胁。
威胁建模,名字本身听起来非常精妙,但其实指的是我们本能都会做的事情。比如,如果让你对自己的房子进行威胁建模,你会开始想房子里都有什么珍贵的人和物:你的家人、传家宝、照片,可能还包括明星签名海报;然后,你会想别人会用什么办法闯进家里,比如通过没有上锁的门,或者开着的窗子;另外,你还会想是什么样的人会来偷东西,比如邻居家调皮的孩子、职业小偷、瘾君子、跟踪狂或是早已盯上你们家珍贵名画的人。
上述所说的这些现实生活中的例子在软件世界里也有相似的实例,不过现在重要的不是如何防范每一个威胁,而是首先你要建立这样的思维方式。如果你的朋友求助于你评估他房屋的安全性,你会伸出援手,但你可能会对自己分析的完整性缺乏信心;如果别人要求你去保障一栋办公建筑的安全,你可能也会头疼,如果要你保障军事设施或监狱的安全就更难了。在这些情况下,只凭直觉是不够的,需要使用相应的工具来解决问题。本书就为读者提供了这样的工具,利用结构化、高效的方法来思考威胁建模技术。
本书讲述了什么是威胁建模,个人、团队、组织机构为什么需要进行威胁建模。这其中的原因包括:威胁建模可以在早期及时发现安全问题,提高对安全需求的理解,以及设计和交付更好的产品。这里通过五个部分来对本书内容进行概要介绍,包括威胁建模定义及其重要意义,哪些读者群适合阅读本书,本书为你提供什么,如何使用本书以及威胁建模技术的最新进展。
什么是威胁建模
日常生活中,大家对威胁建模并不陌生。比如,出于无奈在机场排队时、偷偷溜出家门或去酒吧时都会对威胁进行建模:在机场,即使你没有打算真那么做,但你可能会偷闲思考如何偷偷摸摸带一些东西混过安检;偷偷溜出去的时候,你会担心有人注视着你的行动;当你在高速路上超速时,你可能在建立隐式的威胁模型,其中主要威胁就是警察,你会想他们就潜伏在广告牌后面或天桥下面。另外,公路上的妨碍物(比如穿过马路的鹿或者雨水)都可能出现在你的威胁模型中。
在威胁建模时,通常你会用到两类模型。一类是你所构建的软件或系统模型,一种是威胁模型(可能出错的地方)。你所构建的软件可能是网站、可下载的程序或应用,或者是可以在硬件中传递和交付的软件包,也可能是分布式计算机系统或可能成为“物联网”一部分的“物”。威胁建模是为了看到整片森林,而不是简单的几棵树木。好的模型可以帮助人解决几类或几组攻击,从而构建更安全的产品。
英语中,“threat”一词有很多意思。可以用来形容一个人,比如“奥萨马·本·拉登(Osama bin Laden)对美国来说是个威胁”,也可以形容多个人,如“内部威胁”;另外,还可用来形容一个事件,比如“本周末将面临暴风袭击的威胁”,也可以用来形容缺陷或者受攻击的可能性,比如“你如何应对针对信息保密的威胁?”此外,“威胁”还可以形容病毒和恶意软件,如“这一威胁有三种传播方式”,也可用来形容行为,如“存在操作错误的威胁”。
同样,“威胁建模”也有很多含义。“威胁模型”这个词可用于很多不尽相同有时甚至互不兼容的方面。其中包括:
作为动词,例如,“你对威胁建模了吗?”这句话的意思是说,对于你所构建的软件或系统,你是否仔细检查分析处理过,以查看软件系统哪里会出现问题?
作为名词,可表达使用的是什么威胁模型。比如,“我们的威胁模型是拥有机器的人”或说“我们的威胁模型是个专业而坚定的远程攻击者”。
可以表达如何构建一组理想化的攻击者。
可以表达威胁分类,比如篡改威胁。
毫无疑问,威胁建模本身有很多含义。所有这些含义在不同语境下都是有用的,而且都是正确的,所以最好不要浪费时间争论它的含义。争论其具体的定义是毫无意义的,唯一的方法就是抛开其定义。本书涵盖威胁建模各方面的技术,涉及大量可操作的具体技术,以帮助设计或者构建更安全的软件。本书还将探讨如何解决以下现实问题:一些技术要比其他的技术更有效,并且一些技术对有特定技术或经验的人使用更有效。
威胁建模是防御的关键。没有威胁建模,就会跟打鼹鼠游戏一样,永无完结。
总而言之,威胁建模就是利用抽象的概念来思考风险。
威胁建模的原因
在当今快速发展的世界里,趋势是精简开发活动,而威胁建模有着重要的存在价值,包括早期发现安全缺陷,理解安全需求,设计和交付更安全的产品等。
. 早期发现安全缺陷
想象你在建造一座房子,对安全结果的影响你越早决定越重要。由木制墙及大量落地窗构建的房子会比砖石及少量窗户的房子的潜在危险更大,因此要根据房子建在哪里等因素选择一个合理的方案。如果在决定之后再更改,成本通常会很高。当然,作为补救,你可以在窗子上加防盗护栏,但是,若能最初就有一个更合理的设计不是更好吗?这种权衡也可以用于技术当中。威胁建模可以帮你发现设计上的问题,甚至在你一行代码都没写的时候即可发现问题,而此时也是发现这类问题的最佳时机。
理解安全需求
好的威胁模型能帮助你回答“那的确是实际的安全需求吗?”举例来说,系统是否需要保护设备免受他人非法拥有?苹果公司在iPhone手机产品中给出了肯定回答,这显然不同于传统的个人电脑领域。当你发现威胁以及如何处理威胁时,你要明确需求。有了更清晰的需求,你就可以专注于处理相应的安全特性和性能。
需求、威胁与防御之间是相互作用的。在威胁建模时,会发现一些威胁不会影响你的业务,这样的威胁可能不值得处理。或者需求可能不完整,威胁处理过程复杂或者处理代价高,这时你就需要做出权衡,是在目前仅解决部分威胁,或者接受(沟通)你无法解决所有威胁的现实。
设计和交付更安全的产品
在构建产品时尽早考虑安全需求和安全设计,能大幅减少重新设计、重构系统,以及经常出现安全漏洞的可能性,这样你就可以从容地交付更安全的产品,最终构建更完善、更快速、更经济、更安全的产品,把更多的精力投入到用户需求的特色功能开发中。
解决其他技术无法解决的问题
威胁建模会发现其他工具无法发现的一系列问题,可能是遗漏错误问题,如远程连接验证错误,而代码分析工具无法发现该类问题。其他问题可能是你在系统设计中所独有的。一般地,开发者在构建新软件时,相应地会引入新的安全威胁。通过抽象的概念模型描述可能出现的错误,可以帮助你发现在其他系统里会出现的相同和相似的问题。
由此可得出结论:威胁建模不应该聚焦于其他人身安全工程和网络安全工程中可发现的问题(除非是在早期,为了避免以后的重复劳动)。举例来说,假如你正在开发一个调用数据库的产品,威胁建模会快速定位SQL注入攻击以及可能会被攻击的注入点。然而如果没有威胁建模,可能在未来遭受攻击时才发现该类威胁。因此,威胁建模应该聚焦其他技术无法发现的问题。
本书目标读者群
本书目标读者是专业技术人员,如软件工程师和系统管理员,以及系统分析师、架构师等,本书也有很多可供信息安全专家阅读的内容。本书不同章节针对的读者有所不同,总体来说,前面一些章节适合大多数读者阅读(或者说除了信息安全领域之外的其他专业领域人员),本书后面章节内容则更多的是面向安全专家。
并非只有信息安全专家、专业人士或爱好者才能阅读此书。本书希望你能通过阅读了解到现实中很多人的兴趣和欲望是跟你不同的。比如,他们可能想要从你那里得到钱财,或者他们有别的目标,比如他们拿你做牺牲品夸大自己或是用你的电脑攻击别人。
本书语言通俗易懂,适合任何会编程或设计程序的人,只是有些时候为了表达更加准确或更加清晰而使用一些术语,本书后面还附有术语表。
本书为你提供什么
通过阅读本书,你能获得丰富的威胁建模技术领域相关知识。你可以将其应用在你的项目中,开发与部署更安全的软件。此外,你将学到如何明确、可度量、合理地权衡安全措施,学到一整套工具以及如何应用。同时,你可能会发现发布的软件中一些看起来很棒、有很好的创意,但实际上却暗藏危机。另外,你将学到阻止你有效威胁建模的原因,以及如何避免这些问题。
通过阅读本书,你将学习威胁建模的输出结果——通常叫做“漏洞”(bug)。业界存有异议:普遍将代码中的问题归为漏洞(bug),将设计中的问题归为缺陷(flaw)。本书并不对其进行详细讨论,因为本书的主要目的是应用威胁建模解决问题,上述争议对本书讨论的内容无益。
不同读者获益不同
本书旨在为不同的技术人员提供有益的帮助,包括从事软件开发人员,以及为满足业务运营或商业目标要求而从事软件安全的技术人员。
为方便起见,本书假设开发人员和运维人员之间有明确的区分。这种区分可以更好理解各自的能力、选择和责任。举例来说,对开发人员来说,改变审计记录(log)或实施一个不同的身份验证系统是“容易”的,而这对运维人员来说就不是一件容易的事情。同样,对运维人员来说,维护日志记录完整、保护电脑安全是“容易”的。如本书中所写,业界流行一种“敏捷运维”(devops)模型。因此,针对开发人员和运维人员的课程会有些调整。同样为了方便起见,本书还假定安全专家与开发人员、运维人员的角色互不交叉。
显然,这就意味着,本书中同样的内容可能给不同人群带来不同的课程。以下具体介绍本书可为每一类读者提供的价值。
软件开发及软件测试人员
软件开发人员(日常工作主要是软件开发)包括软件工程师、质量保障及项目管理人员。如果你是这类人员,那么本书将帮助你在构建软件过程的设计初期发现并解决问题,帮助你交付满足客户需求的更加安全的软件。你将学到简单、有效且有趣的威胁建模方法,以及应用该方法从另一个角度构建软件模型和发现威胁。你将学到如何根据软件开发过程中存在的漏洞发现威胁,如何利用威胁使你的业务需求变得更加清晰。你将学到认证技术、密码学及可用性知识,在这个过程中你将发现攻击和防御之间的对抗有着悠久的历史,你能了解到本书推荐的威胁建模方法是如何发展的。你还将学到如何将威胁建模方法应用到软件开发过程中。
系统架构、运维和管理人员
此类人员的日常工作是集成各个软件组件,搭建有效的业务系统并维持其正常运行,通过这本书将学到在系统设计、软件组件选择、准备部署的过程中如何发现和解决威胁。本书可帮助交付满足商业和客户需求的更加安全的系统。你将学到简单、有效而有趣的威胁建模方法,以及应用该方法从另一个角度描述正在构建或者已经构建的系统。通过本书将学到如何发现系统中存在的安全和隐私威胁,如何应用该方法在操作流程中处理此类威胁,如何对你所面临的威胁权衡选择最优的安全措施,以及如何确保彻底解决这些威胁。通过本书将学到针对不同技术领域,如网络和云系统的威胁,以及针对账户的威胁,了解这些威胁对系统运维是十分重要的。书中还将涉及可用性问题,该内容或许可以让你改变你所在组织机构或者客户对安全的态度。你将学到加密的相关知识,并可以用其来保护系统。这些在书中都会详细介绍。
安全专业人员
如果你从事安全工作,本书主要为你提供两方面内容:首先,威胁建模的结构化方法可大大提高你的工作效率,你将学到为何很多威胁建模过程中最显而易见的部分,其实并没有你想象的那么明显和正确;其次,你会学到如何将安全引入软件开发、操作和发布流程中。
从我个人的经验来说,即使你是安全专业人员,这本书也会给你带来帮助,让你更好地威胁建模。当我在撰写案例研究的附录时,我发现我要查阅附录B及本书有关安全需求的章节,发现并不是只要考虑软件模型就能发现威胁。
写给信息安全领域的同僚
坦诚地说,这本书不是关于如何设计抽象意义上完美的软件。由于大多数商业或者组织机构使用的软件存在威胁,这是一本实用的书。目前,统治着世界的软件均存在着威胁,我希望通过做出更好的权衡使得这些软件更加安全。这涉及很多方面,其中两个重要方面是:让各位同仁在其专长的技术领域内保持一致安全策略,以及易于使用威胁建模方法。
本书的观点源于我作为系统管理员部署安全技术以及汇总人们遇到的问题时的工作经历,我作为创业企业运营人员如何使安全产品更好满足市场需求的经历,以及我在微软公司威胁建模的工作责任。威胁建模是微软公司软件开发生命周期的一部分工作。在第三个经历中,我和微软公司及其合伙人、客户等几千人讨论我们提出的方法,这些人中包括新入职的开发人员、在安全领域有着几十年工作经验的人、首席安全官、微软公司可信计算团队咨询委员会成员等。我了解到,关于行得通有太多的观点,而对于行不通的观点则寥寥无几。本书旨在让安全领域的同仁相信,开发和运维的过程改进可以帮助我们交付更加安全的软件。一些安全专家可能对此观点持怀疑态度,那么他们应该着重看第二部分、第四部分和第五部分。
如何使用本书
读者应该从书的开头开始阅读。即便你已经知道如何威胁建模,从头开始阅读也是最佳方式,因为书的开头为本书勾勒出了一个整体框架,可帮助你更好地理解后面的内容。
四步框架
本书提出这样一个观点:威胁建模并不能一步完成,而分几步完成,其中每一步完成一个子目标,为了实现这些子目标你需要回答以下问题。
1.你在构建什么?
2.一旦开始构建,哪些可能出错?
3.对于出错的部分该如何处理?
4.你做的分析工作完整吗?
框架的每一步所用的方法都可视为乐高(Lego)积木。在搭积木时,你可以将一块积木与另外一块安装组合起来。在第1章中,你将看到利用数据流图模拟你正在构建的软件,利用STRIDE帮助你思考哪里出错以及如何处理,以及利用核查表帮助你检查是否已经做了完整的分析工作。第2章中,你将看到数据流图是最适当的思考方式。不同的数据流图就像不同的构建模块,可帮助你对构建的软件或系统进行建模。第3章将深入了解STRIDE(一种威胁模型)。在第4章中,你将学习如何使用攻击树替代STRIDE,抛除相似因素之外的所有因素。STRIDE和攻击树是两种不同的构建模块,可以帮助你在构建新的技术时发现出错的地方。
并不是每种方法都能和其他方法结合使用,比如,要让金属积木Erector和木制的Lincoln积木粘合需要强力胶水。将不同威胁建模方法结合使用就会出现一些令人困惑的建议。例如,思考恐怖分子会如何袭击你的资产,不一定会产生很多可操作的问题。而且,即便是连接那些容易契合的模块,做出来的效果可能非常好,也可能非常差。
因此,假设将其当成一个完整的框架,那么构建模块是什么呢?图I-1形象地展示了四步框架。这些步骤是:
1.?对你正在构建、部署或修改的软件系统进行建模。
2.?利用本书第二部分的模型和方法发现威胁。
3.?利用本书第三部分的方法解决威胁。
4.?验证上述工作的完备性和有效性(同样在第三部分中)。
这个框架是与软件开发、操作部署相匹配的。实验证明这是一种结构化的威胁建模方法。不用替换整个框架即可更容易地实践。本书几乎所有内容都是经过精挑细选的,因为它们都是基于四步框架的。
本书大致按照这个框架组织章节:
第一部分“入门指南”介绍入门知识。书的开篇(尤其是第1章)是专门为没有什么安全专业知识的人设计的。之后的内容基于在这部分的知识(或者结合自己的经验)设计。在这部分中你将了解威胁建模,以及为新手推荐的方法。你也可以学到软件建模的不同方法,以及为何从这里开始好于其他选择,比如从“攻击者”和“资产”开始。
第二部分“发现威胁”介绍发现威胁方面的知识。这部分内容描述了许多用于发现威胁的技术和工具。这部分内容综述和分析了人们对信息技术进行威胁建模的不同方法,可以让你发现不同技术的利弊。本书已经将这些技术分组,让你既可以从头开始读到尾,也可以挑选特定内容进行阅读。
第三部分“管理和解决威胁”介绍管理和解决威胁方面的内容。这部分内容包括如何处理威胁、管理威胁和用于定位威胁的策略和方法,以及如何做出必要的风险权衡。另外还涉及验证你的威胁确实已经得到解决以及帮助你进行威胁建模的工具。
第四部分“科技和棘手领域的威胁建模”涉及在特定技术领域及其他相关领域威胁建模,在这些领域已经有很多威胁建模及分析实践。这一部分包括网络及云、账户和身份、密码学及尝试自己开展安全需求分析的“需求手册”。
第五部分“再上一层楼”介绍了提升威胁建模能力。这部分内容针对经验丰富的威胁建模人员、安全专家、流程设计师——他们需要考虑如何为特定的组织机构定制威胁建模流程。
附录包括可帮助你快速应用所学的相关信息。其中包括“威胁建模是什么”、“我们的资产是什么”等常见问题解答,以及能帮助你发现威胁的威胁树、攻击者及攻击者角色列表,还有第1章中提到的权限提升游戏的细节,最后是一组威胁建模的详细案例。附录后面附有术语表、参考文献等。
网址:本书的网站是www.threatmodelingbook.com,网站上包含书中提到的一些图表的PDF格式版本,以及勘误表。
本书不包括什么
如今,很多信息安全书籍希望教你如何入侵。他们的目的是告诉你该防范哪些攻击,假设如果你了解了这些攻击,你便可以开始构建你的防御系统了。不过,本书和市面上的大部分书籍不同,因为即便市面上有几百万这样的书,仍旧有很多脆弱的系统被构建和部署。另外,针对各类攻击有各种各样经过斟酌的防御方法。了解如何执行攻击或许是有用的,但更重要的是知道什么时候在哪里会有攻击,以及如何有效地防范攻击。这就是本书编写目的所在。
本书不针对某一特定技术、平台或应用程序编程接口(API)。平台及API影响可能会提供你能使用的安全特征或可以消除一些威胁,但与平台相关联的威胁和消除威胁措施会随着版本不同而改变。本书旨在成为你书架上有用的参考书,比任何技术发布周期都要长久。
当然,本书并不是造就威胁建模大师的灵丹妙药,而是帮助理解你需要知道的信息。所谓熟能生巧,在问题处理过程中不断实践和反馈,你终将成为大师。
威胁建模新课程
经验丰富的安全专家在工作过程中都已经开发了适合自己的威胁建模方法。如果在威胁建模方面你已经有多年的经验,本书将为你提供其他可用的方法。本书还可让你全面地了解一系列结构化的威胁建模方法,以及它们是如何相互关联的。最后,还有一些较深的课程内容值得你们关注。
不止一种威胁建模方法
如果你问一名程序员“哪种编程语言最合适一个新的项目?”你可能会得到很多需要澄清的问题,因为没有哪一种是理想的编程语言。当然,编程语言在处理特定类型任务时都有其优点和缺点。例如,用Perl语言编写文本处理代码比汇编语言(assembler)要容易。Python语言比汇编语言更容易阅读和维护。同样,也有或好或坏的方法来进行威胁建模,这很大程度上取决于当时的实际情况,比如参与人员和人员技能等。
所以,你可以把威胁建模看作编程。编程有很多语言、编程范式(比如敏捷模式或瀑布模式)、编程实践(结对编程或频繁部署),威胁建模也是如此。以前威胁建模的书主要涉及威胁建模方法。本书帮助你了解“不止一种实现方式”,不仅仅是Perl语言适用于威胁建模。
找到威胁的方法就是正确的方法
威胁建模正确的方法就是能够让项目组找到比其他技术更多“好的威胁”(“好的威胁”是可以激发必须去做的工作的威胁)。一个项目组如此,几千个项目组亦如此。而且适用于所有层面的资源,比如时间、专业知识、工具。正确的技术能让一个项目组发现和解决威胁(并且增强信心,正如他们已经在做的)。
很多人会告诉你他们知道“一种最正确的方法”(但这是在威胁建模以外的领域)。应避免这场争论,找到适合自己的方法才是最有效的。
威胁建模犹如版本控制
威胁建模有时被认为是一种专业技能,只有一些人才能做好,这一想法通常阻碍我们。因为,比起专业技能,威胁建模更像是版本控制。这当然不是在诋毁或者轻视威胁建模,而是所有专业的开发者在构建任何复杂度的软件时都需要某种形式的版本控制系统。希望威胁建模能成为如版本控制系统一样的基础组件。
你希望所有专业软件开发者都知道一两种版本控制系统的基本知识,同样,很多系统管理员会用版本控制系统来管理配置文件。很多组织机构只靠一个简单的版本控制方法来应付,从来没聘请专家。如果你在一家大型公司工作,就会知道有全职人员管理构造树(build tree),威胁建模和这个情况类似。通过学习本书,可以假设负责软件和运维的专业人员已经有一些基本的威胁建模经验。
威胁建模也像拉小提琴
当你刚开始学习拉小提琴时,你不会一开始就练习拉那些最美的小提琴曲,首先你需要练习音阶、一些简单的曲子,然后循序渐进到更复杂的音乐。
同样道理,当你开始学习威胁建模时,你得通过练习学习技巧,学习过程中你会遇到很多挑战或挫败感。你要知道,威胁建模是一种技能,你可以在很多方面应用,当然也就需要时间来培养能力了。熟能生巧,如果你想一夜之间就变成专家,那么你肯定会失望的。同样,若是你几年才进行一次威胁建模,那么你就会生疏,这时就需要时间来重新锻炼自己所需的能力。
技巧与技能
继续使用拉小提琴这个例子,大多数有才华的小提琴家不会只练习一首曲子,而是有一整套技能,是与自己领域相关的一系列知识。
当你开始威胁建模时,你需要锻炼技巧和技能——你可以着手一系列威胁范例,想象新的系统可能受到怎样的攻击。攻击列表或者攻击库可以部分代替专家所知的威胁的心理技能,了解相似产品的安全问题也可以帮助你培养威胁技能。长此以往,这些都能帮助你思考新的、不同的威胁。
“像攻击者那样思考”是有害的
很多威胁建模书籍劝诫人们“像攻击者那样思考”。对大多数人来说,这就像把自己想象成专业厨师一样难。即使你在家里是做饭好手,但是要当餐厅的主厨会遇到更复杂问题,比如,一家有78个座位的餐厅,每个座位接待两轮客人的话,每天要买多少只鸡?因此,像攻击者那样思考无法帮助大部分人进行威胁建模。
更糟糕的是,结果可能是盲目想象攻击者会怎么想、怎么做,以致你得到了错误的威胁。而要发现威胁,你无须着重攻击者,不过,拟人化或许可以帮你找到解决它们的方法。
攻击、防御与需求之间的相互关系
威胁建模就是为了建立更加安全的软件。当你在使用软件模型及威胁模型来寻找潜在问题时,你会发现一些威胁很难或不可能解决,这时你需要调整需求。这种相互关系很少有人讨论,而这对有效的威胁建模很重要。
有时要防范管理员的问题,有时要考虑你的客户愿意承受什么。“9·11”事件发生后,美国政府多次严肃考虑在民航飞机上禁止带电脑(据报道,电池和大规模炸药在X光机上显示是一样的)。于是,购买昂贵机票的商务舱乘客开始反抗,他们可是让航空公司运转的“金主”。于是政府只好采取其他措施,本书将就这些措施的效力进行评判。
这种相互作用的结果导致一些威胁不能有效缓解。这对很多安全专家来说是痛苦的。(不过,如《黑衣人》中的台词:“生活本来就充满痛苦,殿下。不这么对您说的人一定是在推销什么。”)当你发现违背你的需求的威胁又不能缓解时,基本上可以调整你的需求了。有时,要么操作上缓解威胁,要么顺从使用该系统的人。
基于此,是时候开始潜心威胁建模了!