Ywc

SDL安全开发流程

Word count: 4.1k / Reading time: 14 min
2019/06/15 Share

SDL简介

SDL是什么

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

SDL能解决什么问题

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

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

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

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

SDL的七个步骤

1、培训

开发团队的所有成员都必须接受适当的安全培训,了解相关的安全知识。培训对象:开发人员、测试人员、项目经理、产品经理;培训内容:安全设计、威胁建模、安全编码、安全测试、隐私等。

2、安全要求

2.1确定安全计划

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

2.2 设立安全基线和安全分级

安全基线用于确定安全风险的最低可接受级别,安全分级用于定义安全漏洞的严重性阈值。例如,应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。安全基线和安全分级一经设定,便绝不能放松。

2.3安全和隐私风险评估

对系统可能面临的威胁、存在的弱点、造成的影响,以及三者综合作用所带来风险的可能性的评估,量化系统遭受攻击带来的影响或损失的可能程度。

安全风险评估(SRA)和隐私风险评估(PRA)是一个必需的过程,用于确定软件中需要深入评析的功能环节。包括:

① 项目的哪些部分在发布前需要建立威胁模型?

② 哪些部分在发布前需要进行安全设计评析?

③ 哪些部分需要由不属于项目团队且双方认可的小组进行渗透测试?

④ 是否存在安全顾问认为有必要增加的测试或分析?

⑤ 模糊测试的具体范围?

⑥ 隐私对评级的影响。

3、设计阶段

3.1设计要求

在设计阶段应仔细考虑安全和隐私问题,在项目初期确定好安全需求,尽可能避免安全引起的需求变更。

3.2减小攻击面

减小攻击面与威胁建模紧密相关,不过它解决安全问题的角度稍有不同。减小攻击面通过减小攻击者利用潜在弱点或漏洞的机会来降低风险,减小攻击面包括:关闭或限制对系统服务的访问,应用“最小权限原则”,以及尽可能进行分层防御。

减小攻击面与威胁建模紧密相关。它通过减少攻击者利用潜在弱点或漏洞的机会来降低风险,包括关闭或限制对系统服务的访问,应用“最小权限原则”,尽可能分层防御。

3.3威胁建模

微软的 STRIDE 模型。所谓STRIDE为Spoofing(假冒),Tampering(篡改),Repudiation(否认),Information Disclosure(信息泄漏),Denial of Service(拒绝服务),Elevation of Privilege(提升权限)。此乃微软的安全建模的模型,微软的产品就是基于它考虑安全问题的哦。STRIDE模型几乎是可以涵盖现在世界上绝大部分的安全问题。下面给上STRIDE模型对于安全属性的图

4.实施阶段

4.1使用指定的工具

开发团队使用的编辑器、链接器等相关工具,可能会涉及一些安全相关的环节,因此在使用工具的版本上,需要提前与安全团队进行沟通。

4.2弃用不安全的函数

许多常用函数可能存在安全隐患,应当禁用不安全的函数和API,使用安全团队推荐的函数。

4.3静态分析

静态分析可以帮助软件开发人员、质量保证人员查找代码中存在的结构性错误、安全漏洞等问题,从而保证软件的整体质量。

5.验证阶段

5.1动态分析

动态分析是静态分析的补充,用在程序运行时,测试验证程序的安全性,也称作“黑箱测试”。通过模拟黑客行为对系统进行动态攻击,分析系统的反应,从而确定该系统是否易受攻击。

5.2 模糊测试

模糊测试是一种特定的动态分析方法,通过故意向应用程序引入不良格式或随机数据诱发程序故障。测试策略的制定以应用程序的预期用途、功能、设计规范为基础。

5.3 威胁模型和攻击面评析

项目因需求变更等因素导致最终产出偏离原定目标,为此项目后期有必要对威胁模型和攻击面进行重新评析。

6.发布阶段

6.1事件响应计划

SDL要求约束的每个软件在发布时都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的产品,也可能在日后面临新出现的威胁。需要注意的是,如果产品中包含第三方的代码,也需要留下第三方的联系方式并加入事件响应计划,以便在发生问题时能够找到对应的人。

6.2最终安全评析(FSR)

最终安全评析指在产品发布之前对软件执行的安全活动,对比安全基准确定产品不符合安全基准、缺少功能和其他要求的区域,然后进行以下三种决策:

1) 通过FSR。在FSR过程中确定所有安全和隐私问题都已得到修复或缓解;

2) 通过FSR但有异常。在FSR过程中确定所有安全和隐私问题都已得到修复或缓解,并且/或者所有异常都已得到圆满解决。无法解决的问题将记录下来,在下次发布时更正。

3) 需上报问题的FSR。如果团队未满足所有SDL要求,并且安全顾问和产品团队无法达成可接受的折中,则安全顾问不能批准项目,项目不能发布。团队必须在发布之前解决所有可解决的问题,或者上报高级管理层进行抉择。

6.3 发布/存档

在通过FSR或者虽有问题但达成一致后,可以完成产品的发布。但发布的同时仍需对各种问题和文档进行存档,为紧急响应和产品升级提供帮助。

7.响应

当软件发布后遭受攻击时,根据制定的应急响应计划快速采取措施,把事件造成的损失降到最小。这里还可以加入应急响应演练,以加强公司对抗信息安全攻击的能力。

SDL的步骤

安全培训

开发团队的所有成员都必须接受适当的安全培训,了解相关的安全知识,培训对象包括开发人员、测试人员、项目经理、产品经理等。

安全要求

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

质量门/bug栏

质量门和bug栏用于确定安全和隐私质量的最低可接受级别。
Bug栏是应用于整个开发项目的质量门,用于定义安全漏洞的严重性阈值。例如,应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。Bug栏一经设定,便绝不能放松。

安全和隐私风险评估

安全风险评估(SRA)和隐私风险评估(PRA)是一个必需的过程,必须包括以下信息:
1、(安全)项目的哪些部分在发布前需要威胁模型?
2、(安全)项目的哪些部分在发布前需要进行安全设计评析?
3、(安全)项目的哪些部分需要并不食欲项目团队且双方认可的小组进行渗透测试?
4、(安全)是否存在安全顾问认为有必要增加的测试或分析要求已缓解安全风险?
5、(安全)模糊测试要求的具体范围是什么?
6、(安全)隐私影响评级如何?

设计要求

在设计阶段应仔细考虑安全和隐私问题,在项目初期确定好安全需求,尽可能避免安全引起的需求变更。

减小攻击面

减小攻击面与威胁建模紧密相关,不过它解决安全问题的角度稍有不同。减小攻击面通过减小攻击者利用潜在弱点或漏洞的机会来降低风险,减小攻击面包括:关闭或限制对系统服务的访问,应用“最小权限原则”,以及尽可
能进行分层防御。

威胁建模

为项目或产品面临的威胁建立模型,明确可能来自的攻击有哪些方面。

使用指定的工具

开发团队使用的编辑器、链接器等相关工具,可能会涉及一些安全相关的环节,因此在使用工具的版本上,需要提前与安全团队进行沟通。

弃用不安全函数

许多常用函数可能存在安全隐患,应当禁用不安全的函数和API,使用安全团队推荐的函数。

静态分析

代码静态分析可以由相关工具辅助完成,其结果与人工分析相结合。

动态程序分析

动态分析是静态分析的补充,用于测试环节验证程序的安全性。

模糊测试(Fuzzing Test)

模糊测试是一种专门形式的动态分析,它通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定,以应用程序的预期用途,以及应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试,或者扩大模糊测试的范围和增加持续时间。

威胁模型和攻击面评析

项目经常会因为需求等因素导致最终的产出偏离原本设定的目标,因此在项目后期对威胁模型和攻击面进行评析是有必要的,能够及时发现问题并修正。

事件响应计划

受SDL要求约束的每个软件在发布时都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的产品,也可能在日后面临新出现的威胁。需要注意的是,如果产品中包含第三方的代码,也需要留下第三方的联系方式并加入事件响应计划,以便在发生问题时能够找到对应的人。

最终安全评析

最终安全评析(FSR)是在发布之前仔细检查对软件执行的所有安全活动。通过FSR将得出以下三种不同不同结果。
1、通过FSR。在FSR过程中确定所有安全和隐私问题都已得到修复或缓解。
2、通过FSR但有异常。在FSR过程中确定所有安全和隐私问题都已得到修复或缓解,并且/或者所有异常都已得到圆满解决。无法解决的问题将记录下来,在下次发布时更正。
3、需上报问题的FSR。如果团队未满足所有SDL要求,并且安全顾问和产品团队无法达成可接受的折中,则安全顾问不能批准项目,项目不能发布。团队必须在发布之前解决所有可解决的问题,或者上报高级管理层进行抉择。

发布/存档

在通过FSR或者虽有问题但达成一致后,可以完成产品的发布。但发布的同时仍需对各种问题和文档进行存档,为紧急响应和产品升级提供帮助。
从以上的过程可以看出,微软的SDL的过程实施非常细致。微软这些年来也一直帮助公司的所有产品团队,以及合作伙伴实施SDL,效果相当显著。

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

SDL实战经验准则

准则一:与项目经理进行充分沟通,排除足够的时间

准则二:规范公司的立项流程,确保所有项目都能通知到安全团队,避免遗漏

准则三:树立安全部门的权威,项目必须由安全部门审核完成后才能发布

准则四:将技术方案写入开发、测试的工作手册中

准则五:给工程师培训安全方案

准则六:记录所有的安全bug,激励程序员编写安全的代码

学习文章

SDL的各个阶段
SDL的深入探究及实践
SDL探索之路
精简版SDL落地实践
值得读的书籍securitypaper关于SDL
SDL建设-三方依赖库扫描系统

CATALOG
  1. 1. SDL简介
    1. 1.1. SDL是什么
    2. 1.2. SDL能解决什么问题
  2. 2. 项目生命周期中存在的问题
  3. 3. SDL的七个步骤
    1. 3.1. 1、培训
    2. 3.2. 2、安全要求
    3. 3.3. 3、设计阶段
    4. 3.4. 4.实施阶段
    5. 3.5. 5.验证阶段
    6. 3.6. 6.发布阶段
    7. 3.7. 7.响应
  4. 4. SDL的步骤
    1. 4.1. 安全培训
    2. 4.2. 安全要求
    3. 4.3. 质量门/bug栏
    4. 4.4. 安全和隐私风险评估
    5. 4.5. 设计要求
    6. 4.6. 减小攻击面
    7. 4.7. 威胁建模
    8. 4.8. 使用指定的工具
    9. 4.9. 弃用不安全函数
    10. 4.10. 静态分析
    11. 4.11. 动态程序分析
    12. 4.12. 模糊测试(Fuzzing Test)
    13. 4.13. 威胁模型和攻击面评析
    14. 4.14. 事件响应计划
    15. 4.15. 最终安全评析
    16. 4.16. 发布/存档
  5. 5. SDL实战经验准则
  6. 6. 学习文章