第1篇 我的安全世界观
1.6 如何实施安全评估
1.6.3 风险分析
风险由以下因素组成：
Risk = Probability * Damage Potential
影响风险高低的因素，除了造成损失的大小外，还需要考虑到发生的可能性。
如何更科学地衡量风险呢？DREAD模型，它也是由微软提出的。
1.6.4 设计安全方案
最终，一个优秀的安全方案应该具备以下特点：
- 能够有效解决问题
- 用户体验好
- 高性能
- 低耦合
- 易于扩展与升级
1.7 白帽子兵法
在上节讲述了实施安全评估的基本过程，安全评估最后的产出物就是安全方案，但在具体设计安全方案时有什么样的技巧呢？本节将讲述在实战中可能用到的方法。
1.7.1 Secure By Default原则
在设计安全方案时，最基本也是最重要的原则就是“Secure by Default”。实际上，"Secure by Default”原则，也可以归纳为白名单、黑名单的思想。如果更多地使用白名单，那么系统就会变得更安全。
1.7.1.1 黑名单、白名单
然而，并不是用了白名单就一定安全了。
在前文中提到：“安全问题的本质是信任问题，安全方案也是基于信任来做的。”
选择白名单的思想，基于白名单来设计安全方案，其实就是信任白名单是好的，是安全的。但是一旦这个信任基础不存在了，那么安全就荡然无存。
1.7.1.2 最小权限原则
Secure by Default的另一层含义就是“最小权限原则”。最小权限原则也是安全设计的基本原则之一。
在使用最小权限原则时，需要认真梳理业务所需要的权限，在很多时候，开发者并不会意识到业务授予用户的权限过高。在通过访谈了解业务时，可以多设置一些反问句，比如：您确定您的程序一定需要访问Internet吗？通过此类问题，来确定业务所需的最小权限。
1.7.2 纵深防御原则
与Secure by Default一样，Defense in Depth（纵深防御）也是设计安全方案时的重要指导思想。
纵深防御包含两层含义：
首先，要在各个不同层面、不同方面实施安全方案，避免出现疏漏，不同安全方案之间需要相互配合，构成一个整体。
其次，要在正确的地方做正确的事情，即：在解决根本问题的地方实施针对性的安全方案。
就入侵的防御来说，我们需要考虑的可能有web应用安全、OS系统安全、数据库安全、网络环境安全等。在这些不同层面设计的安全方案，将共同组成整个防御体系，这也就是纵深防御的思想。
纵深防御的第二层含义，是要在正确的地方做正确的事情。如何理解呢？它要求我们深入理解威胁的本质，从而做出正确的措施。
对于一个复杂的系统来说，纵深防御是构建安全体系的必要选择。
1.7.3 数据与代码分离原则
另一个重要的安全原则是数据与代码分离原则。这一原则广泛适用于各种由于“注入”而引发安全问题的场景。
实际上，缓冲区溢出，也可以认为是程序违背了这一原则的后果——程序在栈或者堆中，将用户数据当做代码执行，混淆了代码与数据的边界，从而导致安全问题的发生。
在web安全中，由“注入”引起的问题比比皆是，如XSS、SQLInjection、CRLF Injection、X-Path Injection等。此类问题均可以根据“数据与代码分离原则”设计出真正安全的解决方案，因为这个原则抓住了漏洞行程的本质原因。
1.7.4 不可预测性原则
前面介绍的几条原则：Secure by Default，是时刻要牢记的总则；纵深防御，是要更全面、更正确的看待问题；数据与代码分离，是从漏洞成因上看问题；接下来要讲的“不可预测性”原则，则是从克服攻击方法的角度看问题。
不可预测性（Unpredictable)，能有效地对抗基于篡改、伪造的攻击。
不可预测性原则，可以巧妙地用在一些敏感数据上。
不可预测性的实现往往需要用到加密算法、随机数算法、哈希算法，好好使用这条原则，在设计安全方案时往往会事半功倍。
1.8 小结
(附）谁来为漏洞买单？
CVE的英文全称是“Common Vulnerabilities & Exposures”通用漏洞披露。CVE就好像是一个字典表，为广泛认同的信息安全漏洞或者已经暴露出来的弱点给出一个公共的名称。使用一个共同的名字，可以帮助用户在各自独立的各种漏洞数据库中和漏洞评估工具*享数据，虽然这些工具很难整合在一起。这样就使得CVE成为了安全信息共享的“关键字”。如果在一个漏洞报告中知名的一个漏洞，如果有CVE名称，你就可以快速的在任何其他CVE兼容的数据库中找到相应修补的信息，解决安全问题。