Gartner 2017调研报告:DevSecOps应当做好的十件事(上)

背景介绍

惨痛的教训告诉我们:DevSecOps很重要!

对于很多企业而言,云和DevOps是推动企业业务发展的关键的技术引擎。企业的IT、安全和开发人员都知道在云和DevOps环境中,有大量的敏感信息(如密钥和凭据)需要保护。尽管大部分人都有安全方面的意识,但我们仍能看到诸多的数据泄漏事件。

以最近发生的Uber数据泄露事件为例:

“11月22日,Uber发布声明,承认2016年曾遭黑客攻击并导致数据大规模泄露。根据这份声明,两名黑客通过第三方云服务对Uber实施了攻击,获取了5700万名用户数据,包括司机的姓名和驾照号码,用户的姓名、邮箱和手机号。”

对于面向消费者的企业而言,信任是企业顺利发展的一个重要组成部分。然而,不幸的是,最近几年,企业或机构发生用户信息泄露事件正在变的越来越普遍,引发的危害及潜在的破坏不可估量。

调查发现,Uber数据泄露的原因竟然是工程师将解锁数据库的安全密钥被存储在GitHub的一个可以公开访问的页面。媒体将称作是“In major goof”(超级傻瓜)的失误。

然而,这类由于操作不当引发数据泄漏的事件并不是孤案,尤其值得注意的是,当今云环境和DevOps的迅速发展导致安全风险显著地提高了。安全公司 Detectify 的安全顾问 FransRosén 曾于今年 7 月 13 日发布一份报告称“网络管理员经常忽略 AWS 访问控制列表( ACL )规则,因服务器错误配置而导致大量数据泄露。

在网络急速发展的大数据时代,很多企业都贯彻着“敏捷”的思维和行动,这是一个危险的信号,而且正在不断的被验证着:越来越多的消费者、监管机构和市场发现由此所造成的数据泄漏的代价是高昂的、无法接受的。由于数据泄漏,你可能会看到市场资本中一夕之间损失数亿美元、消费者对企业和机构的信任度下降,在某些情况下,高管们的职业生涯可能会结束或停滞不前。毫不夸张地说,一些依赖数据生存的企业甚至可能在无意中因为一个密钥存储的疏忽而使整个企业面临灭顶之灾,至少竞争对手不会放弃这些机会。

事实上,通过实施最低限度的特权,很多数据泄露事件都是可以提前预防的。接下来,我们将重点讨论一下DevSecOps的概念,以及企业想要成功实行DevSecOps应采取的十项有效措施

DevSecOps的概念

DevOps是Development和Operations的缩写,而DevSecOps则是Development、Security和Operations的缩写。John Willis(DevOps Cookbook合著者之一)称Patrick Debois是DevOps的缔造者,而DevOps的传道者们认为,DevSecOps的基本理念是让每一个解决方案、开发测试的多个跨部门协作人员都融入开发运维和安全的理念,并正确地理解DevOps的做法与含义。也就是说DevSecOps是一个项目组织方式,因此并不不存在DevOps者,更不是说将开发环境和生产环境整合在一起的意思,DevSecOps是一个群体做法,核心理念是:“安全是整个IT团队(包括开发、运维及安全团队)所有成员的责任,需要贯穿整个业务生命周期(从开发到运营)的每一个环节。

将安全整合到DevOps的“DevSecOps”会带来思维方式、流程和技术的整体变化。安全和风险管理的领导者,必须坚持合作,DevOps的敏捷性意味着其在开发过程是无缝的和透明的,同理,“DevSecOps”中的“安全”也应当是沉默的。

企业在执行DevSecOps时通常会面临以下几个方面的挑战:

  • 作为一名安全或风险管理人员,应当很清楚企业的业务发展是核心,因此向客户提供新的IT功能的产品开发团队才是王道,而不是信息安全或IT团队。
  • 信息安全工作必须适应开发过程和相应的工具,而不是背道而驰。
  • 组织使用DevOps生产新的应用和服务,DevOps相关的过程和工具也有责任遵照公司对其他应用程序的要求,产生安全且符合要求的代码。
  • 要求应用程序达到百分百地安全是不现实的,企业一旦陷入“将安全漏洞的数量降为零”的错误追求中,安全测试的负担识别加重,且很可能成为业务发展的一个障碍。

因此,问题的关键是风险的控制和管理,而非单纯的追求安全。想要确保应用程序和数据安全,在进行安全和风险管理(Security and risk management,SRM)时,应当注意:

  • 将安全和合规测试无缝地整合到DevSecOps中,使开发者专注工作在持续集成和持续部署工具链环境中。
  • 持续的扫描已知的漏洞和配置错误,对象包括所有开源的和第三方组件。理想情况下,管理并维护一套完整的资产清单,便于完成对所有软件组件的分析。
  • 不要尝试删除自定义代码中所有未知的漏洞,相反,应把开发人员看作放在最严谨和最自信的人。
  • 鼓励尝试使用新的工具或方式,以减少与开发人员的摩擦,例如使用交互式应用安全测试(IAST)来取代传统的静态和动态测试。
  • 把信息安全团队完美地融入DevOps进程中。
  • 使用相同的统一的规范来处理所有自动化脚本、模板、图像和设计,并保证安全工作覆盖了所有的源代码。

企业对DevSecOps的战略规划

Gartner 分析师的调查结果显示:

  • 2019年,超过70%的企业将实施DevSecOps的相关举措,实现针对开源软件和商业软件包的自动化安全漏洞和配置扫描,2016年这一数据低于10%。
  • 2021年,80%的快速发展团队将实践DevSecOps的举措,2017年这一数字为15%。

当今,DevOps已经成为企业IT能力快速发展和持续交付的首选方法,正确的实施DevOps对企业发展至关重要。

尽管大多数情况下,DevOps未能合理的处置安全性和合规性的问题,但值得高兴的是,企业越来越重视这一情况,根据Gartner的调查数据显示,在受约束的环境中实施DevOps,最优策略是与信息安全紧密结合,如下图所示:

*来源:Gartner(2017年10月)

在过去的一年中,Gartner的调研数据显示,“如何安全地将安全性集成到DevOps中(即交付DevSecOps) 一直是客户感兴趣的领域中关注度遮增长最快的结点之一,Gartner的分析师们进行了600多次的调查,不断的与不同的客户进行交流,沟通他们在DevSecOps方面实施了那些卓有成效的举措,通过分析这些案例,总结出了十项最佳实践,SRM的领导者如果想要成功的交付DevSecOps,可以优先考虑这些方法。

成功交付DevSecOps的十条建议

(1)使您的安全测试工具和过程能够很好的适应开发人员,而不是背道而驰

DevOps的哲学植根于它打破了传统IT领域的陈规,打通了开发和运营的脉络,然而,安全是另一个需要被移除和整合的领域。如果能正确的实施,DevSecOps里的“安全”应当是静默的,换句话说,DevSecOps的目标应该是尽可能的将“安全”无缝并透明地交付给开发者。

不要强迫DevOps开发者去适应信息安全的传统过程,相反,应当有计划的持续性的将安全无缝地集成到开发者的持续集成/持续部署(CI / CD)的工具和流程中。对于那些习惯于迫使开发人员遵从我们的流程的信息安全专业人员来说,重要的是要转变心态,因此有必要进行一些调整,例如:

  • 不要使开发者离开他们熟悉的工具链环境。这意味着你的安全测试需要集成到开发者的开发环境(IDE)和CI/CD工具链的工具中(如Jenkins、Bamboo、Microsoft Team Foundation Server、Chef、Puppet 或Ansible)。
  • 集成安全扫描,使信息安全专业人员不需要再扫描应用程序,例外情况下,才需要信息安全人员提供援助。应尽可能做到,一切对开发人员来说都是自动化的和透明的。
  • 通过应用编程接口(API)构建安全性和合规性扫描平台,而不是通过安全厂商的本地控制台。测试结果应在通过你自己开发的仪表板来呈现(例如Sonar、Maven 或 Jenkins)。因此,要求所有安全扫描工具和服务都完全API化。
  • 使用威胁建模工具作为非功能性需求的一部分,自动化简单的收集所有新增应用程序的安全需求。
  • 通过开发者现有的漏洞跟踪过程(如JIRA或BugTraq),解决检测到的安全问题。
  • 改变心态,将一次性的安全扫描转化成连续地安全保证过程,从项目一开始就将安全集成进去,并评估每一次新的迭代。

(2)不要试图在开发过程中消除所有漏洞

有一句流传了几百年的格言,后来因伏尔泰的推崇而闻名:

Il meglio è nemico del bene (Pescetti)

Le mieux est l’ennemi du bien (Voltaire)

这句话的意思是“完美是好的敌人/完美是效率的敌人”,其所揭示的寓意放到现在依然适用,尤其是在数字化商务领域,在那里,“信息安全驱动完美”的安全理念与企业和开发者对速度和敏捷性的需求往往是不一致的。

没有完美的安全,零风险是不可能的。对于DevSecOps而言,我们要做的是持续的风险和信任评估以及对应用程序漏洞进行优先级排序。为了消除应用程序可能存在的所有漏洞,我们将会放慢开发人员的进度,寻找那些不是真实的(误报)的问题,或者解决真正的、但不是直接或容易利用的低风险漏洞,无疑是在浪费开发人员的时间。

在测试速度、浪费开发者时间(误报和假阴性风险增加)之间需要权衡。实施DevSecOps时,信息安全人员必须接受:“零漏洞”既不可能也不可取,尤其是当它明显阻碍了新服务开发和创新步伐的时候。

此外,我们可以通过使用运行时保护控制来补偿已知的、较低风险的脆弱性或未知的脆弱性的剩余风险:

  • 基于网络和主机的入侵防御系统(IPS)(以防止对已知的操作系统和软件包的攻击)。
  • Web应用防火墙(WAF)。
  • 运行时应用程序自我保护。
  • 将应用程序性能监视和应用程序安全监控融合在一起。
  • 使用合适的僵尸网络缓解方案。
  • 在应用层进行深度防御,包括负载均衡、拒绝服务和分布式拒绝服务保护。

思考并处理应用安全问题时,通过DevSecOps持续改进应用程序的开发和运营过程。需要明确,我们不需要消除开发过程可能存在的所有漏洞,运行时保护措施是DevSecOps战略的重要组成部分。DevSecOps是一个需要不断完善的过程,如下图所示:

*来源:Gartner (2017年10月)

安全不应止步于开发阶段(上图的左侧),整个DevOps生命周期都需要保护,包括新服务的部署后的运行阶段(上图的右侧)。安全,就像开发一样,成为一个连续的交付、学习和改进的过程。

在开发过程中执行基于风险的扫描,被接受的一些漏洞将运行时的持续评估来进行补偿。总之,如果没有监管方面的缺陷,那么可以接受多少风险并不取决于信息安全,而是由产品/服务所有者最终做出的商业决策。

(3)首要任务是识别并移除已知的严重漏洞

现代软件是组装而成的,而不是开发出来的。开发者们从公开可用的源代码和代码库(如GitHub,SourceForge,Maven central 和 Docker Hub)中收集并整合了大量的预编译组件、代码库、容器和框架(如Apache Struts和Swing)。自定义的代码在现代软件中所占的比例少之又少。

相应的,安全扫描的焦点也有所转移。大多数风险都可以通过识别这些公开库、框架和组件的已知的漏洞和错误配置来完成,问题解决之后才投入生产。从安全的角度来看,识别已知代码中已知的漏洞比自定义代码中的未知漏洞要容易得多。实现方式多种多样,最简单的一种方式是将文件与漏洞库相匹配。脆弱性评估供应商调整他们的扫描能力,将这些操作集成到DevSecOps中自动化的完成,诸如Docker之类的工具供应商也提供此类整合能力,这种最佳实践的重要性不能低估。Equifax公司因Apache Struts漏洞而遭遇数据泄露的教训十分沉重。

开源软件(OSS)提出了一个独特的挑战,因为开发人员可以简单地剪切和粘贴源代码,而不是关联整个库或框架。这样一来就不能简单地通过哈希值进行识别,,而是需要全面的扫描源代码本身。此外,OSS的使用可能因授权问题产生一些法律风险,因此建议使用商业软件组成分析(SCA)解决方案为应用程序构建详细清单,这个清单还有一个延长生命周期的好处,如果之后所使用的组件包含一个严重的安全漏洞,安全团队通过这份清单可以快速的查询并明确“哪些应用程序受到了影响”(例如,著名的Apache Struts或OpenSSL的Heartbleed攻击)。

评估应用程序已知漏洞的过程中,SRM负责人应该扫描:

  • 开发人员工作相关的全部内容(包括虚拟机、容器和机器镜像),应充分考虑容器安全及相应的最佳实践。
  • 所有嵌入的OSS代码的已知漏洞。
  • 所有的OSS组件(包括库和框架)。
  • 所有的操作系统文件、可执行文件和动态链接库。
  • 所有平台文件(如Apache和Microsoft IIS)。
  • 第三方商业性的代码库。
  • 第三方公共的应用程序(如SQL Server和Oracle)。
  • 与配置相关的漏洞(例如端口的打开/关闭、服务的激活和正在运行的进程)。

“扫描”的概念也应该扩展到识别恶意软件和敏感数据,而不仅仅是编码方面的漏洞。SRM负责人应该确保加密密钥和其他机密数据不会意外地嵌入到代码中。

(4)不要固守传统的静态/动态分析方法,应当适应新的变化

未完待续…

 

原创文章,作者:M0tto1n,如若转载,请注明出处:http://www.mottoin.com/107385.html

发表评论

登录后才能评论

联系我们

021-62666911

在线咨询:点击这里给我发消息

邮件:root@mottoin.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code