读软件开发安全之道：概率、设计与实施01基础.png

1. 基础

1.1. 实现软件安全既需要运用逻辑，又是一项艺术

• 1.1.1. 一项仰赖直觉来做出判断的艺术

• 1.1.2. 需要践行者对当代数字系统有所掌

• 1.1.3. 需要他们对人与系统之间的交互有所体悟

1.2. 需要准确地思考一下何谓安全

• 1.2.1. 安全定义的主观性颇强，因此厘清安全的基本概念就显得至关重要

• 1.2.2. 信任是一切安全的基本要素，因为每个人都需要使用别人的劳动成果

• 1.2.3. 当代数字系统已经过于复杂，没有人可以凭一己之力从硅元素开始打造自己的“数字王国”

2. 理解安全

2.1. 世上所有生命体都会本能地远离风险

• 2.1.1. 我们在虚拟世界中应对风险的本能付之阙如，攻击者制造虚假信号则易如反掌

• 2.1.2. 虽然比特和代码既无形，也无声，更无味，但这绝不应该妨碍我们努力评估安全风险

2.2. 软件安全的核心目标是保护数字资产，让它们不会受到各种威胁的侵害

2.3. “信息安全”这个专有名词专门指代数据的保护和访问权限的授予

2.4. 软件安全则是一个比较宽泛的概念，软件安全专注于可靠软件系统的设计、实施和操作，包括使其通过可靠的方式来实现信息安全

3. 信任

3.1. 信任在数字世界也同样重要，但是在数字世界中，人们常常认为信任是理所当然的

3.2. 软件安全从根本上都要依赖于信任

• 3.2.1. 没有人可以控制一个系统的所有组件

• 3.2.2. 没有人可以自己编写所有的软件

• 3.2.3. 没有人可以对自己合作的所有供应商进行审查

• 3.2.4. 没有人可以自己从头搭建所有这些系统

3.3. 企业都会根据功能或者价格来选择自己的软硬件产品

• 3.3.1. 所有选择本质上都是建立在信任基础上的决策

3.4. 安全性要求我们认真地分析信任关系

• 3.4.1. 哪怕没人有时间、有资源来对所有资源进行彻底的调查和验证

• 3.4.2. 如果无法做到充分信任，就意味着企业必须完成大量不必要的工作去保护一个很可能不会面临任何实质威胁的系统

• 3.4.3. 如果无条件地信任，未来则有可能会措手不及

• 3.4.4. 如果你完全信任一个实体，它们也就基本上不需要为失败承担任何后果了

3.5. 违背信任有下面两种完全不同的形式

• 3.5.1. 恶意行为（如欺骗、谎言、诡计等）

• 3.5.2. 失职行为（如错误、误解、疏忽等）

3.6. 在信息缺失的情况下做出重要决策，是人们最需要信任关系的场景

• 3.6.1. 我们与生俱来的信任感依赖的是微妙的感官信号，而这种本能不适用于数字世界

• 3.6.2. 利用好自己的信任本能是一种强有力的手段。久而久之，我们就可以对软件安全运用类似的信任本能，这比多少技术分析都更加有效

4. 信任感

4.1. 理解信任感的最好方法就是在我们依靠信任来做出判断的时候，仔细品味那种感受

4.2. 提升自己对数字信任方面的决策的认识，这样才能帮助别人看清这些决策给安全带来的影响

5. 比特不是肉眼可见的

5.1. 当我们自以为“眼睁睁地看着这些数据”的时候，我们其实看到的只是一种与数据本身距离十万八千里的数据展示方式

5.2. 数字科技让信任这件事变得相当棘手，因为它如此抽象、迅捷，看不见、摸不着

• 5.2.1. 当我们浏览数据时，一定要切记内存中的数据与我们阅读数据时看到的那些像素点之间隔着大量的软硬件操作

5.3. 数字信息的基本事实是极难直接进行分辨的

5.4. 关键在于，我们必须弄清楚这种信任的深度和广度，而不是认为所有的信任都是理所当然的

6. 能力与不足

6.1. 大多数攻击始于软件的缺陷或者误配

• 6.1.1. 可能都是那些诚信有加、心存善念的程序员和IT人员制造出来的

• 6.1.2. 是人就会犯错

6.2. 软件使用许可都会包含免责声明，所以一切软件都是在用户知悉和认可风险的前提下使用的

6.3. “所有软件都有bug”，那么其中总有一些bug可以被利用，攻击者也总能找到一些bug并且加以利用

6.4. 软件专家一般很少因为错信了恶意软件，而成为攻击者的目标

6.5. 我们并不难判断哪些操作系统、编程语言比较可靠

6.6. 开源提供了这种透明性，但是开源软件的安全水平取决于项目甲方对开发者的监管是否严格到足以防止开发者在软件中有意无意地插入恶意代码

6.7. 没有一家软件公司会承诺在发生攻击事件时提供更高级别的安全性或者向用户提供赔偿，以此彰显自己在业内的特殊地位

6.8. 信任决策的重要性固然不可小觑，但是也没人能够永远做出正确的决策

• 6.8.1. 信任决策从来都是不完美的

7. 信任是一个频谱

7.1. 信任永远是分不同程度的，在对信任的评估过程中也总是包含一定的不确定性

7.2. 鉴于信任是一个频谱，“信任但仍要验证”的策略就是一个强大的工具，可以让我们在绝对信任与绝对不信任之间建立起一座桥梁

7.3. 审计包括自动审计（准确地校验大量重复的活动日志）与手动审计（选择性校验，以处理那些比较罕见的情况，它把人工核查作为最终决策的依据）

8. 信任决策

8.1. 在软件领域，人们有两种选择：信任或不信任

• 8.1.1. 如果存在疑问，我们大可以选择不信任

• 8.1.2. 只要我们有理由信任另一个候选的解决方案

8.2. 做出信任决策的过程就像给一棵“信任树”剪枝，这棵树如果不加修剪就会长出无穷的枝杈

• 8.2.1. 如果我们相信某项服务或者某台计算机是安全的，我们就不需要花费大量精力进行深入分析了

• 8.2.2. 如果我们无法做到信任，那么我们就需要对系统的更多组成部分（包括很多微组件）加以保护

• 8.2.3. 如果我们不信任供应商，我们就需要继续做出信任决策，毕竟我们不可能完全靠自力更生

8.3. 如果我们只是希望降低整个系统的脆弱性，防止因软件问题导致错误传播，则可以在条件允许的情况下，尽可能增加一些安全校验

8.4. 隐式信任组件

• 8.4.1. 每个软件项目都会依赖大量存在隐式信任(implicitly trusted)的技术

  • 8.4.1.1. 硬件、操作系统、开发工具、库和其他很难核查可靠性的技术

  • 8.4.1.2. 我们只能根据供应商的声誉选择相信这些工具

• 8.4.2. 管理隐式信任没有简便方法

  • 8.4.2.1. 你认定为可靠的对象数量降至最低

  • 8.4.2.2. 每多信任一家公司，就给了这家公司一次让你失望的机会

  • 8.4.2.3. 同一家公司产品线中的产品往往兼容性更好，这些产品之间的互操作也经历过更多的测试

8.5. 值得信赖

• 8.5.1. 每个软件产品都必须让终端用户认为这个产品是值得信赖的

• 8.5.2. 每个软件产品都必须让终端用户认为这个产品是值得信赖的

• 8.5.3. 产品提供的功能相当重要，就必须让客户有坚实的理由信任我们的产品

• 8.5.4. 保持透明可以提升信任感

  • 8.5.4.1. 公开自己的工作可以让客户评估产品的安全性

• 8.5.5. 让第三方参与，利用第三方的独立性来提升信任感

• 8.5.6. 有时，我们的产品就是需要和其他产品进行集成的第三方产品，因为独立交易的双方很难相互勾结，所以这项产品也可以提升客户的信任感

• 8.5.7. 在出现问题的情况下，要主动接受客户的反馈，然后果断采取行动，并且公开披露调查的结果，以及提出防止问题再次发生的措施

• 8.5.8. 有些特性或者设计要素可以把信任感具象化，让客户可以亲眼看到

  • 8.5.8.1. 通过一种存档解决方案来实时显示在不同位置保存了多少份备份

• 8.5.9. 行动可以提升信任感，空洞的口号则会让那些精明的客户产生怀疑

  • 8.5.9.1. 提供一些有形的证据，最好是可以让客户自己进行验证的证据

  • 8.5.9.2. 开放代码给人们审查（让他们知道总有懂得如何审查代码的人会去审查这些代码）本身也能够提升信任感