推荐!IAST如何赋能企业开发安全?看悬镜李浩这4条就够了

原创
2020/08/03 14:36
阅读数 930

 

2020年6月16日起,安在讲堂公益直播第三季,即网安强中强——2020网络安全产品及创新技能直播大赛全新开启,以新技术、新产品、新解决方案的分享传播为侧重,意图呈现当下中国网络安全的新生力量,“乙方”亮相,一展风采。

2020年7月23日 ,安在特邀悬镜安全高级技术工程师李浩做客直播间,以“IAST如何赋能企业开发安全”为主题,和网络安全从业者分享悬镜安全的解决方案。

 

(注:本期文章所有内容皆可在千聊“安在讲堂”直播间回看,公益讲座,全部免费。)

 

截至统计时:

收看直播人数:967

讨论数量:47

签到人数:99

 

本次分享的内容主要分为四个部分。一是DevSecOps的由来,以及当前开发的背景和理念;二是为什么IAST是最佳的选择,事实上,IAST可以解决政企用户不同开发测试场景下的精准应用安全测试问题;三是具体分享IAST技术的实现原理,完善的IAST解决方案需要同时支持以下几种主流模式:运行时插桩模式、流量代理/VPN 模式、流量镜像模式等;四是分享悬镜安全的客户实施案例,以便大家能够更好的理解IAST,基于深度学习技术的新一代交互式应用安全测试平台-悬镜灵脉IAST,覆盖企业各类型测试场景,已为金融、能源、政务、教育及医疗等行业用户提供了创新灵活的智适应安全管家解决方案。

一、SDLC与DevSecOps

 

上图展示的是传统的业务应用标准SDLC流程,覆盖了需求分析、架构设计、编码实现、测试、上线和运营等完整的生命周期。而在SDLC流程中,我们会发现安全主要是通过人工进行接入,依赖于有经验的安全人员来把控整个流程,导致应用落地的周期比较长。

在实际落地过程中,企业为了加快应用的上线进程,往往会采取先上线后补安全的措施,安全能够发挥的作用十分有限,而有限的安全资源和传统上线的安全手段也会制约业务敏捷交付,因此,企业需要改进业务流程以便能够让安全更好地发挥作用。

随着业务的发展,业务开发模型发生变更,迭代周期更短、更加自动化,传统安全工具面临着新的挑战。

在早期的瀑布流开发模式下,安全往往是在开发阶段之后引入。例如开发完之后通过白盒进行代码审计,应用上线之后利用黑盒进行漏扫以及人工渗透进行审计,因此必然存在流程阻断的时间成本。

随着业务的不断发展,瀑布流开发模式显得有点笨拙,敏捷开发、DevOps等模式开始出现,而在SDLC流程中使用的一些工具由于技术的原因,导致流程被阻断,业务被迫暂停,因此综合消耗巨大,不符合快速迭代的开发理念。

所以安全就慢慢的被排除在流程之外,长此以往的话,安全的作用就会慢慢淡化。但是安全是为业务服务,并且需要为业务的问题担责,所以安全的接入方式就必须有所改变,以便适应DevOps的开发模式。

其实,在DevOps模式下安全团队也比较尴尬,DevOps快速迭代和发展的过程中,安全因为缓慢的节奏被弃在一旁,整个流程中没有安全质量的考核和控制,安全团队对于安全质量无计可施。

因此,人人都对安全负责的DevSecOps模式随之出现,其核心理念——安全是整个IT团队(包括开发、运维及安全团队)每个人的责任,需要贯穿从开发到运营整个业务生命周期每一个环节才能提供有效保障。

 

企业建立建设人人都对安全负责的DevSecOps流程是大势所趋,在这个过程中安全团队扮演专家的角色,更好地优化整个流程,而安全细节将由所有人共同完成,整个企业安全效率和质量,对安全的关注度都将全面提升。

 

之前已经提及开发流程落地的各个阶段都应该具备一些安全措施,在这些措施中很重要的一项就是构建工具链。不同的阶段需要不同的安全动作,也需要不同的工具支撑系统自动化运行。

下图就是悬镜安全提出的DevSecOps工具链模型。悬镜DevSecOps工具链模型根据悬镜安全专家多年的行业经验,充分考虑了安全措施的落地性和实用性,在不明显增加时间与经济投入的基础上,在全生命周期上保障软件应用的安全。

 

值得一提的是,悬镜DevSecOps工具链模型是在Gartner 模型的基础上,优化了每一环节上的安全方案,使全流程的安全性有了指数级的提高。

二、最佳实践IAST

前面咱们已经介绍了DevSecOps的理念和工具链的基本组成,但是在实际应用落地过程中,也有一些推荐的工具。例如RSA2018大会上就提出一个新的概念,叫做黄金管道,是指通过一套比较稳定的、可落地的、安全的方式自动化地适应CI/CD或者DevSecOps在公司外部平台的流水线模式。

 

因此,基于上面这张图我们可以看到,之前提到的工具链基本上已经对应起来了。总的来说包括几部分内容:AST应用安全测试,RASP运行时应用自保护,SAC第三方组件成分分析,红蓝对抗和SRC。在黄金管道中,AST就成为开发的一项关键技术,因为它更适合在开发测试阶段进行接入。

目前而言,传统的安全工具存在着各种各样的不足之处。例如SAST的误报率过高,导致在编码阶段必须投入安全专家进行误报排查。DAST不足之处在于拖慢DevOps进度、会产生脏数据、较难与CI/CD工具集成。

然而,想要选择一款适合DevSecOps的产品基本上要有以下的要求,分别是:

1.便于与CI/CD工具链集成,如代码仓库和自动化测试工具;

2.专业程度低,开发测试人员均可使用;

3.尽可能减少误报;

4.安全检测时间尽可能短;

5.安全检测透明化,覆盖各个场景,不对编码和测试过程造成影响;

6.漏洞信息可集成到开放测试人员常用平台;

7.尽可能提供自动化完成安全检查和结果展示接口;

8.安全产品可开放所有功能API。

根据以上的条件,综合对比多款产品和技术实现的方式,IAST是DevSecOps最有效工具之一。IAST交互式应用程序安全测试(Interactive Application Security Testing)是Gartner 2012年提出的一种新型运行时应用安全测试方案,规避了黑盒安全扫描DAST和白盒代码审计技术的主要技术缺陷,通过代理/VPN、旁路流量镜像、透明流量管家以及运行时插桩检测技术,实时监测应用漏洞触发执行情境,接近于零的误报率,漏洞触发点可定位到代码行,可回溯漏洞堆栈信息。

 

因此,IAST有着非常明显的优势,一是低门槛,无需专业技术背景,普通测试人员透明完成业务安全测试,二是低入侵,透明部署,不影响正常测试工作和用户使用流程,三是低误报及漏报。

 

在技术上我们常常问一个问题,黑盒、白盒到底有什么区别。我们简单进行了对比,具体结果如上图所示。

横向来看,误报率方面DAST比较低,SAST会高一些,IAST则是极低,因为它除了具备DAST的一些检测能力外,还可以通过代理/VPN、旁路流量镜像、透明流量管家以及运行时插桩检测技术,实时监测应用漏洞触发执行情境,所以误报率非常低,特定条件下甚至可以达到零误报。

检出率方面,DAST属于中等,SAST还是会高一些,因为SAST的优势在于能够做源码的覆盖,IAST是比较高,因为IAST比较依赖于测试人员的测试用例或者交互测试过程获取到的流量。如果测试人员的测试用例能够覆盖所有的功能,那么它能达到的覆盖面要比安全人员的人工深度测试的覆盖面多一些。毕竟安全人员更懂安全,但是测试人员更懂业务。

测试速度方面,DAST随URL/Payload的数据变化,SAST基于代码量,代码量越大检测速度就越低,IAST则依赖于点击实时检测,因为他可以通过被动污点追踪检测进行分析,如果在测试过程中发现了漏洞就可以实时报出来,具有一定的时效性。

此外,还有第三方组件漏洞、语言支持、框架支持、漏洞验证利用、使用风险、使用成本、漏洞详情、CI/CD支持、漏洞种类覆盖方面,DAST、SAST和IAST技术之间各有不同,具体分析的情况可以从上图中对比了解。

就单款工具而言我们很难判定哪款工具更好用,因为每款工具都有它出现的意义、时代背景和可适用的场景。

三、IAST技术原理

接下来分享的是IAST的技术原理。

前面咱们已经讲了,不管在哪个企业都有敏捷开发的需求,我们想要的就是将安全前置在开发层面。想要实现这一诉求,我们就需要适应各个类型的产品,使用比较完善的相互测试的技术方案等。

IAST交互式应用程序安全测试是一个测试方法,主要是流量技术和插桩技术。流量技术主要是通过代理、VPN、流量镜像、主机层流量、旁路流量镜像等技术获取相应的流量,模拟基于流量的中间人攻击,并进行漏洞利用演示。

插桩技术主要有主动型插桩检测和被动污点追踪检测两种模式,是基于函数运行时的检测,结合IAST的主动验证可以实现真正意义上的零误报。

接下来分享基于不同场景下的分析。

基于代理/VPN的测试场景,适合测试人员对单个网站进行深度渗透测试,不依赖测试系统语言环境,无须接入测试环境即可进行安全测试。比如我们要建设一个网站,测试人员最快上手的方式就是配个代理,代理配置完成后按照功能进行测试,不需要了解服务器的环境,因此接入成本最低。

 

基于流量镜像的测试场景,适合测试目标或部门之间存在隔离,无法清晰了解测试资产,通过在网络出口旁路部署流量镜像,透明无感知接入。简单来说,我们可以在交换机设备上部署安全设备,这样就可以获取相应的流量,并进行实时检测。

 

而在插桩的测试场景中,适合自动化或资产清晰便于部署微探针的情况下,提前在测试应用中间件上进行插桩,如基于Tomcat、SpringBoot等。其部署存在一定的成本,但是如果部署环境、用户环境比较统一,就可以实现自动化部署,弥补部署环节的成本问题。插桩测试的好处在于漏洞检测的效率比较高,可以做到实时检测,并且可以具体到某一行代码。

 

插桩技术的实现原理主要分为两种,一是主动型插桩,二是被动型插桩。

主动型插桩可配合扫描端的验证,对于已经验证的漏洞基本就是100%的漏洞,不存在误报。如果大家感兴趣的话可以看看我们悬镜CTO宁戈之前直播的视频(详情关注悬镜安全服务号,获取直播视频),里面非常详细地介绍了主动型和被动型插桩技术。

主动型插桩主要是扫描端发送Payload,然后插桩Agent在关键函数,获取上下文信息综合分析,再加上扫描端的配合,可进行漏洞利用、漏洞复现,检测出来的漏洞精度更高,更易于指导研发修复,覆盖一些流量检测特有的漏洞支持。缺点是需要进行重放流量,对于网络的要求比较高,无法处理签名加密接口。

被动型插桩,原理上是做污点分析,在目标应用程序运行的过程中实时跟踪监控,记录程序运行的变量和寄存器里的值,最终汇聚至污点汇聚点,如果中间没有经过无害处理,那么可以认为这是一个漏洞。

被动型插桩的优势是可处理签名、加密接口,无数据重放、无脏数据,缺点是污点丢失和 Sanitizer(污点清洁)未知,可能导致漏报和误报。

 

四、客户实施案例

第一个案例是某国有银行,其背景是为银行开发一个业务支撑平台的软件开发中心,以在线网站和移动应用为主,业务量非常多,安全的重要性毋庸置疑。

改造之前,开发中心一直使用的是传统的SDL研发模式,而且安全工作独立于研发体系,无法融合于研发过程,导致效果差、效率低下,质量反馈体系也不包含安全内容,安全质量无法持续改进,最终导致安全保障体系比较困难,因此想要对生产、研发模式进行改造。

改造之后,该国有银行上线DevSecOps研发模式,将安全工作与DevOps流程无缝结合,深度整合在研发过程的每一个环节当中,侵入感低、效果好、效率高。另外,安全漏洞与BUG一同成为质量反馈常规内容的一部分,安全质量持续改进。

第二个案例是某证券机构。他们原有的是一套比较完善的开发数据流程,这种流水线模式有一定的持续交付能力,但是仅依靠目前的流水线平台不能在上线前上或生产过程中进行自动化的安全测试,且无法保证后续的持续改进的能力。

在这个环境中,IAST主要是以工具方式接入,补充上线前的安全措施,并将安全前置,弥补公司前面没有做的安全测试覆盖。但是这样由于流水线控制的原因,自动化程度有限,仍然有部分是人工参与,整体流程还有提升的空间,所以进行了DevSecOps改造。

为了进一步提升业务能力,该公司通过实现自动化构建,结合容器化的部署,从而使业务能够快速迭代发布。当然这里不能缺少安全,因此客户主动进行了DevSecOps平台的建设,引入了相关的工具链。在这个业务中我们也要适应模式的变化,比如平台对接、或者把能力集成到平台上,将功能嵌入到现有的流程中,以及插桩、检测、安全测试等,最终在开发阶段形成自动化的流程。

最后一个案例是某银行卡联合中心,他们本身已经在开发设施阶段有完善的DevSecOps方案,也有一些工具链进行支撑,开发和安全团队的结合较为紧密,自动化引入后孤岛也被打破了,体系较为完善。

但是他们后续上线需要一个高频的部署和软件交付的系统,其中也有一些安全的威胁。他们系统里面每天都会有大量的应用上线,如何对这些应用做安全测试或安全验证就比较困难,单纯依靠人工肯定不行。

所以我们提供的是一个针对多条应用的流水线,以单个应用为目标进行持续的自动化渗透,对目标变更资产进行梳理,从攻击模拟的角度验证资产的完整性,也可以让安全测试人员做攻防模拟演练等,可以对一些特定的应用做深度的验证。

问答环节

1.李老师,使用了IAST之后,DAST还有没有使用价值?

前面咱们已经提及,任何的工具都有它出现的原因,早期安全还没那么成熟时,我们通过DAST能够解决大部分的安全问题。就目前阶段来看,IAST能够覆盖上线前的业务,但DAST也会有更高的要求,比如之前提到的批量应用上线或资产变更,我们也会引入一些流量或者资产变更检测等。

随着互联网攻防演练、渗透测试被提到一个新的高度,下一代的DAST就是自动化渗透测试的一个实践。其实不是DAST没有价值,而是DAST工具还需要进一步提升才能满足我们后续的要求。

2.IAST如何进行业务逻辑漏洞的检测?如水平与垂直越权漏洞?

因为业务逻辑的检测基础需要人工交互式的真实流量,可以测特定的网站,这样的流量就是真实的流量,并且是按照界面的逻辑有操作的。首先我要尝试识别这个操作到底是什么,比如要做验证码检测,我肯定要先识别验证码是怎么输入,短信怎么发送,场景识别之后再去进行验证,这样可以做到对业务逻辑的检测。

水平与垂直越权的检测不是很难,因为水平与垂直越权很大部分是根据业务来定,简单一点的水平垂直越权可以通过用户标识识别、通过接口识别的方式定位成一个操作,这样的话就能知道这是一个可能存在的越权点,然后再尝试验证。

3.你们IAST支持第三方组件漏洞版本检测么,如何做检测的?

可以支持,因为插桩是在中间件上插桩,在运行的时候就可以通过函数调用监控组件的加载,以此拿到组件的基础信息,并进行分析比对,发现一些高危的组件漏洞。白盒的话主要是静态检测,而IAST主要是监控它的加载,然后发现应用具体加载的组件。

4.李老师,IAST使用了之后,是不是就不需要SAST,DAST了?

这个问题前面也提到一点,整个技术叫做AST技术,并不是说试用了IAST就不需要SAST,DAST,它们之间谁都无法替代谁。白盒的技术阶段是在开发过程中,并且有源码,优势非常明显。单从覆盖面来看,白盒的覆盖面非常大,如果人力比较充足的情况下可以接受人工筛查。从攻击面和测试阶段来发现漏洞,它们的关注点都不一样,一个好的方案可以使用多个AST 技术,以便更好的发挥自己的优势。

5.IAST 如何解决脏数据问题? 毕竟是环境与测试共用,测试人员对脏数据会反感的吧?

脏数据是因为黑盒或流量检测方式会有中间人模拟攻击,因为攻击必定会有重放,重放就必定会有脏数据。但IAST的被动插桩技术就不会有脏数据,因为它没有重放,仅仅是跟踪污点传播检测漏洞,因此不会产生脏数据。

6.运维端的安全和开发安全怎么结合?

这需要自动化的安全生态级产品将开发和运维阶段的安全能力打通,形成完整安全闭环,可以关注下悬镜夫子。

7.IAST使用代理模式能检测安全组件吗?

IAST代理模式,可以通过扫描探测及网站返回的指纹信息,检测组件漏洞。

8.DevSecOps需求市场有多大?是否跟当前政企客户的DevOps落地程度,才会有DevSecOps的土壤,是不是只有大公司才会有预算来做?

我主要负责技术,这个问题由市场的同学来回答更合适些。但就我个人感受来说,现阶段,做DevSecOps的确实以大公司为主。

评委互动、打分、抽奖展示

 

 

 

 

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部