其他分享
首页 > 其他分享> > DevSecOps 三问:Why?What?How?

DevSecOps 三问:Why?What?How?

作者:互联网

DevSecOps 三问:Why?What?How?

作者 | 宗良

编辑 | 济萌

作者简介

DevSecOps 三问:Why?What?How?

宗良

文思海辉 信息安全助理副总裁

现任文思海辉信息技术有限公司全球信息安全与风险办公室信息安全助理副总裁,负责文思海辉全球信息安全内控,以及对外的集成安全服务。15年以上从业经验,对软件开发/测试,服务与项目管理,信息安全与风险管控,质量与流程体系,培训体系与培训实施等多个方面都有深入理解与实际操作。

序言

随着 DevOps 的实际应用不断发展,Faster & Faster 的产品发布推陈出新,一个很严峻的问题有待解决:如何确保在快速迭代、快速发布过程中的产品安全,尤其随着《网络安全法》等一系列法律法规的完善与发布,这一问题已经上升到刑事责任而非过往的民事责任的高度。

安全与 DevOps 的整合已经迫在眉睫,本分享将就这一方面,介绍相应的 DevSecOps 的实际实施经验。

本文的三个部分:

1、Why DevSecOps;
2、What is DevSecOps;
3、How DevSecOps。

一、Why DevSecOps

1.1、传统的 SDLC 与传统的应用安全

DevSecOps 三问:Why?What?How?

首先跟大家的分享的是传统的 SDLC 与传统的应用安全。在整个传统的瀑布生命周期里面,大家可以看到运维是排在最后的,那么这跟安全存在什么样的关系呢?

通过上图,我们可见在运维过程里打相关的安全补丁是运维人员最常遇到的,也是最需要做的日常工作。

但是,实际上运维相关的安全工作并不是只有一个安全补丁。在打相关的安全补丁之前,还存在着许多工作,如:安全需求调研、安全设计工作、安全代码规范工作和安全测试。
1.2、敏捷模型对应的应用安全

DevSecOps 三问:Why?What?How?

下面我们讨论一下安全和敏捷是如何有效的结合的。首先是威胁建模和脆弱性检测:

故此,就需要用脆弱性检测这个方法预先找到漏洞。这个就意味着:你在一开发的过程中,需你要合理的考虑未来连接通道等等可能带来的问题。

接下来是两个测试——静态应用安全测试和动态应用安全测试。

最后是软件安全修复和安全代码培训。

1.3、标准的 DevOps 与应用安全

DevSecOps 三问:Why?What?How?

在 DevOps 整个运行过程中,持续集成和持续发布变得越来越快了,但足够安全么?

下面讲述一个真实的案例。我们有一个客户运用了 DevOps 系统,并且干的非常棒,从原来的每三周发一个大版本到现在基本上每天出76个版本。

但是,在安全方面系统持续地爆出来各种各样安全通知;然后,他的上级安全主管部门觉得他的安全管理非常差就给他发了一则安全整改通知并让其进行专项整顿。

那么在这个 Faster&Faster 的过程中,他做了测试、开发、检查;但是,他没有将安全特性融入进去,其后续的很多版本的 SQL 注入,跨站、中间人劫持这些最基本的安全问题都没有很好地进行修补。

对于上述的问题,我给大家讲几个概念:

1、SecOps:它的核心理念是自动化,其次是运营,同时把安全作为自动化的方式融进去。但是,EMC 公司本身没有特别好的产品,所以只是把这个作为一个服务方式来介绍给他公司的客户。在这个服务推出来以后,在当时也算业界相对比较领先的安全服务了。

2、SecDevOps:它产生时间是2015年8月17日,是偏向针对主机层的一个安全运维的专家服务。它的核心理念是早期风险建模,即上述讲到的威胁建模就是 SecDevOp。因此一定要在早期引入,越早期引入越好。

3、DevSecOps:它最主要的提出者是 SANS。SANS 是目前全球最大的安全的公益性、非商业化组织。对于 DevSecOps,SANS 在2016年3月发布一份白皮书。它的核心理念就是安全和 DevOps 实现共存和共赢,两者要整合在一起。

将威胁建模、安全早期的引入和信息安全融合在一起,这是我们深入地讲到的 DevSecOps 这个东西了。

二、What is DevSecOps

2.1、DevSecOps 的概念

DevSecOps 三问:Why?What?How?

在这个 DevSecOps 过程中,核心的思想内容就是用红色标注出来的部分:一个是自动化,第二个是内嵌整合。那么在整个过程中,我们会深入地看到几个东西:

  1. 威胁建模。威胁建模是整个 DevSecOps 里最重要的以及最核心的一个部分。对于威胁建模,我们会在后面章节还有详细的叙述。

  2. 整合集成。它就是把安全的各种活动作为一个整体集成在一起;同时把安全作为其中的一个基因整合或融入到 DevSecOps 的整个生命周期中。

在这个过程中,围绕开发的角度和运维的角度来看,会有很多的课题。这些课题有的是从安全的角度解决,有的是从安全的角度只能给出建议。

但是,不管是建议,还是解决的方式,或者是处置,那么它所带来的结果是什么呢?最常见的一个就是当我们发现问题的时候:

2.2、DevSecOps 聚焦

DevSecOps 三问:Why?What?How?

从 DevSecOps 聚焦的角度来看,这张图会很大,但是我们主要就是聚焦:文化、员工、产品、流程和技术,并且将安全融合进去。

2.3、DevSecOps = DevOps + Security Embedded

DevSecOps 三问:Why?What?How?

在本节,我首先给大家三个重要的提示:

这三个重要提示是整个 DevSecOps 里面最核心的问题。

为什么说这三者是最核心呢?首先,自动化的测试是在自动化和 DevOps 过程中,将安全基因整合进去。再则,持续测试其实是你要有策略的进行测试达到 TRUST。

TRUST 这个词在海外非常认可的,整个建设 TRUST 的过程中,最基本的就是威胁建模,无论何种情况下它会告诉你可能面临哪些安全隐患、威胁或者风险。

有朋友提到在没有与因特网连接的情况下,还有安全威胁吗?一个客户有A、B、C三个网络,A类网络与因特网没有物理上的直接连接,B类与因特网之间通过网闸进行逻辑隔离,C类网络是通过传统的防火墙进行逻辑隔离。

我们去审查客户环境的时候,客户问了一个问题:“我这个A类网络里面,你觉得还有必要进行安全防护吗?”。我回答他这需要从两个有两种可能性角度去看。

上述这个例子就揭示了我们为什么会需要威胁建模?威胁建模不仅要从应用本身来考虑,还要考虑应用所在的主机和中间件等等。因为这是最基本的部分,它带来的就是安全设计。这意味着一个良好的设计可以减少很多的安全隐患。而安全设计在我们的很多的过程中,并不会被那么重视,不管在架构中,还是在算法中。

接下来说说安全的测试。它有很多内容:第一个是 SAST,第二是 DAST。在这个过程中,我们把安全作为基因持续集成到开发和测试。这时候会出现一个问题就是在怎么样的情况下使用什么样的安全策略,比如我们有很多的版本(大版本、小版本、里程碑版本),以及安全测试的强度不一致的问题。同时,我们一定要挑出其中跟版本最有关联的,使其在安全本质上保持一致。

例如:在全球,我们有一个调查机构叫 Verizon。它每年会出一个叫全球数据泄露调查的报告。在2016年的数据泄露调查报告里面,此机构做了一个在全球范围内的统计:“97%的漏洞是来自于我们每年经常看到的 OWASP Top 10” 。

OWASP Top 10这个漏洞会在安全测试的时候成为我们进行安全分级策略的一个重要输入来源。也就是说,对于小版本而言,我们只测这10个漏洞有没有最基础的呈现就可以了。它就相当于功能测试里最基础的冒烟测试。

如果这个都不能过,就不用考虑版本发布的事宜了。但是对于大版本或是重要的里程碑而言,我建议不要只测这10个漏洞了,还需要参看两个数据(一个是讲全球漏洞的 CVE,另一个是讲***方式的 CAPEC)。如果你的产品偏向于应用层,我建议你看 CAPEC;如果产品偏向于网络层,我建议看 CVE。

对于开发过程来说,我们非常建议的是要进行安全状态的评估。很多的客户在做开发的时候会有缺失,也就是说他们做了检测,甚至做的威胁建模,但是却没有做安全状态的评估。

所以,当生命周期走到发布的时候,就无法判定能否发布,因为不知道这个版本有没有安全隐患以及安全隐患会不会造成影响。其实这个问题产生的根源在两个部分:

如果我们做好上述这些的话,自然就能得出一个是否是安全的定论。然而,安全测试里面除了要做 SAST 和 DAST,还有 FUZZ 和法律法规的检测等等。由于出台国家网络安全法,所以我们必须要对策略合规性进行合理的考虑(这个合规是合法法律,规是指行政法)。

最后,我要将的就是***测试了。***测试是模拟***进行***的一个测试。从我个人观点来说,***测试还是很有意义的。但是,大家需要注意的是:随着网络安全法的出台,不管是甲方组织进行***测试,还是乙方去做***测试,都一定要注意合法合规。简答来说,合法合规的***测试是需要进行报备授权的,也就是说:有报备的叫***测试,没报备的叫******或者被定性为破坏计算机系统罪行。

总结一下,上述我们主要谈论到了三个地方。

DevSecOps 是什么?是把安全嵌进去了,融入在其他,这才是它真正的核心,这才是它真正的价值所在。

三、How DevSecOps

DevSecOps 三问:Why?What?How?

在整个DevSecOps过程中,存在四个问题:

  1. 如何设计你的 DevOps 整体的框架,然后把安全融进去;

  2. 安全怎么整合;

  3. 自动化配合 Self-Driven 自驱动;

  4. V&V 就是质量保证和质量控制。

因此,我们需要更多检测系统和更多的相关东西,并将这些作为一个整体融在一起,那怎么融?我个人建议,有三种方式:

3.1、安全的自动发布特性和安全控制特性

DevSecOps 三问:Why?What?How?

上图是一个很典型的自动化发布的模块架构。在这个自动化模块的架构里面,安全放在在哪里?没有的话,就是会带来种种的问题。因此,我们需要一个安全的自动化发布,并考虑把安全性融进去。这就意味着在一起规划时候,你就要将安全性考虑进去。
DevSecOps 三问:Why?What?How?

3.2、实例问题感悟

DevSecOps 三问:Why?What?How?

下面讲一个真实的案例。我们有一个客户上了 DevOps 系统后感觉非常棒。因为,他从原来每三周发一个大版本到现在每天出76个版本。数据显示上很厉害,但是安全方面持续地爆出来各种各样安全通知,然后上级主管部门觉得这个客户安全管理的怎么这么差,就给他发了一则整改通知,叫专项整顿。

虽然,他做测试、开发、检查了,但是他跟安全的特性没有融进去,然后很多的版本,SQL 注入,跨站、中间人劫持这些最基本的问题,甚至包括前段时间的想哭病毒,他们都有轻微的感染现象。

后来我们帮助客户上了 DevSecOps 干,并且我们跟客户一起去搞。最后的结果,他的76个应用系统、232个发布单元,全部实现了对应的 DevSecOps。有人问具体工具怎么做的:首先,商业化工具,其实也就那些大家熟悉的譬如 Fortify、AppScan 之类;此外,用了一些开源的工具;最后,就是也会自研一些东西,自研的东西一定结合客户场景和应用、实际环境。

3.3、DevSecOps 未来可以整合的元素

DevSecOps 三问:Why?What?How?

对于 DevSecOps 的未来从个人角度说,我认为有六个地方是需要与整个 DevSecOps 进一步深度结合的:

总之,这六个趋势都可以独立和 DevOps 或 DevSecOps 进行整合,同时也可以拆分开来分别整合到 DevSecOps 中去。那么这些趋势的本质是什么?本质是我们需要跟上持续的潮流。

比如,五年前在中国你跟人讲 DevSecOps,99%的人会问什么叫 DevSecOps?而今天你跟人讲 DevSecOps,5%的人可能已经在做了 DevOps,剩下80%的人是了解一部分内容的,剩下15%的人才是对 DevSecOps 一窍不通的。

END

标签:What,DevSecOps,安全,一个,建模,DevOps,How,测试,Why
来源: https://blog.51cto.com/15127503/2660478