企业安全之SDL体系初步探索

前言

在甲方已经工作了一段时间，在做测试的过程中，也看了一些关于安全体系的文章，下面是我对SDL体系的一些初步了解，分享出来与大家共同探讨。

SDL简介

SDL(security development lifecycle)是安全开发生命周期，侧重于软件开发的安全保证过程，构建更安全的软件同时降低开发成本。

SDL的核心理念就是将安全考虑集成在软件开发的每一个阶段：需求分析、设计、编码、测试和维护。从需求、设计到发布产品的每一个阶段每都增加了相应的安全活动，以减少软件中漏洞的数量并将安全缺陷降低到最小程度。

SDL体系一般使用于传统的瀑布式开发，其需求比较固定，流程较长。

SDL目的

过去，企业应对安全问题往往是在上线前甚至上线后通过人工渗透测试、自动化安全扫描等方式发现漏洞，然后反馈至开发人员修改。这种方式存在下面的问题：

1）开发人员修复漏洞的周期长、成本高；

2）问题发现滞后，可能会限于当下技术而搁置安全问题；

3）同样的安全问题频繁出现，安全维护成本居高不下。

SDL就是为了解决这种问题，将安全集合在开发的每个阶段，尽早发现安全漏洞，尽早测试，降低修复安全漏洞的成本。

微软SDL流程

为了应对这些问题，不同企业或组织都提出了SDL模型，目前微软的SDL模型可以说是应用更广泛的一种，接下来一起来看看微软的SDL模型。

从下图可以看出，SDL分为了培训，需求，设计，实施，验证，发布，响应阶段。

流程没有好坏之分，关键是要适合公司的状态，因此，在实际操作的过程中，不可能完全与上面的流程相同，要根据公司的实际情况进行改变。

安全培训

培训是最基础的一部分，旨在提高开发团队全体人员的安全意识，这有利于后续的操作。培训应该当做是一个常态化的工作来做，每周或每个月都应该组织安全培训。

开发和测试团队对安全管理工作的理解和支持是SDL体系顺利实施的基础，因此必须重视人员培训，精心开展相关人员培训工作。

目标：提高团队安全意识，减少安全风险发生

培训对象：开发人员，测试人员、项目经理、产品经理等

培训内容：常见的安全漏洞，不安全的组件列表，不安全函数等等

难点：开发人员时间不易协调

需求&设计

这里将需求和设计放到一起，对应的开发流程中的设计阶段。

根据微软的SDL流程，这里有一个非常重要的事情，那就是威胁建模，但是随着业务功能的暴增以及越来越多的业务运营转向数字化，威胁随之增多，仅解决所有高优先级威胁变得非常耗时，更耗费大量的人力和物力。因此往往成了一种样式，没有深入的做下去。

当前较为流行的威胁识别模型是由微软提出的基于面向过程的STRIDE安全威胁模型。STRIDE模型将威胁主要分为6个类别，分别是Spooling（仿冒）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、Dos（拒绝服务）和Elevation of privilege（权限提升）

目标：缩减攻击面，发现设计阶段的安全问题，威胁建模

具体实施：

1）分析需求文档，参与需求评审，将需求中可能出现安全问题的点指出来并给出解决方案。如促销活动如何避免被薅羊毛。

2）隐私风险评估，分析项目中可能出现的隐私问题并提出改进措施，避免隐私问题。

3）分析系统存在的攻击面，并设计测试方案。

4）确定技术方案使用的框架的安全性

难点：

1）缺乏自动化工具，如威胁建模不能自动化完成，那么就需要花费巨大的人力

2）人手不足，安全人员没有精力去做每个需求的安全性分析

实施

我理解的实施阶段就是在程序员开发的过程中能够发现部分安全问题，并修复。这样可以将一些比较容易发现的安全问题由程序员自行进行处理，降低了漏洞修复的成本。如是否使用了危险函数，是否使用了有漏洞的组件等等。

同时，在提交或者合并代码时能自动进行代码审计。代码审计的时候会出现误报，这就需要在运营过程中不断的优化规则。

这部分尽可能通过自动化工具去完成，减少人工的参与。

目标：在开发过程中检测出安全风险并修复

具体实施：

1）对代码进行静态安全检查(sast)，开发将代码提交到仓库以后通过工具进行扫描。也可以通过与IDE插件形式与集成开发环境结合检测代码漏洞，如findbug插件。

2）严格控制第三方和开源组件的来源，避免使用有安全问题的组件。可以使用的工具有dependency-check等

难点：

1）开发过程中频繁更改，不容易跟踪

2）SAST工具误报率普遍在30%以上，误报在一定程度上会降低工具的实用性，需要花费更多的时间来清除误报。

验证

验证阶段也就是我们常做的测试阶段，这个阶段就需要我们从多个方面去验证系统的安全性。

目标：通过各种方式发现系统中存在的安全问题并改进

具体实施：

1）黑盒扫描（DAST）：通过人工或者工具进行测试，发现系统中的安全问题。常用的工具有awvs,appscan,代理扫描等

2）安全测试：对各个功能进行测试，找到安全问题并记录。这个阶段测试是肯定需要手动完成的，但是问题的记录和后续跟踪需要平台支撑，这样即方便记录同时也方便后续的查看追踪，数据统计等工作。

3）代码审计：采用人工与工具结合的方式进行代码审计，发现系统中存在的安全问题。可以使用的工具有fortify,cobra等等。

发布

经过了前面的几个步骤，系统的安全性已经基本可以得到保证，发布时需要在做一遍最终安全评审（FSR）并且进行发布归档，制定应急计划，以防运营阶段出现安全问题时可以快速响应。

最开始我一直以为只要前面的步骤做好了，发布时再过一遍安全评审是没有必要的，可直到有一次发现实际上线的版本和我们安全测试的版本不一致，才意识到发布时再过一遍是非常有必要的。

目标：最终安全评审，发布归档

具体实施：

1）检查上线版本与测试版本是否一致，防止回退版本上线。

2）检查第三方组件没有存在安全漏洞

3）对上线应用进行归档，整理使用的组件等资产，以便后续进行排查

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

5）发布后在进行一次渗透测试，防止生产环境配置出现问题

难点：

1）设置卡点，会影响应用发布，加大测试与运维的沟通

响应

经过了上面的全部步骤，上线以后依然有可能存在安全问题，当软件发布后遭受攻击时，根据制定的应急响应计划快速采取措施，把事件造成的损失降到最小。

目标：持续监控系统状态，保证应用安全

具体实施：

1）对项目运行当中的活动日志和异常情况及时更新，对数据库、中间件和系统状态进行持续监控及上报。

2）一旦出现安全问题，快速进行问题定位、漏洞分析和修复处理，同时做好漏洞修复、版本更新、负载过度等安全事件的应急预案。

3）监控使用组件是否出现新的安全风险，一旦出现安全风险迅速响应

难点：

1）开源软件出现漏洞时无法快速定位

SDL面临的挑战

SDL流程的需要多个部门的协作，因此在实施时会遇到各种各样的问题：

1）实施SDL导致整个流程线延长，安全开发软件所需的时间也随之延长，但碍于项目交付时间有限，最终会导致安全在活动中流于形式。

2）公司内部开发流程混乱，没有一套明确的流程，导致SDL推动不下去

3）安全人员与开发人员很难做到充分沟通

4）自动化工具建设不足，导致需要大量的人工

在SDL体系建设初始，总是会遇到各种各样的问题，可以先从最简单的开始做起，在逐步进行推进。一定要注意自动化检测的建设，这样能节省巨大的人力成本。

同时，SDL建设过程中，充分的沟通也是必不可少的。

总结

上面以微软的SDL为例，说了一下每个步骤大概怎么去做，但是每个公司面临的场景都不相同，因此具体实施起来可能就要根据实际情况去做。SDL体系最终需要在企业内部推广和运行，因此对于不满足企业业务特点的方面，企业需要及时调整，以适配业务。

由于本人水平有限，文章中可能会出现一些错误，欢迎各位大佬指正，感激不尽。如果有什么好的想法也欢迎交流

原文始发于微信公众号（信安路漫漫）：企业安全之SDL体系初步探索