第 17 章 安全开发流程（ SDL ）
安全开发流程，能够帮助企业以最小的成本提高产品的安全性。它符合“ Secure at the Source ”的战略思想。实施好安全开发流程，对企业安全的发展来说，可以起到事半功倍的效果。
17.1 SDL 简介
SDL 的全称是 Secureity Development Lifecycle ，即：安全开发生命周期。它是由微软最早提出的，在软件工程中实施，是帮助解决软件安全问题的办法。SDL 是一个安全保证的过程，其重点是 软件开发，它在开发的所有阶段都引入了安全和隐私的原则。自 2004 年起，SDL 一直都是微软在全公司实施的强制性策略。SDL 的大致步骤如下：
SDL 中的方法，试图从安全漏洞产生的根源上解决问题。通过对软件工程的控制，保证产品的安全性。
美国国家标准与技术研究所（ NIST ）估计，如果是在项目发布后再执行漏洞修复计划，其修复成本相当于在设计阶段执行修复的 30 倍。
步骤阶段：
1. 培训
开发团队的所有成员都必须接收适当的安全培训，了解相关的安全知识。培训的环节在 SDL 中看似简单，但其实不可或缺。通过培训能贯彻安全策略和安全知识，并在之后的执行过程中提高执行效率，降低沟通成本。培训对象包括开发人员、测试人员、项目经理、产品经理等。
微软推荐的培训，会覆盖安全设计、威胁建模、安全编码、隐私等方面知识。
2. 安全要求
在项目确立之前，需要提前与项目经理或者产品 owner 进行沟通，确定安全的要求和需要做的事情。确认项目计划和里程碑，尽量避免因为安全问题而导致项目延期发布----这是任何项目经理都讨厌发生的事情。
3. 质量门/bug 栏
质量门和 bug 栏用于确定安全和隐私质量的最低可接受级别。在项目开始时定义这些标准可加强对安全问题相关风险的理解，并有助于团队在开发过程中发现和修复安全 bug 。项目团队必须协商确定每个开发阶段的质量门（例如，必须在 check in 代码之前进行 review 并修复所有的编译器警告），随后将质量门交由安全顾问审批，安全顾问可以根据需要添加特定于项目的说明，以及更加严格的安全要求。另外，项目团队需阐明其对安全门的遵从性，以便完成最终安全评析（FSR）。
bug 栏是应用于整个软件开发项目的质量门，用于定义安全漏洞的严重性阀值。例如，应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。bug 栏一经设定，便决不能放松。
4. 安全和隐私风险评估
安全风险评估（SRA）和隐私风险评估（PRA）是一个必需的过程，用于确定软件中需要深入评析的功能环节。这些评估必须包括以下信息：
- （安全）项目的哪些部分在发布前需要威胁模型？
- （安全）项目的哪些部分在发布前需要进行安全设计评析？
- （安全）项目的哪些部分（如果有）需要由不属于项目团队且双方认可的小组进行渗透测试？
- （安全）是否存在安全顾问认为有必要增加的测试或分析要求以缓解安全风险？
- （安全）模糊测试要求的具体范围是什么？
- （隐私）隐私影响评级如何？
5. 设计要求
在设计阶段应仔细考虑安全和隐私问题，在项目初期确定好安全需求，尽可能避免安全引起的需求变更。
6. 减少攻击面
减少攻击面与威胁建模紧密相关，不过它解决安全问题的角度稍有不同。减少攻击面通过减少攻击者利用潜在弱点或漏洞的机会来降低风险。减小攻击面包括关闭或限制对系统服务的访问，应用“最小权限原则”，以及尽可能地进行分层防御。
7. 威胁建模
为项目或产品面临的威胁建立模型，明确可能来自的攻击有哪些方面。微软提出了 STRIDE 模型以帮助建立威胁模型，这是非常好的做法。
8. 使用指定的工具
开发团队使用的编译器、链接器相关工具，可能会涉及一些安全相关的环节，因此在使用工具的版本上，需要提前与安全团队进行沟通。
9. 弃用不安全的函数
许多常用函数可能存在安全隐患，应该禁用不安全的函数或 API ，使用安全团队推荐的函数。
10. 静态分析
代码静态分析可以由相关工具辅助完成，其结果与人工分析相结合。
11. 动态程序分析
动态分析是静态分析的补充，用于程序环节验证程序的安全性。
12. 模糊测试（ Fuzzing Test ）
模糊测试是一种专门形式的动态分析，它通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定，以应用程序的预期用途，以及应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试，或者扩大模糊测试的范围和增加持续时间。
13. 威胁模型和攻击面评析
项目经常会因为需求变更等因素导致最终的产出偏离原本设定的目标，因此在项目后期重新对威胁模型和攻击面进行评析是有必要的，能够及时发现问题并修正。
14. 事件响应计划
受 SDL 要求约束的每个软件在发布时都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的产品，也可能在日后面临新出现的威胁。需要注意的是，如果产品中包含第三方的代码，也需要留下第三方的联系方式并加入事件响应计划，以便在发生问题时能够找到对应的人。
15. 最终安全评析
最终安全评析（ FSR ）是在发布之前仔细检查对软件执行的所有安全活动。通过 FSR 将得出以下三种不同结果。
- 通过 FSR 。在 FSR 过程中确定的所有安全和隐私问题都已得到修复或缓解。
- 通过 FSR 但有异常。在 FSR 过程中确定的所有安全和隐私问题都已得到修复或缓解，并且/或者所有异常都已得到圆满解决。无法解决的问题将记录下来，在下次发布时更正。
- 需上报问题的 FSR 。如果团队未满足所有 SDL 要求，并且安全顾问和产品团队无法达成可接受的折中，则安全顾问不能批准项目，项目不能发布。团队必须在发布之前解决所有可以解决的问题，或者上报高级管理层进行抉择。
16. 发布/存档
在通过 FSR 或者虽有问题但达成一致后，可以完成产品的发布。但发布的同时任需要对各类问题和文档进行存档，为紧急响应和产品升级提供帮助。
相对于微软的 SDL ，OWASP 推出了 SAMM（ Software Assurance Maturity Model ），帮助开发者在软件工程的过程中实施安全。
SAMM 和微软 SDL 的主要区别在于，SDL 适用于软件开发商，他们以贩售软件为主要业务；而 SAMM 更适用于自主开发软件的使用者，如银行或在线服务提供商。软件开发商的软件工程往往较为成熟，有着严格的质量控制；而自主开发软件的企业组织，则更强调高效，因此在软件工程的做法也存在差异。
17.2 敏捷 SDL
就微软的 SDL 过程来看，仍然显得较为厚重。它适用于采用瀑布法进行开发的软件开发团队，而对于使用敏捷开发的团队，则难以适应。
敏捷开发往往是采用“小步快跑”的方式，但是对于安全来说，往往是一场灾难。需求无法再一开始非常明确，一些安全设计可能也会随之变化。
微软为敏捷开发专门设计了敏捷 SDL。
敏捷 SDL 的思想其实就是以变化的观点实施安全的工作。需求和功能可能一直在变化，代码可能也在发生变化，这要求在实施 SDL 时需要在每个阶段更新威胁模型和隐私策略，在必要的环节迭代模糊测试、代码安全分析等工作。
17.3 SDL 实战经验
- 与项目经理进行充分沟通，排出足够的时间。
- 规范公司的立项流程，确保所有项目都能通知到安全团队，避免遗漏。
- 树立安全部门的权威，项目必须由安全部门审核完成后才能发布。
- 将技术方案写入开发、测试的工作手册中。
- 给工程师培训安全方案。
- 记录所有的安全 bug ，激励程序员编写安全的代码。
17.4 需求分析与设计阶段
在需求阶段，安全工程师需要关心产品主要功能上的安全强度和安全体验是否足够，主要需要思考安全功能。
在安全领域中，“安全功能”与“安全的功能”是两个不同的概念。
- 安全功能：产品本身提供给用户的安全功能。
- 安全的功能：产品具体功能的实现上要做到安全，不要出现漏洞而被黑客利用。
17.5 开发阶段
开发阶段是安全工作的一个重点。依据“安全是为业务服务”这一指导思想，在需求层面，安全改变业务的地方较少，因此应当力求代码实现上的安全，也就是做到“安全的功能”。
17.5.1 提供安全的函数
在开发阶段，还可以使用的一个最佳实践就是制定出开发者的 开发规范 ，并将安全技术方案写进开发规范中，让开发者牢记开发规范。
将安全方案写入开发规范中，就真正的让安全方案落了地。 这样不仅仅是为了方便开发者写出安全的代码，同时也为代码安全审计带来了方便。
代码安全审计工具
代码的自动化审计比较困难，而半自动的代码审计仍然需要耗费大量的人力，那有没有取巧的办法呢？
实际上，对于甲方公司来说，完全可以根据开发规范来定制代码审计工具。其核心思想是， 并非直接检查代码是否安全，而是检查开发者是否遵守了开发规范。
这样就把复杂的“代码自动化审计” 这一难题，转化为“代码是否符合开发规范”的问题。而开发规范在编写时就可以写成易于审计的一种规范。最终，如果开发规范中的安全方案没有问题的话，当开发者严格遵守开发规范时，产出的代码就应该是安全的。
17.6 测试阶段
测试阶段是产品发布前的最后一个阶段，在此阶段需要对产品进行充分的安全测试，验证需求分析、设计阶段的安全功能是否符合预期目标，并验证在开发阶段发现的所有安全问题是否得到解决。
安全测试应该独立于代码审计而存在。“安全测试”相对于“代码审计”而言，至少有两个好处：
- 有一些代码逻辑较为复杂，通过代码审计难以发现所有问题，而通过安全测试可以将问题看得更清楚；
- 有些逻辑漏洞通过安全测试，可以更快的得到结果。
安全测试，一般分为自动化测试和手动测试两种方式。
自动化测试以覆盖性的测试为目的，可以通过“Web 安全扫描器”对项目或产品进行漏洞扫描。
目前 Web 安全扫描器针对 “ XSS ”、“ SQL Injection ”、“ Open Redirect ”、“ PHP File Include ” 等漏洞的检测技术已经比较成熟。这是因为这些漏洞的检测方法主要是检测返回结果的字符串特征。
而对于 “ CSRF ”、“越权访问”、“文件上传”等漏洞，却难以达到自动化检测的效果。这是因为这些漏洞涉及系统逻辑或业务逻辑，有时候还需要人机交互参与页面流程。因此这类漏洞的检测更多的需要依靠手动测试完成。
Web 应用的安全测试工具一般是使用 Web 安全扫描器。
安全测试完成以后，需要生成一份安全测试报告。这份报告并不是扫描器的扫描报告。扫描报告可能会存在误报与漏报，因此扫描报告需要经过安全工程师的最终确认。确认后的扫描报告，结合手动测试的结果，最终形成一份安全测试报告。
安全测试报告中提到的问题，需要交给开发工程师进行修复。漏洞修补完成后，再迭代进行安全测试，以验证漏洞的修补情况。
1759
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
