我们所说的SDL是什么?

SDL 全称 (Secure-Development-Lifecycle) 我们所说的安全开放生命周期

传统的软件开发生命周期,旨在满足功能和特性方面的要求,通常是为了满足某些特定的业务目标,但这时候就留下了看不见的安全隐患。

SDL 的介绍

SDL是一个广泛的安全解决方案和指南,提供有关一系列在开发中安全问题的解决方案和有用的信息资源,从Web应用程序安全性到信息和网络安全解决方案,再到移动和Internet安全解决方案这些都在SDL的囊括范围之内。

这个思想来源于微软提出的从安全角度指导软件开发过程的管理模式,是一种专注于软件开发安全保障的流程。

SDL能帮助我们解决那些问题

  • 设计、代码和文档等与安全相关漏洞减到最少
  • 在软件开发的生命周期中尽可能的早地发现相关漏洞
  • 实现保证最终的用户安全

项目中的安全风险

我们先看看一个项目应该经历的生命周期大致为:

  1. 需求分析
  2. 设计/建模
  3. 研发
  4. 测试
  5. 部署/上线

风险点

通过项目的开发流程来看,找一下其中存在的一些安全问题

  • 需求阶段: 缺少必要的安全需求介入,导致后续可能缺少必要的安全模块设计
  • 设计阶段: 设计阶段缺乏安全,导致系统架构缺陷后期难以修复,并且由于是整个项目的框架层面,如果一旦涉及到的业务多那么修复工作将是一件长期繁重的事情。
  • 研发阶段: 研发缺少安全意识,导致开发的代码存在安全漏洞。
  • 测试阶段: 测试阶段缺少安全测试覆盖,导致安全问题不能提前暴露
  • 部署上线: 攻击面完全暴露,攻击者总是能通过各种手段入侵成功

分析重灾区

从各大的SRC平台来看大多数的安全问题可能发现在:

  • 弱口令
  • Github/SVN 信息泄漏
  • 配置不当
  • 水平越权
  • XSS
    等等

从这些问题来看 绝大多数都是可以在开发阶段就遏制的,如果使用SDL良好的安全开发流程那么这些问题都能得到相应的解决。

SDL如果介入其中

按照微软的定义来讲大致是这样的
image

https://www.microsoft.com/en-us/SDL/process/training.aspx 这里是其中涉及到每一步的详细解释。

需求阶段

在需求阶段,安全性的最佳实践已集成到产品中。这些做法可能来自行业标准,也可能基于对过去发生的问题的回应。

其中有产品中实现的功能安全性要求,并包括SDL的所有活动。它们被用作落地的点,以确保正确考虑所有部分。
一个示例可能是产品必须强制实施最小密码长度为八个字符。但安全功能依然是从用户的角度编写的。

设计阶段

SDL的设计阶段包括在编写代码之前(希望)发生的活动。安全设计是关于量化架构(针对单个特征或整个产品)然后搜索问题。安全设计可以在正式文件或餐巾纸上进行。

在许多系统中,即使SDL半途中介入,但SDL也能够存活下来。关键是使用威胁建模。

威胁建模是思考特征或系统如何受到攻击的过程,然后在编写代码之前减轻设计中未来的攻击。

坚实的威胁模型了解功能或产品的攻击面,然后定义将在这些接口上发生的最可能的攻击。威胁模型与解决问题所包含的缓解措施一样好。但在此过程的早期识别安全问题至关重要。

研发阶段

编写安全代码,SDL包含程序员必须做的一些事情,以确保他们的代码最有可能是安全的。该过程涉及标准和自动化工具的混合。

在标准方面,一个可靠的SDL定义了一个安全的编码指南(例如SEI CERT for C,C ++和Java发布的指南),它定义了预期的内容,并为开发人员遇到特定问题并需要洞察力提供指导。

实现工具包括静态应用程序安全性测试(SAST)和动态应用程序安全性测试(DAST)软件。SAST就像是代码的拼写检查器,可以识别源代码中的潜在漏洞。SAST针对每晚构建运行,或者可以集成到IDE中。它可以在夜间找到并打开错误管理系统中的新错误,或者提示开发人员在编码时暂停以实时修复问题。

DAST检查应用程序的运行时实例化。它通过应用程序来查找所有可能的接口,然后尝试利用应用程序中的常见漏洞。这些工具主要用于Web界面。

测试阶段

正式测试活动包括安全功能测试计划,漏洞扫描和渗透测试。漏洞扫描使用行业标准工具来确定应用程序或产品是否存在任何系统级漏洞。

渗透测试涉及测试人员试图解决给定应用程序中的安全保护并利用它们。测试可以扩展产品并将其暴露给自动化工具无法复制的测试场景。测试是资源密集型的,因此通常不会针对每个版本执行。

最后阶段:发布/响应

当针对最终版本确认所有安全活动并将软件发送给客户(或可供下载)时,将发布版本。响应是外部客户和安全研究人员报告产品安全问题的接口。

部分响应应包括产品安全事件响应团队,该团队专注于分类和沟通产品漏洞,包括单个错误和需要行业协作的错误(例如,Heartbleed,Bashbug等)。

其他安全活动对SDL的成功也至关重要。这些包括安全冠军,bug赏金以及教育和培训。

是否有最佳实践

安全培训方面

实践方案:

  • 代码安全管理
  • 研发人员信息安全管理
  • 安全编码规范推行
  • 服务器配置安全规范培训

解决的问题:

  • 建立项目人员信息安全意识
  • 安全编码规范实施,提升研发同学的编码安全性
  • 安全规范实施文档,解决了运维同学部署的安全知识欠缺问题。

安全需求、设计

实践方案:

  • 认证安全设计解决方案
  • 权限安全设计解决方案
  • 关键操作安全设计方案:
    • 支付操作
    • 密码重置操作

解决的问题:

  • 统一解决方案,解决一处漏,处处漏问题
  • 解决了前期架构缺陷,导致后期修复成本过大,无限延 期问题
  • 专业化的安全设计,规避常见的逻辑缺陷

研发安全

实践方案:

  • 梳理语言及框架的安全缺陷
    • 语言特性引起的问题
    • 框架缺陷
  • 统一的安全封装代码库
  • 静态代码分析工具
    • 自研代码分析工具
    • 商业产品的使用

解决问题:

  • 自动化的代码安全转换,提升研发安全质量
  • 安全的代码库,保证模块防护的正确性
  • 研发过程中的代码安全检查,避免上线后才发现问题

安全测试

实践方案

  • 黑盒安全扫描系统进行检测
    • 安全自动化扫描平台
    • 浏览器扩展
  • 白盒代码安全审计

    • 《高级PHP应用程序漏洞审核技术》

    解决问题

  • 上线前的全面体检
    • 覆盖应用层的安全问题
    • 针对基础环境的基本梳理测试

线上安全评估

实践方案:

  • 安全评估面
    • 基础环境的安全评估
    • 应用层的安全评估
    • 信息管理层面的安全评估
  • 安全评估CheckList的推出

解决问题

  • 完全模拟黑客,提前发现黑客可能的攻击路径,并进行防御

应急响应

实践方案:

  • 安全资产梳理及情报收集机制
  • 安全产品部署
    • WAF
    • 自动化扫描
    • 入侵检测系统

解决问题:

  • 第一时间感知漏洞,并进行防御实施,规避漏洞给业务带来的影响
  • 能够第一时间针对受影响的资产进行安全防御。