●推荐序一xvii
推荐序二x
对本书的赞誉x
序一i
序二xxv
前言xxvii
部分入门资料
章安全性与可靠性的交集3
1．1从密码和电钻谈起3
1．2可靠性与安全性：设计注意事项4
1．3机密性、完整性、可用性5
1．3．1机密性5
1．3．2完整性5
1．3．3可用性6
1．4可靠性与安全性：共性6
1．4．1隐形6
1．4．2评估7
1．4．3简洁性7
1．4．4演变7
1．4．5弹性8
1．4．6从设计到生产9
1．4．7调查系统和日志9
1．4．8危机响应9
1．4．9恢复10
1．5小结10
第2章了解攻击者11
2．1攻击者动机12
2．2攻击者画像13
2．2．1业余爱好者13
2．2．2漏洞研究人员13
2．2．3黑客活动家14
2．2．4犯罪分子14
2．2．5自动化和人工智能15
2．2．6内部人员15
2．3攻击者方19
2．3．1威胁情报19
2．3．2网络杀伤链20
2．3．3TTP20
2．4风险评估注意事项21
2．5小结21
第二部分设计系统
第3章示例分析：安全代理25
3．1生产环境中的安全代理25
3．2Google工具代理27
3．3小结29
第4章设计中的权衡30
4．1设计目标和要求31
4．1．1特性需求31
4．1．2非功能性需求31
4．1．3功能与涌现特性32
4．1．4案例：Google的设计文档33
4．2需求平衡34
4．3处理紧张局势和统一目标37
4．3．1案例：微服务和Google Web应用程序框架37
4．3．2统一涌现特性的需求39
4．4初始速度和持续速度39
4．5小结41
第5章小特权设计42
5．1概念和术语43
5．1．1小特权43
5．1．2零信任网络43
5．1．3零接触43
5．2基于风险的访问分类43
5．3佳实践44
5．3．1API功能小化45
5．3．2Breakglass机制47
5．3．3审计47
5．3．4测试和小特权49
5．3．5诊断被拒绝的访问50
5．3．6优雅失败和Breakglass机制51
5．4工作案例：配置分发51
5．4．1基于OpenSSH实现的IX API52
5．4．2软件更新API52
5．4．3自定义OpenSSHForceCommand53
5．4．4自定义HTTP接收器（边车）53
5．4．5自定义HTTP接收器（内置）53
5．4．6权衡取舍53
5．5一种用于认证和授权决策的策略框架54
5．5．1使用不错授权控件55
5．5．2投入广泛使用的授权框架55
5．5．3避免潜在的陷阱56
5．6不错控制56
5．6．1MP6
5．6．23F7
5．6．3业务依据58
5．临时访问59
5．6．5代理59
5．7权衡和冲突59
5．7．1增加了安全复杂性60
5．7．2对合作商及公司文化的影响60
5．7．3影响安全性的质量数据和系统60
5．7．4对用户工作效率的影响60
5．7．5对开发复杂性的影响60
5．8小结61
第6章面向易理解性的设计62
6．1为什么易理解性很重要62
6．1．1系统不变量63
6．1．2分析不变量
6．1．3心智模型65
6．2设计易理解的系统65
6．2．1复杂性与易理解性65
6．2．2分解复杂性66
6．2．3集中负责安全性和可靠性需求67
6．3系统架构67
6．3．1易于理解的接口规范68
6．3．2易于理解的身份、认证和访问控制69
6．3．3安全边界74
软件设计78
．1使用应用程序框架满足服务需求78
．2理解复杂的数据流79
．3考虑API的可用性81
6．5小结83
第7章适应变化的设计84
7．1安全变更的类型85
7．2变更中的设计85
7．3让发布更容易的架构决策86
7．3．1让依赖项保持新并频繁重建86
7．3．2用自动化测试让发布更频繁86
7．3．3使用容器87
7．3．4使用微服务87
7．4不同的变更：不同的速度与不同的时间线89
7．4．1短期变更：零日漏洞90
7．4．2中期变更：改善安全态势92
7．4．3长期变更：外部需求94
7．5难点：计划调整96
7．6不断扩大的范围：心脏滴血漏洞97
7．7小结98
第8章弹性设计99
8．1弹性设计原则100
8．2纵深防御100
8．2．1特洛伊木马100
8．2．2Google App Engine分析102
8．3控制降级104
8．3．1区分故障成本105
8．3．2部署响应机制107
8．3．3负责任的自动化109
8．4控制爆炸半径111
8．4．1角色分离112
8．4．2位置分离113
8．4．3时间分离115
8．5故障域和冗余115
8．5．1故障域116
8．5．2组件类型117
8．5．3控制冗余119
8．6持续验证120
8．6．1验证关键区域121
8．6．2验证实践122
8．7实践建议：着手点124
8．8小结125
第9章面向恢复性的设计127
9．1要恢复什么128
9．1．1随机错误128
9．1．2意外错误128
9．1．3软件错误128
9．1．4恶意行为129
9．2恢复机制的设计原则129
9．2．1面向快速恢复的设计（受政策监督）129
9．2．2对外部时间观念的依赖132
9．2．3回滚所代表的安全性和可靠性间的权衡133
9．2．4使用显式吊销机制139
9．2．5了解精确到字节的预期状态142
9．2．6面向测试和持续验证的设计145
9．3紧急访问146
9．3．1访问控制147
9．3．2通信148
9．3．3响应人员的习惯148
9．4预期外的收益149
9．5小结149
0章缓解拒绝服务攻击150
10．1攻守双方的策略150
10．1．1攻方的策略151
10．1．2守方的策略152
10．2面向防御的设计152
10．2．1具有防御能力的架构152
10．2．2使服务具备防护能力154
10．3缓解攻击154
10．3．1监控与告警154
10．3．2优雅降级155
10．3．3DoS防护系统155
10．3．4有策略的响应156
10．4应对源于服务本身的“攻击”157
10．4．1用户行为157
10．4．2客户端重试行为158
10．5小结159
第三部分实现系统
1章案例分析：设计、实现和维护一个受信任的公共CA163
11．1受信任的公共CA的背景163
11．2为什么需要受信任的公共CA1
11．3自建还是购买CA165
11．4设计、开发和维护过程中的考虑165
11．4．1选择编程语言166
11．4．2复杂与简明166
11．4．3保护第三方和开源组件167
11．4．4测试167
11．4．5CA密钥材料的弹性168
11．4．6数据验证168
11．5小结169
2章编写代码170
12．1框架级安全性和可靠性保证措施171
12．1．1使用框架的好处．172
12．1．2案例：用于创建RPC后端的框架172
12．2常见安全漏洞176
12．2．1SQL注入漏洞：TrustedSqlString177
12．2．2预防XSS漏洞：SafeHtml178
12．3评估和构建框架的经验179
12．3．1用于常见任务的简单、安全、可靠的库180
12．3．2部署策略181
12．4简洁性有助于提升代码的安全性和可靠性182
12．4．1避免多层嵌套182
12．4．2消除YAGNI类代码183
12．4．3偿还技术债务184
12．4．4重构184
12．5默认安全性和可靠性185
12．5．1选择合适的工具185
12．5．2使用强类型186
12．5．3检查代码．188
12．6小结189
3章代码测试190
13．1单元测试190
13．1．1编写有效的单元测试191
13．1．2编写单元测试的时机191
13．1．3单元测试对代码的影响192
13．2集成测试193
13．3动态程序分析194
13．4模糊测试197
13．4．1模糊引擎的工作原理197
13．4．2编写有效的模糊测试驱动程序200
13．4．3示例fuzzer201
13．4．4持续模糊测试204
13．5静态程序分析205
13．5．1自动代码检查工具205
13．5．2如何将静态分析集成至开发工作流中209
13．5．3抽象解释211
13．5．4形式化方法213
13．6小结213
4章部署代码214
14．1概念和术语214
14．2威胁建模216
14．3佳实践217
14．3．1强制做代码审查217
14．3．2依赖自动化218
14．3．3验证工件，而不仅仅是人218
14．3．4将配置视为代码．219
14．4基于威胁建模做安全加固220
14．5不错缓解策略222
14．5．1二进制文件来源222
14．5．2基于来源的部署策略224
14．5．3可验证的构建225
14．5．4部署阻塞点230
14．5．5部署后验证231
14．6实用建议232
14．6．1一步步来232
14．6．2提供可操作的错误消息233
14．6．3确保来源信息明确233
14．创建明确的策略233
14．6．5引入Breakglass机制234
14．7重温基于威胁建模部署安全措施234
14．8小结234
5章调查系统235
15．1从调试到调查236
15．1．1案例：临时文件236
15．1．2调试技巧237
15．1．3当陷入困境时该怎么办243
15．1．4协同调试：一种教学方法246
15．1．5安全调查与系统调试间的差异246
15．2收集恰当、有用的日志247
15．2．1将日志设计为不可变的248
15．2．2考虑隐私要素249
15．2．3确定要保留哪些安全相关的日志249
15．2．4日志记录成本252
15．3可靠、安全的调试访问253
15．3．1可靠性253
15．3．2安全性253
15．4小结254
第四部分维护系统
6章防灾规划257
16．1“灾难”的定义257
16．2动态灾难响应策略258
16．3灾难风险分析259
1建立事件响应团队259
1．1确定团队成员和角色260
1．2制订团队章程261
1．3建立严重性和优先级模型262
1．4确定与IR团队合作的运营参数262
1．5制订响应计划263
1．6创建详细的行动手册2
1．7确保访问和更新机制就位2
16．5在事件发生前预先安排系统和人员2
16．5．1配置系统265
16．5．2培训265
16．5．3流程和程序266
16．6测试系统和响应计划266
16．6．1审计自动化系统267
16．6．2开展非侵入式桌面演练．267
16．6．3在生产环境中测试响应268
16．红队测试270
16．6．5评估响应270
16．7Google的案例271
16．7．1具有影响的测试271
16．7．2DiRT演习测试紧急访问271
16．7．3行业级漏洞271
16．8小结272
7章危机管理273
17．1是否存在危机274
17．1．1事件分诊274
17．1．2入侵与缺陷275
17．2指挥事件276
17．2．1步：不要惊慌276
17．2．2开展响应277
17．2．3组建自己的事件团队277
17．2．4OpSec278
17．2．5牺牲好的OpSec实践换取更大的利益280
17．2．6调查过程280
17．3控制事件283
17．3．1并行处理事件283
17．3．2移交284
17．3．3士气286
17．4沟通287
17．4．1误解287
17．4．2拐弯抹角287
17．4．3会议288
17．4．4让合适的人了解合适的细节289
17．5整合回顾290
17．5．1分诊290
17．5．2宣布事件290
17．5．3沟通和OpSec290
17．5．4开始处理事件291
17．5．5移交291
17．5．6交还事件调查工作291
17．5．7准备沟通和补救292
17．5．8结束292
17．6小结293
8章恢复和善后294
18．1恢复调度295
18．2恢复时间线296
18．3恢复计划297
18．3．1确定恢复范围297
18．3．2恢复过程的考虑因素298
18．3．3恢复检查清单301
18．4启动恢复302
18．4．1隔离资产302
18．4．2系统恢复和软件升级303
18．4．3数据过滤304
18．4．4恢复数据304
18．4．5更换凭据和密钥305
18．6恢复之后306
18．7示例308
18．7．1被入侵的云实例308
18．7．2大规模钓鱼攻击309
18．7．3需要复杂恢复工作的、有针对性的攻击310
18．8小结311
第五部分组织与文化
9章案例研究：Chrome安全团队315
19．1背景和团队发展史315
19．2安全是团队的职责317
19．3帮助用户安全地浏览Web页面318
19．4速度很重要319
19．5设计纵深防御机制319
19．6保持透明，让社区参与进来320
19．7小结320
第20章理解角色和责任321
20．1谁为安全性和可靠性负责322
20．1．1专家的作用322
20．1．2了解安全专业知识324
20．1．3资格认证和学术教育325
20．2将安全性整合到组织中325
20．2．1嵌入安全人员和安全团队327
20．2．2案例：Google的嵌入式安全327
20．2．3特殊的团队：蓝队和红队329
20．2．4外部研究者330
20．3小结332
第21章建立安全可靠的文化333
21．1定义健康的安全性和可靠性文化334
21．1．1默认的安全性和可靠性文化334
21．1．2评审文化335
21．1．3意识文化336
21．1．4说“是”的文化339
21．1．5接受必然性的文化340
21．1．6可持续发展文化340
21．2通过佳实践改变文化342
21．2．1对齐项目目标和激励参与者342
21．2．2通过风险规避机制减少恐惧343
21．2．3使安全兜底措施成为常态344
21．2．4提高生产力和可用性344
21．2．5多沟通，保持透明345
21．2．6怀抱同理心346
21．3说服领导层347
21．3．1了解决策过程347
21．3．2为变革立案348
21．3．3选择自己的战场349
21．3．4升级和问题解决349
21．4小结350
总结351
附录灾难风险评估矩阵353
作者介绍355
封面介绍355