《The.Security.Development.Lifecycle.CN.软件安全开发生命周期》
第一部分 对SDL的需求
隐私与安全：
隐私可以看作是遵守策略的一种方式，安全则看做是一种执行策略的方式。隐私问题的核心是符合监管部门的要求、公司策略和客户期望。关于安全还需要考虑的一个因素是与客户签订的服务水平协议（SLA）和维护时间。安全与可靠性存在显著差别，但有时候可能会产生冲突。微软可信计算最初关注四个方面，其中三个是技术方面：安全、隐私和可靠性。下图为质量、安全、隐私和可靠性之间的关系
影响SDL成本的因素：
1.从最初就实施SDL是成本最低的。选择语言、编码标准以及中医的攻击，尽量避免出现错误。
2.对大量“遗留代码”应用SDL的成本是高昂的。
3.同等条件先，在C#、VB.NET或Java等托管代码环境中应用SDL，相比于在C或C++等未托管代码环境而言，更为容易。
4.彻底移除某一特性总会比不断地修复更安全，成本更低。
5.工具通常情况下总是比人工查找漏洞更有效。
当前的软件开发方法不足以生成安全的软件，主要有以下四种不行的原因
“只要给予足够的关注，所有的缺陷都将无处遁形”不行的原因：大多数人并不喜欢审核代码中的bug和漏洞，因为过程缺乏创新性且缓慢枯燥令人厌烦。有一个简单的原则：代码审核的质量，完全取决于待审核的代码的多少；必须有足够多的具备相关知识的人员才能够对代码进行充分的审核；“关注越多”越容易失去要点。
- 专利软件开发模式不行的原因：现在有许多开发模式，没有任何证据表明，这些模式中的任何一种能比其中的另外一种缔造出更安全的软件。多数软件开发模式在文档中很少提及“安全”和“质量”。
- 敏捷开发模式不行的原因：安全最佳实践不够深入。
- 通用评估准则不行的原因：CC所提供的知识表明安全相关的特性已经按照预期执行的证据，他的目标并不是确保监控程序不出现任何实现上的安全bug。
第二部分 对SDL的需求软件安全开发生命周期过程
第0阶段：教育和意识
- 微软的bug bush本身是为了找出安全bug，但他的娱乐性远远高于其本身涉及的技术。奠定了微软整个安全教育的根基。还有安全意识演讲，应包含可信计算概述、SDL简介、安全设计基础、威胁建模、模糊测试介绍、安全编码最佳实践。微软所有工程人员每年必须至少参加一次安全培训，也可将在线培训拍下来放到公司内网中。成功的安全教育与意识培训需要三点:
- 管理层明确支持
- 富有经验演讲者
- 持续进行的教育
第1阶段：项目启动
- 首先判断软件安全开发生命周期是否覆盖应用。原则上来说，所有的软件都能从SDL过程中受益。接着指定一个在SDL过程中指引开发团队安全活动的安全人员，其主要职责是确保最终安全审核能够完成。这个员工叫做安全顾问。安全顾问是开发团队与安全团队之间沟通的桥梁，安全顾问需要召集开发团队举行SDL启动会议，对开发团队的设计与威胁模型进行评审，分析并对bug进行分类。接着是组建安全领导团队，确保在bug跟踪管理过程中包含有安全与隐私类bug。最后建立“bug标准”。
第2阶段：定义并遵从设计最佳实践
- 常见安全设计原则：
- 经济机制：保证代码与设计尽可能简单、紧凑。
- 默认失效保护：对任何请求默认应加以拒绝。
- 完全中介：每一个访问受保护对象的行为都应当被检查
- 公开设计：与“不公开即安全”的原则相对而言，认为设计本身不应具有神秘感。
- 权限分离：切勿允许基于单一条件的操作过程
- 最小特权：只授予执行操作所必需的最小特权
- 最少公共机制：使诸如文件以及变量等类似的共享资源尽可能少。
- 心理可接受程度
- 进行受攻击面分析与降低，不仅要理解应用的受攻击面组成，而且还要理解如何才能有效地降低受攻击面，从而阻止利用潜在的缺陷代码进行攻击的攻击者。ASR主要有一下几步：确定该特性是否真的很重要、谁需要从哪里访问这些功能、降低特权。
第3阶段：产品风险评估
安全风险评估被用于判断系统中易受攻击的漏洞级别。需要考虑以下几个问题：安装问题、受攻击面问题、移动代码问题、安全特性相关问题、常规问题、分析问卷。
隐私影响分级是产品风险评估的第二部分，这个分级包括三个策略值：隐私分级1，隐私分级2和隐私分级3。如果应用满足以下任何一项，就具有最高可能性隐私分级，因而要求具有最高隐私保护职责。
应用传输匿名数据给软件开发人员或者第三方，则被划分为隐私分级2.如果应用不包含1和2中任何一种行为，则被划分为隐私分级
隐私分级1 满足：
隐私分级2：应用传输匿名数据给软件开发人员或第三方。
隐私分级3：应用不包含隐私分级1、2中的任何一种行为。
统一各种因素
第4阶段：风险分析
- 威胁建模产物是描述应用背景信息并定义高层应用模型的文件，通常包括：应用场景、外部依赖性、安全假设、外部安全备注。威胁建模过程如下：
- 定义应用场景
- 收集外部依赖列表
- 定义安全假设
- 创建外部安全备注
- 绘制数据流图
- 确定威胁类型
- 识别系统威胁
- 判断风险
- 规划消减措施
- 威胁模型可以用来辅助代码评审和测试。
第5阶段：创建安全文档、工具以及客户最佳实践
创建指导性安全最佳实践文档，主要包括以下几类：安装文档、主线产品使用文档、帮助文档、开发人员文档
第6阶段：安全编码策略
- 使用编译器内置防御特性，这些保护性的代码是由编译器自动添加，无需开发人员进行干预，主要的防护选项：
- 缓冲区安全检查：/GS
- 安全异常处理：/SAFESEH
- 数据执行防护兼容性：/NXCOMPAT
- 使用源代码分析工具本身并不能使软件变得更安全，很容易落到陷阱中。但源代码分析工具也有益处。切勿使用违禁函数，减少潜在可被利用的编码结构或设计，使用安全编码检查清单。
第7阶段：安全测试策略
- 模糊测试最初用于发现可靠性bug，后来证明其也可以发现某类安全bug。模糊操作旨在通过反复解释代码分析数据结构，也可称之为解析器，有三种：文件格式解析器、网络协议解析器、API和其他零散解析器。渗透测试是一个用于在信息系统在中发现脆弱性的测试过程。还有一种测试方式就是运行时验证。
第8阶段：安全推进活动
- 一次成功的推进活动需要周密的计划以及从一开始就被列入日程计划中的时间投入。软件开发团队最低程度也需要接受专门的培训，以使其对安全推进活动的期望值以及推进流程等有所了解。计算机上运行的所有代码或成为你软件的一部分的代码都必须被评审，而且该评审与代码年限没有关系。
架构师和程序经理们需要对威胁模型进行不止一次的评审。在安全推进活动期间的程序化管理方式推动重估受攻击面的任务完成，会获得两个主要的收益：好的安全习惯和有助于推动代码评审任务的优先程度评级。最终，编写终端用户文档的作者和编辑们都应当对他们所有的草稿文档进行评审，以验证安全最佳实践是正确无误的，且文档中没有述及潜在有危害的实践。
第9阶段：最终安全评审
- 完整的最终安全评审过程有四个步骤，一是产品团队协调，这一部分不是纯技术性的活动，团队必须填写一个调查问卷。二是再次评审威胁模型，三是未修复的安全bug评审，验证那些标记为“暂不修复”的安全bug是否可真正对其不予理睬。四是工具有效性验证。
这些内容不只是读书笔记，还让我对自己的大学学习生活进行了反思。
第10阶段：安全响应规划
-
为什么准备响应？因为开发团队一定会出错，新漏洞一定会出现，规则一定会发生变化。准备安全响应包含两个过程，第一是建立一个安全响应过程，第二就是每一个产品开发团队的责任，组建一个安全响应中心
-
产品团队有效的执行响应过程是十分必要的，有两个指导原则，一是准备安全响应的时间应位于漏洞被上报之前；二是每一个软件团队都必须做好安全响应准备。主要步骤：组建相应团队、支持全线产品、支持所有客户、使产品具备更新能力、在研究人员之前找到漏洞。
第11阶段：产品发布
- 如需软件被签字通过，安全与隐私团队就必须认可以下事实：SDL过程被正确无误地贯彻落实了。
第12阶段：安全响应执行
- 遵从你的计划，如果有新上报的漏洞，保持冷静，记住欲速则不达，留意可能改变计划的事件，遵从你的计划；尽你所能补救，深谙取舍之道
