SDL:Security Development Lifecycle 安全开发生命周期
安全开发生命周期(SDL)是什么?
SDL 官方介绍
安全开发生命周期(SDL)即 Security Development Lifecycle,是一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。 自 2004 年起,微软将 SDL 作为全公司的计划和强制政策,SDL 的核心理念就是将安全考虑集成在软件开发的每一个阶段:需求分析、设计、编码、测试和维护。从需求、设计到发布产品的每一个阶段每都增加了相应的安全活动,以减少软件中漏洞的数量并将安全缺陷降低到最小程度。安全开发生命周期 (SDL)是侧重于软件开发的安全保证过程,旨在开发出安全的软件应用。
何为SDL安全开发生命周期
可以简单的说是将安全融入到开发的每一个过程中去,以减少软件中漏洞的数量并将安全缺陷降低到最小程度。由于SDL将安全进行左移,在源头就发现漏洞,可以直接进行修复,从而减少后期维护成本,以及和软件功能冲突的问题。
开发安全软件时,安全和隐私从来都不应是事后才考虑的,必须制定一个正式的过程,以确保在产品生命周期的所有时间点都考虑安全和隐私。 Microsoft 的安全开发生命周期 (SDL) 将全面的安全要求、特定于技术的工具和必需流程嵌入到所有软件产品的开发和运营中。
培训、需求、设计、实施、测试、发布、响应
微软 SDL 可以由上图七个部分组成(可简称 5 + 2),包括五个核心阶段(蓝色圆圈标注的中间5个阶段)和两个支持安全活动(黑色圆圈标注的两个端点):
5个核心阶段:分别是要求、设计、实现、验证和发布。 每个阶段都包含强制性的检查和审批,以确保所有安全和隐私要求以及最佳做法得到妥善解决。
2个支持活动:即培训和响应。分别在核心阶段之前和之后进行,以确保它们得到正确实现,并且软件在部署后保持安全。
Microsoft 的所有开发团队都必须遵守 SDL 流程和要求,从而获得更安全的软件,并降低开发成本,减少严重漏洞。
2、原理
结合应用开发的需求、设计、开发、测试、上线、运维和废弃等生命周期的各阶段,定义安全目标和控制措施,结合评审、测试、培训等手段,保证开发系统的安全性
3、原因
3.1 攻击内容发生了变化
- 病毒蠕虫
- 攻击OS、DB
- APT攻击社会工程学
- 攻击应用系统
3.2 攻击对象发生了变化
3.3 缺乏安全开发技能
3.4 运维阶段无法解决开发问题
- 应用程序代码问题(SQL注入、XSS)
- 应用系统安全设计失效(验证码绕过)
- 应用系统安全需求考虑不充分(密码保护)
- 基础环境漏洞(Apache struts2 ssl)
- 应用服务配置不当(IIS、nginx、Jboss)
4、安全开发管理带来的收益:
- 减少漏洞数量、提高系统安全性
- 降低上线压力,保证项目进度
- 降低安全和运维人员压力
- 规范应用开发各个环节,提高开发人员技能
- 理顺业务、开发、安全部门之间关系
5、SDL的安全目标
- 降低产品或服务的安全漏洞率
- 降低可能发生的安全漏洞的严重程度
- 在产品研发阶段就消除潜在的安全风险
- 建立企业整体安全开发规范和流程
- 将安全开发规范固化在开发工具中
- 建立安全能力中心,快速响应安全事件
6、 SDL安全能力提升路线图
6.1 PPDR安全自适应过程
PPDR是Prepare、Protect、Detect及Response的简称,具体如下:
Prepare(评估):现状调研
Protect(保护):保护体系建设
Detect(检测):检测和监控体系建设
Response(响应):应用响应体系建设
6.2 SDL能力提升路线
6.2.1 第一阶段:研发安全现状调研及差距分析
SDL 评估旨在确定企业在开发过程中的安全和隐私需求, 分析任何差距, 并向企业提供建议。评估23项功能, 涵盖 SDL 中的17种实践。
6.2.2 第二阶段:安全研发流程落地实施
微软的安全研发流程落地实施主要涉及如下五个关键点:
根据企业安全能力差距分析,进行安全培训体系建设、知识库建设、合规支撑工具建设,安全团队建设;
应用安全架构评估、威胁建模:比如建立威胁消减知识库,帮忙安全SE做安全架构设计;
自动化的安全功能点检查工具、自动化的发布过程,和安全工具自适应:比如 CodeQL 静态代码检查工具,可以自动检测开发者提交的PR,及时发现安全问题;
自动化的Web漏洞设,检查工具引入和建Fuzz工具引入,内网渗透和 KALI 的引入;
建立快速应急响应团队、明确响应人员角色职责。
7、业界标准:
7.1 微软(SDL)最广泛:
培训、需求、设计、实施、测试、发布、响应
7.2 思科(CSDL):
- 安全设计(安全需求、威胁建模)
- 安全开发(安全开发流程、安全开发工具)
- 渗透测试(设计验证)
7.3 NLST:
开始、获取和开发、执行、操作和维护、发布阶段部署
7.4 OWASP:
8. SDL具体内容
8.1 需求及交付全过程阶段
需求分析(安全需求工程)
设计:设计安全
实现:安全编码(输入过滤、输入编码、输出过滤、输出编码)
测试:软件黑盒测试,渗透性测试,代码安全审计(XSS测试,可手工也可以结合自动工具)
发布:补丁管理配置加固(IDS/IPS、web应用防火墙、客户端浏览器安全加固)
1. 需求分析阶段
确定和收集项目的需求和目标,包括功能需求、性能需求、安全需求等。进行用户需求调研,定义系统的功能和接口等。
2. 设计阶段
根据需求分析阶段的结果进行系统设计和架构设计。包括系统的模块划分、数据结构设计、算法设计、界面设计等等。
3. 编码阶段
根据设计阶段的结果,进行源代码的编写和单元测试。程序员根据系统设计和需求规格说明书进行编码。
4. 测试阶段
对编码阶段完成的代码进行全面的测试,包括单元测试、集成测试、系统测试、性能测试等等。发现并修复软件缺陷和问题。
5. 部署和交付阶段
将测试通过的软件部署到生产环境中,并向客户交付。可以包括软件安装、配置、培训等。
6. 运维和维护阶段
在软件交付后继续监控和维护系统,包括故障修复、性能优化、版本更新、用户支持等。
需要注意的是,SDL的具体流程可以根据项目和组织的需求进行定制和调整。以上是一个通用的SDL流程框架,可以根据实际情况进行组合和拓展。
8.2 典型的SDL流程框架:
8.2.1 培训 | 开发团队的所有成员都必须接受适当的安全培训
所有 Microsoft 员工都必须完成一般安全意识培训和适合其角色的特定培训。 初始安全意识培训在员工时提供给新员工,在 Microsoft 的整个工作期间都需要进行年度刷新培训。
开发人员和工程师还必须参与特定于角色的培训,让他们了解安全基础知识以及安全开发的最新趋势。 还鼓励和提供所有全职员工、实习生、特遣队工作人员、分包商和第三方的机会,以寻求高级安全和隐私培训。
涉及的培训内容主要如下图所示:
8.2.2 要求 | 如果数据在传输过程中没有加密,就有可能被截获、篡改:
Microsoft 开发的每个产品、服务和功能都从明确定义的安全和隐私要求开始;它们是安全应用程序的基础,并告知其设计。 开发团队根据产品将处理的数据类型、已知威胁、最佳做法、法规和行业要求,以及从以前的事件中吸取的经验教训等因素来定义这些要求。 定义后,将明确定义、记录和跟踪要求。
软件开发是一个持续的过程,这意味着关联的安全和隐私要求在整个产品的生命周期中发生变化,以反映功能和威胁环境的变化。
8.2.3 设计 | 采用HTTPS对通信数据进行加密,以保障数据的保密性:
定义安全性、隐私和功能要求后,软件的设计就可以开始。 作为设计过程的一部分,将创建威胁模型,以帮助根据风险识别、分类和对潜在威胁进行评分。 对软件进行更改时,必须在每个产品的生命周期内维护和更新威胁模型。
威胁建模过程首先定义产品的不同组件,以及它们如何在关键功能方案(如身份验证)中相互交互。 数据流图 (DFD) 创建,以直观地表示所用的关键数据流交互、数据类型、端口和协议。 DFD 用于识别和确定添加到产品安全要求的缓解威胁的优先级。
开发人员需要对所有威胁模型使用 Microsoft 的Threat Modeling Tool,这使团队能够:
- 沟通其系统的安全设计
- 使用经过验证的方法分析安全设计的潜在安全问题
- 建议和管理安全问题的缓解措施
- 在发布任何产品之前,将检查所有威胁模型的准确性和完整性,包括缓解不可接受的风险。
8.2.4 实现 | 避免采用特定危险API如strcpy、sprintf避免缓冲区溢出漏洞:
实现从开发人员根据前两个阶段创建的计划编写代码开始。 Microsoft 为开发人员提供了一套安全开发工具,以有效实现他们设计的软件的所有安全性、隐私性和功能要求。 这些工具包括编译器、安全开发环境和内置安全检查。
8.2.5 验证 | 通过动态构建SQL语句以证明对用户输入进行了严格过滤,避免了SQL注入攻击:
在发布任何书面代码之前,需要进行多次检查和批准,以验证代码是否符合 SDL、符合设计要求且没有编码错误。 SDL 要求手动评审由独立于开发代码的人员的审阅者进行。 职责分离是此步骤中的重要控制措施,可确保同一人无法编写和发布任何代码,从而导致潜在的意外或恶意伤害。
还需要进行各种自动检查,并内置于提交管道中,以便在签入期间和编译生成时分析代码。 Microsoft 使用的安全检查分为以下类别:
- 静态代码分析:分析源代码是否存在潜在的安全缺陷,包括代码中存在凭据。
- 二进制分析:在二进制代码级别评估漏洞,确认代码已准备就绪。
- 凭据和机密扫描程序:标识源代码和配置文件中可能的凭据和机密公开实例。
- 加密扫描:验证源代码和代码执行中的加密最佳做法。
- Fuzz测试:使用格式错误和意外数据来练习 API 和分析器,以检查漏洞并验证错误处理。
- 配置验证:根据安全标准和最佳做法分析生产系统的配置。
- 开源治理 :开源软件检测和检查版本、漏洞和法律义务。
如果手动审阅者或自动化工具在代码中发现任何问题,则会通知提交者,并且在再次提交以供审阅之前,需要对其进行必要的更改。此外,内部和外部提供商定期对 Microsoft 联机服务进行渗透测试。
8.2.6 发布 | 入侵者通过JSP程序提交上传了页面文件,清除木马程序并提供整改建议:
- 集成环境测试
- 最终安全评审
通过所有必需的安全测试和评审后,生成不会立即发布给所有客户。 在安全部署过程( Safe Deployment Process,SDP)中,生成会系统地逐步发布到更大和更大的环。 SDP 环的定义如下:
- Ring 0:负责服务的开发团队
- Ring 1:所有 Microsoft 员工
- Ring 2:Microsoft外部的用户已将其组织或特定用户配置为位于目标发布频道
- Ring 3:分阶段的全球标准版本
每个环中的内部版本保留在负载周期较高的适当天数内,但除Ring 3 外,因为已对早期环中的稳定性进行了适当的测试。
8.2.7 响应
发布后会广泛记录和监视所有 Microsoft 服务,并使用集中专有近实时监视系统识别潜在的安全事件。
- 定期安全评估
- 应急响应
- 发布漏洞解决方案
SDL全过程图示如下:
以上感谢!