长亭百川云 - 文章详情

DevSecOps皇冠上的明珠-ASOC

安全产品人的赛博空间

65

2024-07-13

一、前言

很久没写点东西,最近因为一些工作需求,要写一点比较有新意和前沿的东西,结合自己做安全产品的经历,在DevSecOps领域发现ASOC这个方向国内鲜有人讲,因此有了这篇文章简单介绍下ASOC这个领域。

ASOC我刚看到这个单词的时候,相信跟很多人的反应一样,以为是“Application SOC”应用安全的SOC,但是其实全称是“Application Security Orchestration and Correlation”应用安全编排与相关性,从后续的研究来看,可能跟应用安全的SOC也差不多意思,但是更有一些偏重的方向和额外的新意。

为什么把ASOC叫做DevSecOps皇冠上的明珠,主要是因为ASOC的建设一般处于DevSecOps体系建设的后期,企业威胁建模、SAST、SCA、IAST、DAST等各种工具集成、流水线运转基本完善后,进一步考虑增加DevSecOps体系的效率与漏洞质量的时候,才会试图建设ASOC平台。就像叠金字塔,需要下面的底座建设完善后,才能开始叠最上面的部分,这也并不是意味着ASOC是一个多好的方向,反而越基础的安全建设市场需求量越大,但是做好一个ASOC平台比做单品肯定要难不少,所需要产品经理对DevSecOps的理解也确实比做AST中某个单独工具要高,所以我们可以看到国外做ASOC方向的厂家并不多,主要是专门做DevSecOps方向的安全厂商在做完其他AST工具后,才开始涉足此方向,进一步完善自己的产品体系。

二、ASOC的定位

ASOC的概念在2019年Gartner的成熟度曲线中首次被提出

ASOC方向是结合了ASTO(应用安全测试编排)和AVC(应用安全漏洞相关性)两个方向,ASTO与AVC的概念均是2018年成熟度曲线正式提出,但是AVC方向在更早17年就有相关的分析报告了,并且Gartner貌似对“重构漏洞修复优先级(VPT)”这个点非常看好,很早就连着在AVC、RBVM、TVM三个方向中都提到了,可能修不完的漏洞早已成了大家的共识吧,必须区分一些优先级出来。

ASTO与AVC的概念正式提出一年后快速合并为ASOC,个人认为主要原因还是AVC方向的模糊性,虽然说AVC强调多数据源的漏洞关联分析,并没有强调在哪个阶段,但是提到AVC方向的主要还是开发安全厂商,貌似“开发安全工具之间的漏洞关联分析”才变成了AVC的定义,并且既然提到多数据源关联分析,那么数据源肯定需要聚合到一个平台上,这就跟TVM纯正的漏洞管理方向又比较重合,再加上现在TVM厂商也是被卷的没办法了,想各种创新能力,早就做到了多数据源关联分析,因此既然一方面AVC面临TVM厂商的合并,另一方面市场实践认为AVC在开发阶段做可能更合适,那么干脆就与ASTO一起合并成了ASOC方向。

以我对AST这个领域的了解,这么做还是非常有必要的,“建设一个DevSecOps的统一管控平台”已经成了大家的共识,统一管理统一分析可以带来更低的使用成本,以及在数据中挖掘一些更高级的内容,这个产品在市场已经是这么实践的了,已经发生了,但是这个事情迟迟没有一个明确的产品方向,估计Gartner也看到这一点,那就赶紧搞个ASOC做大一统,所以我前面说即使你把ASOC理解成“Application SOC”也没有太大的问题,方向上类似,只是细节不同。

但是多数的ASOC厂商只是做到了统一管理,做的好一些的做到了自由工具编排,如何从数据中挖掘更多的价值,只看到了小部分的实践,并没有太多令人惊喜的地方,跟安全运营领域的SOC产品对数据的挖掘程度相比还差不少。

三、ASOC的核心能力

既然ASOC是由ASTO和AVC两个方向合并而成,ASOC的核心能力自然而然就是这两个方向核心能力的并集,向上统一管控各类开发安全工具,向下统一对接DevOps各类工具,提供自动化流程编排与工具编排能力,流程与数据统一管理、统一输出,不同数据源漏洞的关联分析,重新对漏洞危险等级排序,提供漏洞修复优先级建议等。

3.1 应用安全测试编排(ASTO)

应用安全测试编排(ASTO)其所要解决的最主要的问题是,AST工具分类安全需求、威胁建模、SAST、IAST、SCA、DAST、模糊测试等越来越多,企业可能光是开发安全阶段的扫描工具就有十几种,这些工具都需要与CI/CD平台集成,并且不仅仅是流水线平台,还涉及到跟DevOps工具集成,如果我们把需要互相对接的工具连一条线,这就组成了一个庞大的网状结构,异常复杂,漏洞数据可能可以通过漏洞管理平台统一管理,但是工具的管理就必须一个个工具去看了,这带来了巨大的使用成本。

那么怎么解决?就像网络通信中的HUB,加一个集线器就好了,ASTO就是充当这个集线器的作用,向上统一管控各类开发安全工具,向下统一对接DevOps各类工具,把网状结构变成中心发散的结构,大大降低了复杂性,当然这也意味着ASOC平台需要进行大量的集成适配,能够对接各类开发安全工具,同时梳理清楚每个安全工具可以与哪些DevOps过程中的开发工具对接,包括流水线对接,在这些复杂的对接之上,包装出一个简易的可视化操作页面,这其实是很考验产品功底的。在拥有这么一个工具后,企业引入安全工具只需要把安全工具对接进入ASOC平台中,然后在ASOC平台中进行一些配置,工具就可以应用到DevSecOps流水线中了。

所以在定义中说道“ASOC工具应该充当应用开发与安全测试工具之间的管理层”,这么做的好处不仅仅在于降低成本,当所有工具都在一个平台中管控的时候,对比安全运营领域就像ASOR一样,平台开始具备一定的编排调度能力,ASOC平台也可以通过编写剧本的方式,规定AST工具在什么时候执行,获得什么样的输入,得到什么样的输出,输出到哪里等等这些工作,在仔细观察MAVERIX产品所展示的图的时候,可以看到例如OSA(开源软件分析,类似于现在的SCA)安全过程不止是在Build阶段进行,而是在Code、Test等不同阶段都有,通过剧本编排可以很比较方便的完成AST工具在不同阶段的调用。

同时在ASOC平台上,也会去集成所有安全活动流程,例如安全需求审核流程、完整的漏洞管理流程、软件上线安全审批流程等,当流程编排与工具编排碰到一起的时候,带来的就是比较极致的灵活性与自动化,当然这部分做好也非常难,需要足够灵活,才可能适配企业的各种情况,这么说可能太抽象,举一个具象化的例子来说明此过程的好处,例如

(1).ASOC调用SAST扫描源码发现漏洞,由于SAST漏洞的误报率过高,安全运营人员通过ASOC筛选漏洞结果,将特别高危的某些类型,或者某些比较准确的规则爆出的漏洞输出到BUG管理平台,其他的漏洞待定

(2).BUG管理平台上,研发修复漏洞后更改状态,漏洞状态反向同步到ASOC,ASOC发现漏洞状态为“研发修复”后,再次调用SAST进行复测,标记是否“修复成功”

(3).进入到IAST测试阶段,IAST发现的漏洞带有执行函数与数据流,若发现数据流基本一致的漏洞,ASOC平台对比数据流,自动给漏洞打标上“SAST检出、IAST检出”的标签,代表该漏洞可信度高,若该漏洞之前SAST未推送到BUG管理平台,那么综合SAST的代码信息与IAST的数据流信息,一同推送到Bug管理平台;若已经修复,那么就不再重复推送。

这么一个过程是企业比较常规的漏洞管理过程,但是这其中什么时候调用工具、工具结果如何比对、如何避免重复推送漏洞,没有ASOC平台的情况下,免不了企业需要进行工具二次开发工作,这个也是ASOC所带来的价值。

3.2 漏洞相关性(AVC)

应用安全漏洞相关性,主要是把不同来源的漏洞信息,聚合进行分析,进一步确认漏洞的真实性,提供给用户最佳的修复优先级建议,如下这张图大致解释了AVC所做的事情

要搞清楚AVC能做什么其实也很简单,把每个AST工具所能输出的信息整理一下,发现其中的交叉点,就是可以重点进行关联的地方,例如上文例子中提到的,IAST可以获得运行时最精准的数据流,反编译可以得到代码信息,SAST可以获得程序分析推断出的数据流,如果入口点、执行点、漏洞类型一致,是不是大大提高该漏洞的有效性,毕竟两个工具交叉验证均存在,同时也避免不同工具的相同漏洞重复推送的问题,当然,Gartner所认为的漏洞关联分析,也貌似仅限于此,我们自己有一些更深入的思考,在下文中介绍。

值得一提的有两个地方,一方面是数据源不仅仅是AST工具输出,还可以是威胁情报和业务数据,这就类似RBVM的意思,不过威胁情报多在事件型漏洞如SCA输出的CVE漏洞中起作用。另一个方面,这些漏洞的输出也不仅仅是输出到BUG管理系统,在DevSecOps中也强调与Ops上线后阶段的联动,例如:选择暂缓的漏洞,输出到具备虚拟补丁功能的WAF或者RASP中,或者漏洞与安全运营过程结合,攻击这使用A攻击手法,且资产上正好有A漏洞,那么这条事件就应该提高优先级来处置,等等。

四、超出定义之外的思考

在研究了ASOC方向和相关产品实现后,深入思考这个方向,还能够发现很多可做但是没人做的事情,我思考的核心点是,只能做漏洞数据的互相关联吗?AST工具的输出只有漏洞数据吗?AVC仅仅只是做一些漏洞的去重,关联不同工具的结果吗?

很快我就给出了否定的答案,继续思考也让我看到了一些难以解决的问题的曙光,单工具困于误报率、漏报率问题久久不能解决,其核心问题是“工具自身是有能力壁垒的”,单工具就限定了分析方法比较单一,单一的分析方法决定了这个工具的分析上限,以前我们做SDL经常说的一句话是“不同工具有自己擅长解决的漏洞问题是不一样的”,反过来说也一样“不同工具有自己不擅长解决的漏洞问题”,但是厂商永远是希望它尽可能解决所有问题,导致误报漏报居高不下,例如我看到甚至有用SAST做逻辑漏洞检测的,这误报能不高吗?例如SCA工具就是通过版本匹配得出漏洞的,业界都是这个思路,所以报出的组件漏洞,不确定能否真实利用。这就是我所说的工具的能力壁垒,也是思想的壁垒。

这里只列举一些我看到过在国外产品上已经实现了的功能,更多我自己思考的,并且已经基本验证过可行的,这里就不写出来了,因为可能会涉及到我们自己做的后续产品方向,比较敏感。

4.1 打破壁垒的化学反应1-代码覆盖度

IAST的一个常见问题是,由于IAST一般是靠测试人员点击触发,所以测试覆盖度是一个比较大的问题,为了解决这个问题,IAST厂商都有识别API覆盖度的功能,那再进一步,代码覆盖度能不能做?以前没见到过哪个厂家做这个事情

超出漏洞本身去考虑,上文提到的一个问题,AST工具的输出只有漏洞数据吗?SAST只输出漏洞的数据流吗?不是的,做过SAST就知道,SAST是基本要做全部代码的数据流构建的(当然也有从危险函数反推的),那么SAST是可以输出全文的数据流的;IAST所输出的也不仅仅是漏洞是数据流,IAST可以把每条请求代码执行的数据流记录下来(可能反编译会有点误差,但是问题不大),那么把这两个数据流一对比,是不是就可以知道本次测试的代码覆盖度了?甚至SAST还能分析出哪些是新增代码,哪些是新增数据流,进而得到本期新增功能的测试代码覆盖度

上图是Code Dx在这个方面上的实践,SAST的分析结果用树状图展示出来,IAST有测试到的数据流,用额外颜色进行标记,从而得到代码覆盖度。

4.2 打破壁垒的化学反应2-函数可达性

SCA工具最大的问题之一,是无法确定爆出来的CVE是否可被真实利用,原因是SCA就是通过版本匹配得出漏洞的,业界基本都是这个思路,所以报出的组件漏洞不确定能否真实利用。如何去解决?或者有没有想过如何解决?还是做产品都人云亦云,业界是这个方案那我们也用这个方案,这最简单了。

我看国内近两年也有很多做SCA的创业公司,SCA入门的门槛低,好产品化,做到60分不难,做到90分是非常难,但是这些公司的产品看着能力都差不多,如何确定漏洞真实性、准确的二进制成分分析这些难点问题,没有人去解决,依然是难点,做出的产品都雷同。(腾讯前段时间发了具备二进制分析的SCA,还是比较厉害的)

函数可达性,是用以解决SCA无法确定CVE漏洞真实可利用的一个实践思路,如下图所示,是SNYK对此问题的探索,比业界做的跟进一步的是,他们收集了CVE漏洞的触发函数,给每个CVE漏洞标记一个漏洞函数,这个工作量不小,CVE描述中并不是所有的都描述了漏洞函数,这是一个堆人工的活。

有了CVE对应的漏洞函数后,利用SAST所分析的数据流,寻找哪些数据流上存在此漏洞函数,再向前推断数据流,入参变量是否外部可控,如果发现了外部可控变量到CVE漏洞函数的路径,那么就将此漏洞标记为Reachable,意味着该漏洞函数是可达的,该CVE漏洞很大可能是可被利用的。

五、结语

Gartner定义漏洞关联分析主要指不同数据源的漏洞数据,但是我认为这里的数据不应该只是狭义的漏洞数据,应当包括各类AST工具产生的如威胁模型、请求数据、数据流信息(SAST产生的推断数据流、IAST产生的真实数据流)、代码上下文、组件信息等等,把这些数据深入分析,进行联动对比整合,才能够得到一些如我们上面所举例的更高级、更有价值的结果,以此来解决更多AST领域现存的难点问题,例如SAST的误报率居高不下、IAST如何保证覆盖度、SCA如何确定漏洞真实可利用等。一个真正优秀的ASOC产品,可能在这个星球上还没出来,这个方向也是鲜有人去涉足的。

我们以前做安全产品,很多都是直接抄国外产品的理念与实践,这个其实无可厚非,北美的安全市场比国内领先大概5年,可以说先抄再根据国内实际情况做优化落地是最快的路径,但是这个过程走多了,抄着抄着也觉得没啥意思了,写这篇文章也是抛砖引玉,希望能引发更多人在这个相对未知方向上的思考和研究,万一真正优秀的ASOC是国内先做出来的呢?谁都说不准,可以有点理想,进行一些微小的工作。

相关推荐
关注或联系我们
添加百川云公众号,移动管理云安全产品
咨询热线:
4000-327-707
百川公众号
百川公众号
百川云客服
百川云客服

Copyright ©2024 北京长亭科技有限公司
icon
京ICP备2024055124号-2