SDL安全开发生命周期

安全开发

Word count: 3.6kReading time: 12 min

 2019/06/15 

SDL简介
- SDL是什么
- SDL能解决什么问题
SDL、SDLC和S-SDLC
项目生命周期中存在的问题
SDL的步骤
安全设计核心原则
SDL实战经验准则
学习文章

SDL简介

SDL是什么

安全开发生命周期（SDL）即Security Development Lifecycle，是一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。自2004年起，微软将SDL作为全公司的计划和强制政策，SDL的核心理念就是将安全考虑集成在软件开发的每一个阶段:需求分析、设计、编码、测试和维护。从需求、设计到发布产品的每一个阶段每都增加了相应的安全活动，以减少软件中漏洞的数量并将安全缺陷降低到最小程度。安全开发生命周期 (SDL)是侧重于软件开发的安全保证过程，旨在开发出安全的软件应用。

SDL能解决什么问题

SDL将设计、代码和文档等与安全相关漏洞减到最少，在软件开发的生命周期中尽可能的早地发现解决相关漏洞建立的流程框架;为了实现保证最终的用户安全，在软件开发各阶段中引入针对项目安全和用户隐私问题的解决方案。

SDL、SDLC和S-SDLC

SDL：Security Development Lifecycle，安全开发生命周期；

SDLC：Software Development Life Cycle，软件开发生命周期；

S-SDLC：Secure Software Development Life Cycle，安全软件开发生命周期，是由开源Web安全组织OWASP推出的一个项目，它跟SDL的区别是它更关注的是SDL的落地化；

项目生命周期中存在的问题

项目研发生命周期：需求分析->设计->研发->测试->部署
项目研发生命周期中安全危险暴露模型：
SDL安全开发流程

SDL中的方法，试图从安全漏洞产生的根源上解决问题，通过对软件工程的控制，保证产品的安全性。
美国国家标准与技术研究所（NIST）估计，如果是在项目发布后在执行漏洞修复计划，其修复成本相当于在设计阶段执行修复的30倍。

SDL的步骤

一、培训

开发团队的所有成员都必须接受适当的安全培训，了解相关的安全知识，培训对象包括开发人员、测试人员、项目经理、产品经理等。
在SDL执行之前，需要给研发团队进行相关的安全培训，包括但不限于以下内容。当然，个人认为对产品线研发团队的安全培训并不只是限于SDL执行之前、而是针对各个阶段都要进行。
- 安全设计，包括以下主题：
  - 减小攻击面
  - 深度防御
  - 最小权限原则
  - 安全默认设置
- 威胁建模，包括以下主题：
  - 威胁建模概述
  - 威胁模型的设计意义
  - 基于威胁模型的编码约束
- 安全编码，包括以下主题：
  - 缓冲区溢出（对于使用 C 和 C++ 的应用程序）
  - 整数算法错误（对于使用 C 和 C++ 的应用程序）
  - 跨站点脚本（对于托管代码和 Web 应用程序）
  - SQL 注入（对于托管代码和 Web 应用程序）
- 弱加密安全测试，包括以下主题：
  - 安全测试与功能测试之间的区别
  - 风险评估
  - 安全测试方法
- 隐私，包括以下主题：
  - 隐私敏感数据的类型
  - 隐私设计最佳实践
  - 风险评估
  - 隐私开发最佳实践
  - 隐私测试最佳实践

二、要求

在项目确立之前，需要提前与项目经理或者产品owner进行沟通，确定安全的要求和需要做的事情。确认项目计划和里程碑，尽量避免因为安全问题而导致项目延期发布。

本阶段主要包括3个SDL实践：

安全要求：“预先”考虑安全和隐私是开发安全系统过程的基础环节。为软件项目定义信任度要求的最佳时间是在初始计划阶段。尽早定义要求有助于开发团队确定关键里程碑和交付成果，并使集成安全和隐私的过程尽量不影响到计划和安排。对安全和隐私要求的分析在项目初期执行，所做工作涉及为设计在计划运行环境中运行的应用程序确定最低安全要求，并确立和部署安全漏洞/工作项跟踪系统。
质量门/Bug栏：用于确立安全和隐私质量的最低可接受级别。
安全和隐私风险评估：安全风险评估 (SRA) 和隐私风险评估 (PRA) 是必需的过程，用于确定软件中需要深入评析的功能环节。这些评估必须包括以下信息：
- （安全）项目的哪些部分在发布前需要威胁模型？
- （安全）项目的哪些部分在发布前需要进行安全设计评析？
- （安全）项目的哪些部分（如果有）需要由不属于项目团队且双方认可的小组进行渗透测试？
- （安全）是否存在安全顾问认为有必要增加的测试或分析要求以缓解安全风险？
- （安全）模糊测试要求的具体范围是什么？
- （隐私）隐私影响评级如何？

三：设计

SDL安全设计的6个核心原则：

Attack Surface Reduction（攻击面最小化）
Basic Privacy（基本隐私）
Least Privilege（权限最小化）
Secure Defaults（默认安全）
Defense in Depth（纵深防御）
Threat Modeling（威胁建模）

三：实施

本阶段主要包括3个SDL实践：

使用批准的工具：所有开发团队都应定义并发布获准工具及其关联安全检查的列表，如编译器/链接器选项和警告。此列表应由项目团队的安全顾问进行批准。一般而言，开发团队应尽量使用最新版本的获准工具，以利用新的安全分析功能和保护措施。
弃用不安全的函数：许多常用函数和 API 在当前威胁环境下并不安全。项目团队应分析将与软件开发项目结合使用的所有函数和 API，并禁用确定为不安全的函数和 API。确定禁用列表之后，项目团队应使用头文件（如 banned.h 和 strsafe.h）、较新的编译器或代码扫描工具来检查代码（在适当情况下还包括旧代码）中是否存在禁用函数，并使用更安全的备选函数替代这些禁用函数。
静态代码分析：项目团队应对源代码执行静态分析。源代码静态分析为安全代码评析提供了伸缩性，可以帮助确保对安全代码策略的遵守。静态代码分析本身通常不足以替代人工代码评析。安全团队和安全顾问应了解静态分析工具的优点和缺点，并准备好根据需要为静态分析工具辅以其他工具或人工评析。

四：验证

本阶段主要包括3个SDL实践：

动态程序分析：为确保程序功能按照设计方式工作，有必要对软件程序进行运行时验证。此验证任务应指定一些工具，用以监控应用程序行为是否存在内存损坏、用户权限问题以及其他重要安全问题。SDL 过程使用运行时工具（如 AppVerifier）以及其他方法（如模糊测试）来实现所需级别的安全测试覆盖率。
模糊测试：模糊测试是一种专门形式的动态分析，它通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定以应用程序的预期用途以及应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试或扩大模糊测试的范围和增加持续时间。
威胁模型和攻击面评审：应用程序经常会严重偏离在软件开发项目要求和设计阶段所制定的功能和设计规范。因此，在给定应用程序完成编码后重新评析其威胁模型和攻击面度量是非常重要的。此评析可确保考虑到对系统设计或实现方面所做的全部更改，并确保因这些更改而形成的所有新攻击平台得以评析和缓解。

五：发布

本阶段主要包括3个SDL实践：

事件响应计划：受SD 要求约束的每个软件发布都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的程序也可能面临日后新出现的威胁。事件响应计划应包括：
- 单独指定的可持续工程 (SE) 团队；或者，如果团队太小以至于无法拥有 SE 资源，则应制定紧急响应计划 (ERP)，在该计划中确定相应的工程、市场营销、通信和管理人员充当发生安全紧急事件时的首要联系点。
- 与决策机构的电话联系（7 x 24 随时可用）。
- 针对从组织中其他小组继承的代码的安全维护计划。
- 针对获得许可的第三方代码的安全维护计划，包括文件名、版本、源代码、第三方联系信息以及要更改的合同许可（如果适用）。
最终安全评审：最终安全评析 (FSR) 是在发布之前仔细检查对软件应用程序执行的所有安全活动。FSR 由安全顾问在普通开发人员以及安全和隐私团队负责人的协助下执行。FSR 不是“渗透和修补”活动，也不是用于执行以前忽略或忘记的安全活动的时机。FSR 通常要根据以前确定的质量门或 Bug 栏检查威胁模型、异常请求、工具输出和性能。
发布/存档：指派负责发布事宜的安全顾问必须证明（使用 FSR 和其他数据）项目团队已满足安全要求。此外，必须对所有相关信息和数据进行存档，以便可以对软件进行发布后维护。这些信息和数据包括所有规范、源代码、二进制文件、专用符号、威胁模型、文档、紧急响应计划、任何第三方软件的许可证和服务条款以及执行发布后维护任务所需的任何其他数据。

发布后：响应

产品在发布后的安全应急响应是必须要做的。

从以上的过程可以看出，微软的SDL的过程实施非常细致。微软这些年来也一直帮助公司的所有产品团队，以及合作伙伴实施SDL，效果相当显著。

相对于微软的SDL，OWASP推出了SAMM（Software Assurance Maturity Model），帮助开发者在软件工程的过程中实施安全。
SAMM与SDL的主要区别在于，SDL适用于软件开发商，他们以贩售软件为主要业务；而SAMM更适用于自主开发软件的使用者，如银行或在线服务提供商。软件开发商的软件工程往往较为成熟，有着严格的质量控制；而自主开发软件的企业组织，则更强调高效，因此在软件工程的做法上也存在差异。

安全设计核心原则

在SDL模型里，有个比较核心的点是安全设计核心原则，来自腾讯安全的总结：

SDL安全开发流程

攻击最小化

暴露的CGI等都可能是攻击点，非必要的接口等要减少。
即使暴露也应该限制访问访问范围从而缩小攻击面。

默认安全

指产品在设计的时候一些配置的默认项应该考虑是安全状态，比如一些安全开关应该是默认开启。

威胁建模

威胁建模是在需求设计阶段的一项识别和消减威胁的重要手段。关于威胁建模，微软提出的一个方法叫做“STRIDE”。

SDL安全开发流程

STRIDE威胁建模其实就是基于数据流图去识别不同环节是否存在仿冒、篡改、抵赖、信息泄露、拒绝服务、权限提升几个维度的安全威胁，并制定对应的消减措施，落实并验证的一个过程。其中六个维度的威胁大家通过表格里的安全属性就可以看到它其实是基于信息安全基本要素制定的。额外提下，由于隐私安全的关注的爆发，也成为了第七个安全威胁。具体这里就不对威胁建模展开说明了，大家有兴趣可以通过扩展阅读内容进行学习。