威胁建模：设计和交付更安全的软件[图书]

2.3.1　关注资产 27
2.3.2　关注攻击者 29
2.3.3　关注软件 30
2.4　软件模型 31
2.4.1　图表类型 32
2.4.2　数据流图 32
2.4.3　信任边界 36
2.4.4　图表中包含的内容 37
2.4.5　复杂图 38
2.4.6　图的标签 38
2.4.7　图中的颜色 39
2.4.8　入口点 39
2.4.9　表验证 39
2.5　小结 41
第二部分　发现威胁
第3章　STRIDE方法 45
3.1　理解STRIDE方法及其为何有用 45
3.2　假冒威胁 47
3.2.1　在同一台机器上假冒一个进程或文件 48
3.2.2　假冒一台机器 48
3.2.3　人员假冒 48
3.3　篡改威胁 49
3.3.1　篡改文件 49
3.3.2　篡改内存 49
3.3.3　篡改网络 50
3.4　否认威胁 50
3.4.1　攻击日志 50
3.4.2　否认一种行为 51
3.5　信息泄露威胁 51
3.5.1　进程信息泄露 52
3.5.2　数据存储信息泄露 52
3.5.3　数据流中的信息泄露 52
3.6　拒绝服务威胁 53
3.7　权限提升威胁 53
3.7.1　通过崩溃进程提升权限 53
3.7.2　通过授权失效提升权限 54
3.8　扩展示例：针对Acme-DB的STRIDE威胁 54
3.9　STRIDE变种 56
3.9.1　STRIDE-per-Element 56
3.9.2　STRIDE-per-Interaction 58
3.9.3　DESIST方法 61
3.10　准出条件 61
3.11　小结 62
第4章　攻击树 63
4.1　使用攻击树 63
4.1.1　利用攻击树寻找威胁 64
4.1.2　创建新的攻击树 64
4.2　展现一个攻击树 66
4.2.1　人类可识别的表现形式 66
4.2.2　结构化的表示法 70
4.3　攻击树示例 70
4.4　真实的攻击树 71
4.4.1　诈骗攻击树 71
4.4.2　选举操作评估威胁树 73
4.4.3　思维导图 73
4.5　有关攻击树的观点 75
4.6　小结 75
第5章　攻击库 76
5.1　攻击库属性 76
5.1.1　攻击库及检查列表 77
5.1.2　攻击库与文档检查 78
5.2　CAPEC 78
5.2.1　准出条件 80
5.2.2　有关CAPEC的观点 81
5.3　OWASP前十名 81
5.4　小结 82
第6章　隐私工具 83
6.1　Solove的隐私分类 84
6.2　互联网协议的隐私考虑 85
6.3　隐私影响评估 86
6.4　Nymity Slider和隐私棘轮 86
6.5　语境完整性 88
6.5.1　语境完整性启发式决策 88
6.5.2　扩大的语境完整性启发法 89
6.5.3　有关语境完整性的观点 89
6.6　LINDDUN助记符 90
6.7　小结 91
第三部分　管理和解决威胁
第7章　处理和管理威胁 95
7.1　开始威胁建模项目 95
7.1.1　何时开始威胁建模 95
7.1.2　从哪里开始和（计划）在哪结束 97
7.1.3　从哪里入手 97
7.2　深入分析减缓方法 99
7.2.1　减缓顺序 99
7.2.2　下棋 100
7.2.3　目标优选 100
7.2.4　逃避熊的袭击 100
7.3　利用表格和列表跟踪 101
7.3.1　追踪威胁 101
7.3.2　建立假设 103
7.3.3　外部安全注解 103
7.4　威胁建模的特定场景元素 105
7.4.1　客户/供应商信任边界 105
7.4.2　新技术 105
7.4.3　对API威胁建模 107
7.5　小结 108
第8章　防御策略及技术 109
8.1　减缓威胁的策略及技术 109
8.1.1　认证：减缓欺骗威胁 110
8.1.2　完整性：减缓篡改威胁 111
8.1.3　不可否认性：减缓否认威胁 113
8.1.4　机密性：减缓信息暴露威胁 115
8.1.5　可用性：减缓拒绝服务威胁 117
8.1.6　授权：减缓权限提升威胁 118
8.1.7　策略和技术陷阱 119
8.2　利用模式解决威胁 120
8.2.1　标准部署 120
8.2.2　解决CAPEC威胁 120
8.3　减缓隐私威胁 120
8.3.1　最小化 120
8.3.2　加密 121
8.3.3　遵从性和政策 123
8.4　小结 123
第9章　解决威胁时的权衡 125
9.1　风险管理的经典策略 125
9.1.1　回避风险 126
9.1.2　解决风险 126
9.1.3　接受风险 126
9.1.4　转移风险 126
9.1.5　忽略风险 127
9.2　为风险管理选择减缓措施 127
9.2.1　改变设计 127
9.2.2　应用标准减缓技术 130
9.2.3　设计定制的减缓措施 132
9.2.4　模糊编码不是减缓威胁措施 132
9.3　针对特定威胁的优先级方法 133
9.3.1　简单方法 133
9.3.2　利用错误栏威胁排序 134
9.3.3　成本估算方法 135
9.4　通过接受风险来减缓威胁 138
9.5　减缓策略中的军备竞赛 139
9.6　小结 139
第10章　验证威胁是否已解决 141
10.1　测试威胁减缓 142
10.1.1　测试过程完整性 142
10.1.2　如何测试减缓 142
10.1.3　渗透测试 143
10.2　检查你获取的代码 143
10.2.1　构建软件模型 144
10.2.2　利用软件模型 145
10.3　问答式威胁建模 145
10.3.1　模型/现实一致性 146
10.3.2　任务和过程的完成 146
10.3.3　漏洞检查 146
10.4　解决威胁的过程各方面 147
10.4.1　威胁建模授权测试；测试授权威胁建模 147
10.4.2　验证/转换 147
10.4.3　操作过程中记录假设 148
10.5　表格与列表 148
10.6　小结 150
第11章　威胁建模工具 151
11.1　通用工具 151
11.1.1　白板 151
11.1.2　办公套件 152
11.1.3　漏洞跟踪系统 152
11.2　开放源代码工具 153
11.2.1　TRIKE 153
11.2.2　SeaMonster 153
11.2.3　权限提升纸牌游戏 153
11.3　商业工具 154
11.3.1　Threat Modeler 155
11.3.2　Corporate Threat Modeller 155
11.3.3　SecurITree 155
11.3.4　Little-JIL 155
11.3.5　微软的SDL威胁建模工具 155
11.4　尚不存在的工具 158
11.5　小结 159
第四部分　科技和棘手
领域的威胁建模
第12章　需求手册 163
12.1　为何需要“手册” 163
12.2　需求、威胁、减缓威胁之间相互作用 164
12.3　商业需求 165
12.3.1　优于竞争 165
12.3.2　产业需求 165
12.3.3　场景驱动的需求 166
12.4　防御/检测/响应需求框架 166
12.4.1　防御 166
12.4.2　检测 168
12.4.3　响应 169
12.5　人员/过程/技术作为需求的框架 170
12.5.1　人员 170
12.5.2　过程 170
12.5.3　技术 170
12.6　开发需求与采购需求 171
12.7　合规性驱动的需求 171
12.7.1　云服务安全联盟 171
12.7.2　NISTPublication200 172
12.7.3　支付卡行业数据安全标准 173
12.8　隐私需求 173
12.8.1　公平信息处理条例 173
12.8.2　从设计着手保护隐私 174
12.8.3　身份识别七法则 174
12.8.4　微软开发隐私标准 175
12.9　STRIDE需求 175
12.9.1　认证 176
12.9.2　完整性 177
12.9.3　不可否认性 178
12.9.4　机密性 178
12.9.5　可用性 178
12.9.6　授权 178
12.10　非需求 179
12.10.1　操作非需求 180
12.10.2　警告和提示 180
12.10.3　微软的“十个不变法则” 180
12.11　小结 181
第13章　网络与云威胁 182
13.1　网络威胁 182
13.1.1　网站威胁 182
13.1.2　网络浏览器和插件威胁 183
13.2　云租户威胁 184
13.2.1　内部威胁 184
13.2.2　合租威胁 185
13.2.3　合规性威胁 185
13.2.4　法律威胁 185
13.2.5　电子取证响应威胁 186
13.2.6　各种各样的威胁 186
13.3　云供应者威胁 186
13.3.1　直接来自租户的威胁 186
13.3.2　租户行为导致的威胁 187
13.4　移动威胁 187
13.5　小结 188
第14章　账户与身份识别 189
14.1　账户生命周期 190
14.1.1　创建账户 190
14.1.2　账户维护 192
14.1.3　账户终止 192
14.1.4　账户生命周期检查列表 193
14.2　认证 193
14.2.1　登录 194
14.2.2　登录失败 195
14.2.3　对于“你所拥有的”威胁 197
14.2.4　对“你是谁”的威胁 197
14.2.5　对“你所知道的”威胁 199
14.2.6　认证检查列表 202
14.3　账户恢复 202
14.3.1　时间和账户恢复 203
14.3.2　账户恢复邮件 204
14.3.3　基于知识的认证 204
14.3.4　社会认证 207
14.3.5　账户恢复的攻击者驱动分析 208
14.3.6　多渠道认证 209
14.3.7　账户恢复检查列表 209
14.4　姓名、ID和SSN 210
14.4.1　姓名 210
14.4.2　身份证明文件 212
14.4.3　社保号及其他国家身份识别号 213
14.4.4　身份盗用 215
14.4.5　姓名、ID及SSN检查列表 215
14.5　小结 216
第15章　人类因素与可用性 217
15.1　人的模型 218
15.1.1　应用人的行为模型 218
15.1.2　人的模型认知科学 220
15.1.3　人的启发式模型 223
15.2　软件情景模型 225
15.2.1　对软件进行建模 225
15.2.2　软件模型的图表 227
15.2.3　对电子社会工程攻击的建模 229
15.3　威胁引出技术 229
15.3.1　集体研讨 230
15.3.2　威胁建模的仪式方法 230
15.3.3　仪式分析启发式 230
15.3.4　将可用性融于四步框架 233
15.4　解决人类因素的工具和技术 233
15.4.1　抑制人类因素作用的谬见 233
15.4.2　良好的设计决策模型 234
15.4.3　良好学习环境的设计模型 236
15.5　用户界面工具和技术 237
15.5.1　配置 237
15.5.2　显式警示 238
15.5.3　吸引注意力的模型 239
15.6　测试人类因素 240
15.6.1　良好和恶劣的情景 240
15.6.2　生态有效性 241
15.7　有关可用性与仪式的观点 242
15.8　小结 243
第16章　密码系统威胁 244
16.1　密码原语 245
16.1.1　基本原语 245
16.1.2　隐私原语 248
16.1.3　现代加密原语 248
16.2　典型威胁角色 250
16.3　针对密码系统的攻击 251
16.4　用密码创建 253
16.4.1　做决定 253
16.4.2　准备升级 254
16.4.3　密钥管理 254
16.4.4　解密之前验证 255
16.5　关于密码需要记住的事情 255
16.5.1　使用专业人士设计的密码系统 255
16.5.2　用专业人士创建或测试的密码代码 255
16.5.3　密码不是安全魔尘 256
16.5.4　假设都会公开 256
16.5.5　你仍需要管理密钥 256
16.6　加密系统：Kerckhoffs及其原则 256
16.7　小结 257
第五部分　更上一层楼
第17章　将威胁建模带到你的组织机构中 261
17.1　如何引入威胁建模 262
17.1.1　说服个体贡献者 263
17.1.2　说服管理层 263
17.2　谁做什么 264
17.2.1　威胁建模与项目管理 264
17.2.2　先决条件 265
17.2.3　可交付物 265
17.2.4　个体角色及责任 266
17.2.5　小组交互 267
17.2.6　威胁建模团队的多样化 270
17.3　在开发生命周期中的威胁建模 270
17.3.1　开发过程问题 270
17.3.2　组织问题 275
17.3.3　为你的组织机构定制一个过程 278
17.4　克服对威胁建模的反对声音 279
17.4.1　对资源的反对声音 279
17.4.2　价值反对声音 280
17.4.3　对计划的反对声音 281
17.5　小结 281
第18章　试验方法 283
18.1　查看缝隙 283
18.2　操作威胁模型 285
18.2.1　FlipIT 285
18.2.2　杀戮链 285
18.3　“宽街”分类法 288
18.4　博弈机器学习 293
18.5　对一家企业进行威胁建模 293
18.6　针对威胁建模方法的威胁 294
18.6.1　危险可交付物 294
18.6.2　危险方法 295
18.7　如何实验 297
18.7.1　明确问题 297
18.7.2　寻找要衡量的方面，进行衡量 297
18.7.3　研究你的结果 298
18.8　小结 298
第19章　成功的设计 299
19.1　理解流程 299
19.1.1　流程与威胁建模 300
19.1.2　妨碍人们 302
19.1.3　注意认知负荷 302
19.1.4　避免创造者失明 302
19.1.5　资产与攻击者 303
19.2　了解参与者 303
19.3　边界对象 304
19.4　“最好”是“好”的敌人 305
19.5　展望未来 306
19.5.1　“威胁模型改变了” 306
19.5.2　有关艺术性 307
19.6　小结 308
附录A　有用的工具 309
附录B　威胁树 315
附录C　攻击者列表 349
附录D　权限提升纸牌游戏 365
附录E　案例研究 372
术语表 388

.　　早期发现安全缺陷
　　想象你在建造一座房子，对安全结果的影响你越早决定越重要。由木制墙及大量落地窗构建的房子会比砖石及少量窗户的房子的潜在危险更大，因此要根据房子建在哪里等因素选择一个合理的方案。如果在决定之后再更改，成本通常会很高。当然，作为补救，你可以在窗子上加防盗护栏，但是，若能最初就有一个更合理的设计不是更好吗？这种权衡也可以用于技术当中。威胁建模可以帮你发现设计上的问题，甚至在你一行代码都没写的时候即可发现问题，而此时也是发现这类问题的最佳时机。
　　理解安全需求
　　好的威胁模型能帮助你回答“那的确是实际的安全需求吗？”举例来说，系统是否需要保护设备免受他人非法拥有？苹果公司在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光机上显示是一样的）。于是，购买昂贵机票的商务舱乘客开始反抗，他们可是让航空公司运转的“金主”。于是政府只好采取其他措施，本书将就这些措施的效力进行评判。
　　这种相互作用的结果导致一些威胁不能有效缓解。这对很多安全专家来说是痛苦的。（不过，如《黑衣人》中的台词：“生活本来就充满痛苦，殿下。不这么对您说的人一定是在推销什么。”）当你发现违背你的需求的威胁又不能缓解时，基本上可以调整你的需求了。有时，要么操作上缓解威胁，要么顺从使用该系统的人。
　　基于此，是时候开始潜心威胁建模了！