安全开发流程(SDL)
SDL:Security Development Lifecycle 安全开发生命周期
培训 | 要求 | 设计 | 实施 | 验证 | 发布 | 响应 |
核心安全培训 | 确定安全要求 创建质量门/错误标尺 安全和隐私风险评估 | 确定设计要求 分析攻击面 威胁建模 | 使用批准的工具 弃用不安全的函数 静态分析 | 动态分析 模糊测试 攻击面评析 | 事件响应计划 最终安全评析 发布存档 | 执行事件响应计划 |
1、培训
培训对象:开发人员、测试人员、项目经理、产品经理
培训内容:安全设计、威胁建模、安全编码、安全测试、隐私等
2、安全要求
项目确立前与项目经理或产品所有者进行沟通,确定安全的要求。
3、质量门/bug 栏
质量门和 bug 栏用于确定安全和隐私质量的最低可接受级别。项目团队必须协商确定每个开发阶段的质量门。bug 栏是应用于整个软件开发项目的质量门,用于定义安全漏洞的严重性阈值。
4、安全和隐私风险评估
安全风险评估(SRA)和隐私风险评估(PRA)用于确定软件中需要深入评析的功能环节。包括 ① 项目的哪些部分在发布前需要建立威胁模型?② 哪些部分在发布前需要进行安全设计评析?③ 哪些部分需要由不属于项目团队且双方认可的小组进行渗透测试?④ 是否存在安全顾问认为有必要增加的测试或分析?⑤ 模糊测试的具体范围?⑥ 隐私对评级的影响。
5、设计要求
在设计阶段仔细考虑安全和隐私问题。
6、减小攻击面
减小攻击面与威胁建模紧密相关。它通过减少攻击者利用潜在弱点或漏洞的机会来降低风险,包括关闭或限制对系统服务的访问,应用“最小权限原则”,尽可能分层防御。
7、威胁建模
微软的 STRIDE 模型
8、使用指定的工具
开发团队使用的编译器、链接器等工具及其版本应由安全团队确定安全性。
9、弃用不安全的函数
禁用不安全的函数或 API
10、静态分析
可以由工具辅助完成
11、动态分析
在测试环节验证程序安全性
12、模糊测试
模糊测试是一种特定的动态分析方法,通过故意向应用程序引入不良格式或随机数据诱发程序故障。测试策略的制定以应用程序的预期用途、功能、设计规范为基础。
13、威胁模型和攻击面评析
项目因需求变更等因素导致最终产出偏离原定目标,为此项目后期有必要对威胁模型和攻击面进行重新评析。
14、事件响应计划
每个软件在发布时都必须包含事件响应计划。尤其如果产品中包含第三方的代码,要求留下第三方的联系方式并加入事件响应计划。
15、最终安全评析
在产品发布之前对软件执行的安全活动。
16、发布/存档
在通过最终安全评析后可以完成产品的发布。同时,对各类问题和文档进行存档,为紧急响应和产品升级提供帮助。
SAMM:Software Assurance Maturity Model,OWASP 推出的软件认证成熟模型
参考链接:http://www.opensamm.org/
SDL 适用于软件开发商,他们以贩售软件为主要业务;SAMM 适用于自主研发软件的组织,如银行、在线服务提供商。软件开发商的软件工程比较成熟,有严格的质量控制;而自主开发软件的企业组织更强调效率。
敏捷 SDL
对于使用敏捷开发的团队,需求和功能一直在变化,代码也在发生变化,这要求在实施 SDL 的过程中在每个阶段更新威胁模型和隐私策略,在必要的缓解迭代模糊测试、代码安全分析等工作。
互联网公司 SDL 实践经验
准则一、与项目经理进行充分沟通,排出足够时间
准则二、规范公司的立项流程,确保所有项目都能通知到安全团队,避免遗漏
准则三、树立安全部门的权威,项目必须由安全部门审核完成后才能发布
准则四、将技术方案写入开发、测试的工作手册中
准则五、给工程师培训安全方案
准则六、记录所有的安全 bug,激励程序员编写安全的代码
产品研发阶段的安全
需求分析与设计阶段
需求分析阶段可以对项目经理,产品经理或架构师进行访谈,了解产品背景和技术架构,并给出相应的建议。
应该了解项目中是否包含了第三方软件,认真评估第三方软件是否存在安全问题。规避第三方软件带来的安全风险。
参考链接:https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet
开发阶段
提供安全的函数
OWASP 的开源项目 OWASP ESAPI 为安全模块的实现提供了参考。如果开发者没有把握实现一个足够好的安全模块,最好参考 OWASP ESAPI 的实现方式。(其中 Java 版本最为完善)。
很多安全功能可以放到开发框架中实现,这样可以大大降低程序员的开发工作量。
定制开发者的开发规范,并将安全技术方案写进开发规范中,让开发者牢记。在代码审计阶段,可以通过白盒扫描的方式检查变量输出是否使用了安全的函数。将安全方案写入开发规范中让安全方案实际落地,不仅方便开发者写出安全的代码,同时为代码审计带来方便。
代码安全审计工具
常见的代码审计工具对复杂项目的审计效果不好:① 函数调用是个复杂的过程,当审计工具找到敏感函数时,回溯函数的调用路径常常会遇到困难;② 如果程序使用了复杂框架,代码审计工具往往由于缺乏对框架的支持,从而造成误报或漏报。
代码自动化审计工具的一个思路:找到所有可能的用户输入入口,然后跟踪变量的传递情况,看变量最后是否会走到危险函数。
对于甲方公司来说,可以根据开发规范来定制代码审计工具 —— 并非直接检查代码是否安全,而是检查开发者是否遵守了开发规范。
测试阶段
安全测试应该独立于代码审计。有些代码逻辑较为复杂,通过代码审计难以发现所有问题,而通过安全测试可以将问题看清楚;有些逻辑漏洞通过安全测试可以更快地得到结果。
安全测试分为自动化测试和手动测试两种。
自动化测试可以通过 web 安全扫描器对项目或产品进行漏洞扫描:XSS、SQL Injection、Open Redirect、PHP File Include;CSRF、越权访问、文件上传等漏洞由于涉及系统逻辑或业务逻辑,有时需要人机交互参与页面流程,因此需要依靠手动的方式完成测试。