本文整顿自 OSCS 软件供应链平安技术论坛- 边立忠(京蛰)老师的分享《蚂蚁供应链平安建设实际》。
边立忠,蚂蚁团体高级平安专家,蚂蚁团体利用平安产品中台负责人,次要负责蚂蚁 SCA、IAST、SAST、镜像平安扫描等供应链平安相干产品的建设和技术钻研。
大家好,我是边立忠,很快乐明天有机会给大家做一个软件供应链平安相干的分享。
我在蚂蚁次要负责 DevSecOps 的工具链,或者叫工具矩阵的建设,以及供应链相干的产品建设。所以明天带来的软件供应链平安建设除了囊括我团队负责的这一部分以外,还会囊括蚂蚁其余在供应链相干的建设的内容。明天我作为代表,整体来给大家做这样一个分享和介绍。
将从以下几个局部来进行分享:
- 蚂蚁供应链平安概述:危险、挑战、建设思路;
- 危险检测;
- 平安管控;
- 纵深进攻;
- Log4j经典案例:如何被应急响应、处理和管控危险
蚂蚁供应链平安概述
软件供应链平安领域
蚂蚁从供应链相干的危险来辨别供应链平安,对咱们理论的业务造成了平安影响,就把它定为一个供应链平安相干的领域。
蚂蚁以后最大供应链危险:代码的间接或间接依赖、三方软件。
间接依赖会间接影响业务可信,其中包含:
- 源代码
- 代码的间接依赖
- 运行时系统软件
- 容器镜像及OS
- 底层硬件设施
间接依赖间接影响业务可信,其中包含:
- 研发工具、平台
- 代码的间接依赖
- 制品下载散发平台
- 人、角色
- 制品更新平台
次间接依赖存在更多的攻打渠道,其中包含:
- 人所处物理环境
- 人应用的设施
- 人所在网络环境
- 间接依赖的上下游
- ……
随着蚂蚁整个利用的量级、业务的量级一直增长、一直收缩,间接依赖同样有着十分大的增长。在间接依赖自身增长的前提下,间接依赖和次间接依赖就会呈几何量级呈现爆发式增长。这种爆发式增长的上下游依赖,给咱们带来了难以穷举的防护指标。
然而从历史的 case 来看,其实蚂蚁供应链最大的危险一方面是来自利用的间接依赖和间接依赖,另一部分是来自于三方软件。所以说明天我的分享是会围绕这个领域来给大家开展。
软件供应链危险态势
第一,软件的下载量逐年出现快速增长。软件自身在增长的前提下,软件的量级增长,就会引入盘根错节的利用的供应链关系。
另一个是供应链的攻打事件。供应链的安全事件也在逐年呈指数级增长。并且它的攻打手法更加的荫蔽,影响范畴也更加宽泛。
以下列出了从 15 年到 21 年的比较严重或者说大家认知、感触比拟显著的供应链的事件。对于蚂蚁来说,从平安的维度供应链的危险分为两类,一类是破绽,另一类是供应链的投毒。那前面也是会围绕这两个方向给大家开展来做介绍。
蚂蚁供应链平安防护体系
对于应答破绽以及投毒的危险,蚂蚁是如何进行防护的 。
整个供应链平安防护体系次要分为三个局部(三位一体的防护体系),包含危险监测(发现危险)、平安管控(管制危险)以及纵深进攻(化解危险),每一部分须要的一些工具能力如下图。
就像是当下的疫情防控的几个阶段,核酸检测-危险管控-疫情医治。
危险检测-发现危险
- 情报监控/收集
- 潜在供应链破绽开掘
- 供应链投毒检测
- 影响面疾速排查
平安管控-管制危险
- 供应链组件准入
- 供应链组件援用准入
市面上的开源供应链到底有哪些危险、哪些有危险,哪些没危险,我哪些应该管控。所以两头总会存在一些漏网之鱼,或者说总会存在预期之外的状况。然而对于蚂蚁金融属性十分强的公司来说,这样的危险脱漏是无奈接受的。咱们就提出了纵深进攻的概念,咱们须要通过纵深进攻的理念,在真正产生危险的时候,供应链的组件理论触发危险的时候,可能来对危险进行管控。
纵深进攻-化解危险
- 攻打检测
- 攻打阻断
- 危险隔离
三位一体的进攻体系,最终达到的目标是危险的发现,管制危险以及危险的化解。
危险检测
供应链平安检测产品矩阵
这是咱们供应链平安检测的整个的产品矩阵,能够分成上中下三局部来了解。
首先下面是各个业务,同时这些供应链的产品为了服务业务线,咱们实现了独立部署平台化,包含多租户的 SaaS 化模式。
另一个当供应链危险产生的时候,须要检测的范畴是什么?所以说咱们会有本人的资产平台,围绕咱们爱护的资产到底要什么?举个例子:首先咱们晓得 URL 和域名是什么、 URL 和域名对应的 IP 是什么、 VIP 对应的主机是什么、主机开的端口是什么、端口所对应的过程是什么、过程上跑的利用是什么?利用哪些、接口包含利用的代码库是什么、数据是不是敏感数据、可能拜访到的数据用到的数据是什么?基于这样的资产的透视,咱们就能够晓得要爱护的指标是什么。
基于咱们爱护的指标,就会去构建整体的供应链的检测产品。供应链检测的产品也能够分为高低两个局部来解读。上面这部分更多是说咱们理论发现哪些组件存在供应链的危险。这两头就蕴含了咱们要做情报的收集,情报的监控,包含自研的收集渠道,外采的渠道,以及墨菲单干的情报收集、监控。并且情报是须要有研判的,因为很多 cve 的破绽,这些情报好多都是理论没有什么危险的,没有理论攻打的链路,然而它也会被作为一个情报公开出来。所以说情报首先是须要做研判的,另外也会对公开的情报、非公开情、潜在非公开破绽或潜在破绽的进行钻研。
这里就波及到了工业软件的可证,基于咱们污点建模的能力,构建出了动态和动静的跟踪能力,包含重打包的能力。后面的老师也有讲到说,那我这有一个包,比如说我有 Fastjson 这个包,我拿过去外部改一改,间接把代码引入到我的我的项目外面去。那这其实也是一个供应链的问题,咱们也会有这样代码类似度的检测,在外头去发现重打包的一些问题。
另一个咱们会有一些投毒检测,它蕴含了通过底层的操作系统切面,包含一些利用的切面,在理论的运行过程当中去感知它有没有投毒的行为。这两头就蕴含装置的检测、 query 的检测,以及函数理论调用过程当中 fuzz 的检测。那么基于这个能力,上半年总共检测进去 1000 多个存在投毒的 node 的组件。
再回到下面局部,这部分更多是理论晓得了哪些供应链的组件存在平安危险之后,如何去做影响面排查的能力,或者说如何去做增量检测的能力。下面分为左半局部和右半局部。右边更多是业务在上线前用到的检测产品。比如说白盒代码扫描,咱们会在白盒代码扫描外面会集成 SCA 的扫描能力,包含特色扫描能力、污点追踪扫描能力。咱们会去看比如说某个组件存在了 CVE 破绽,那它在理论业务应用过程当中,它的整个攻打的链路能不能触达,或者说理论的攻打的参数能不能被内部可控,那当然咱们也会有一些代码画像的能力。
上面是咱们目前反对的一些语言,其实咱们也在钻研建对立的语法书,因为当初业界的各种白盒扫描的产品,各个语言之间的建设,比如说 Java 的 node 的语言都会去自建一套,比方每个语言都会去做一套 IAST 的这种解析,那咱们心愿说的 IAST 可能有一个对立的表白,而后在这根底上建一个对立的污点追踪引擎。所以说咱们会建设对立的语法树做撑持。
另一个就是交互式扫描,交互式扫描会有基于动静的跟踪,包含动静的污点追踪,代码的画像之类等。而后也会反对更多的语言。
另一个局部,业务通过了开发测试达到打包的时候,打包完镜像的时候也有扫描。镜像扫描次要做比方供应链 RPM 的扫描、供应链的 jar 包,供应链组件的扫描以及敏感信息的扫描,包含恶意程序木马扫描。之后利用就公布上线,到线上之后,咱们会有线上的一些能力和产品来自动化的去发现平安危险。次要就包含了利用的平安的透视。
这是咱们整体的检测机制,检测的产品矩阵。而后咱们也在做另外一个事件:软件供应链的可证。
软件供应链可证
咱们当初其实在尝试做可证,可证跟检测有什么不同呢?可证其实咱们其实为了辨别三种状况:
- 平安的,不存在破绽或投毒行为
- 不平安的,存在破绽或投毒
- 临时无奈判断,存疑的
其中一种是临时咱们判断不了的,通过咱们工具、机器不能判断,那么它是存疑的。这个时候咱们就能够举荐用户去用咱们认为平安的。如果说同样性能做 JSON 解析、做 XML 解析,咱们能够举荐用户去用咱们认为平安的,或者说咱们认为通过可证的剖析认为这个组件不太可能在将来会被曝出这种供应链破绽。那么临时无奈判断的,可能通过人工经营去判断。通过人工+工具的这套体系,也可能帮忙咱们破绽钻研的同学去开掘一些潜在的 0 day 或潜在的平安的破绽。
软件供应链可证的性能或工具是联合了咱们自身在 IAST 和 SAST 这一块积攒的动静和动态剖析的教训所构建进去的。第一,咱们能够拿到它的代码特色,并且能够拿到它的动静和动态的危险的调用链路。基于这些危险调用链路、依赖关系,能够去做代码画像,比如说链路的画像、依赖的画像。而后看组件它到底有没有高风险的行为,并且说高风险的行为是不是存在可控的状况。最终咱们能够推断进去可证的这三个维度的数据。
可证是往年才开始做的,目前来看,咱们联合人工+工具曾经发现已发现google、apache等多个根底组件的平安0day。(已报备给相干单位)
平安管控
这部分是咱们软件供应链平安管控的整体的流程。
其中平安管控分为两个局部,一部分是组件进入到外部的,蚂蚁有个外部的制品库,包含 Python 、 Npm 、Java 的都有外部的制品库,所以在内部的组件用户上传,还是地方仓库同步,都会通过投毒检测、 DAST 检测,最初入到外部制品库。
录入到外部制品库之后,接下来就是理论生产资料被理论应用的过程,当中咱们也有准入的管控。应用过程分为两个场景,目前关注比拟多的是第一个场景,我在应用过程当中被我理论的利用应用了。另一个场景可能关注比拟少,就是计算工作这种场景。然而在蚂蚁有大量这种计算,大量这种场景,比如说 UDF 的计算工作跑在大数据平台上,那这个计算工作它也会存在供应链的问题,无非就是计算工作的一个插件,包含比如说那种压测的平台,它也能够写压测插件,这种也是会存在供应链的危险的。并且之前咱们也检测到这种危险被触发的这种状况。这块咱们来做一个简略的介绍。
首先在开发阶段,咱们会有开发准入,会有 SCA 的扫描,会揭示开发说你有什么样的危险,须要去把这些危险修复掉。集成测试的时候会 SDK 扫描,包含 IAST 的检测。这个时候咱们会造成一个卡口的机制,因为集成测试的时候代码根本就是一个稳固态了。那接着到构建公布的时候,镜像构建完了,咱们也会有构建公布阶段的镜像扫描,这个时候也会对供应链问题进行卡口。
而后真正线上运行的时候,咱们会去做 DAST ,包含利用威逼透视,智能破绽感知,例行的巡检扫描。计算工作也是一样的,从开发测试到上线,由开发阶段有查看,上线阶段有卡点。所有的数据最终会会集到元数据中心,元数据中心联合危险报告以及危险事件,再回流到应急响应核心,就可能疾速地来应答。比如说新呈现的这种 CVE 的破绽,投毒事件,咱们能疾速地晓得它的影响面。
纵深进攻
供应链问题其实是一个混沌的问题,混沌的问题咱们通过检测和管控并不一定能百分百的把这些危险都解决掉。这个时候就须要咱们去思考理论危险产生的时候,怎么来管制危险和隔离危险,或者说打消危险。那咱们就提出了纵深进攻的思维,好多人可能玩过塔防的游戏,我联合塔防的游戏来给大家讲一下什么是纵深进攻。
第一,玩塔防的时候不会把进攻塔建在一起,就建在一个节点,因为建在一个节点的状况下,这些小兵通过了这个节点前面就畅通无阻了。所以说要害的节点必然是层层设卡的。
第二,各个进攻塔之间的效用必定是互补的。有些进攻塔是间接给对小兵造成挫伤的,有些进攻塔是给小兵造成眩晕的,让它跑得慢一点,能让攻打的工夫长一点。所以说进攻的能力之间必定是互补的。
第三,塔防游戏自身在设计上是不容许有捷径的。所谓捷径就是两头有草坪或者高的障碍物,小兵是没法间接通过障碍物达到起点的。其中很重要的一点就是咱们要杜绝攻打捷径,也就是所谓的隔离。这就是咱们纵深进攻的思维。
总结,要害节点,要层层设卡;防御能力互为补充;杜绝攻打的捷径。
网络层面纵深进攻
网络层面纵深进攻更多强调的是隔离和可信通性。蚂蚁会对网络、利用进行分类分级。比方上面是云底座,下面是各个 Node ,再在下面是一些 VPC 。比方有三方的 VPC ,还包含一些重要的管控危险比拟大的,就会放在管控 VPC 外面,包含办公信息化产品的 VPC 、测试开发的 VPC ,都是相互隔离的,它们之间的通信只能通过跨域 VPC 的可信通道能力通信。这是网络层面 VPC 层面的隔离,另一个就是隔离之后的可信通信。
在具体的 VPC 内,咱们会去做具体 VPC 内更细粒度的隔离。比方一个 VPC 内各个利用,它的属性是不一样的。比如说业务 VPC 它有外围的一些利用,咱们会通过 DMZ 的这种形式,把它隔离在一个外围的 DMZ 外面去,一些揭发层的、间接对公网裸露的,会到揭发层的 DMZ 这外面去。这个益处是什么? 在某一个区域暴发的供应链平安危险,它只能在无限的范畴内进行扩散,它要扩散到别的 VPC 其实老本是很高的。
计算纵深进攻
具体的某个 VPC 内,是怎么来建设纵深进攻这套机制的,把它称之为是计算纵深进攻。
次要是两类危险,一类是破绽,另一类是投毒的攻打。计算纵深的进攻是从平安的网关、流量的接入层、物理主机、容器过程这些维度的一个进攻。
切面在纵深进攻中的利用
纵深进攻的整个体系外面很要害的一点是切面,在多个环节都失去了很好的利用。
在纵深进攻外面的利用,首先对立接入层,会有一个切面,攻击者的流量进来之后,会在流量的对立接入层有 WAF 、有智能感知,通过流量的形式拦挡危险。当真正的申请达到 controller 、业务逻辑的时候,自身咱们的 RASP 基于切面的底座或切面的技术,咱们会有要害的切点。所以说当有一个有危险log4j 触发 JNDI 的这种行为的时候,就会被切点监控到,并且会被这个切点拦挡。所以说基于切面能力利用在纵深进攻外面的时候,可能做到攻打阻断、沙箱隔离、异样检测的能力。然而最重要的一点是通过切面的理念被利用到了整个综合进攻外头。
咱们会发现平安不会再成为业务的一个老本,平安和业务自身是解耦的,其实平安的一些计划难推动,更多是平安会成为业务的老本,要落地计划,业务必须配合我去做一些革新或帮忙平安去承当这样的老本。但切面很好,因为它自身是和业务平行的,这种状况下平安就不会成为业务的一个老本。并且平安是真正助力业务去做、去胜利的一个能力。
小结
1、要害节点(攻击者必经之路)层层设卡
- 对立接入层
- 物理机
- 容器
- 业务过程
- 利用间通信
- 数据库
2、各防御能力互为补充
- 流量视角
- 利用内运行时视角
- 操作系统视角
- 利用间视角
3、杜绝攻打捷径(隔离)
- VPC隔离
- vDMZ隔离
- 过程沙箱
- 平安容器
Log4j 典型案例
最初来分享一下 Log4j 的典型案例,在蚂蚁是怎么被应急处理以及到变成日常的例行管控的。
首先分为两条线:下面那条线次要介绍的是破绽止血,上面一条线是影响面排查和破绽修复,这两条线在理论应急过程当中是并行的,两条线同时触发同时往前推动的两条线。
整个破绽的应急自身必定是从破绽剖析开始的,所以第一步是确定破绽的原理、触发点、payload 特色。这个时候很重要的一点是修复计划是什么?咱们是要有一个决策的。
破绽剖析 - 破绽止血 - 触类旁通
因为咱们收到情报的时候,官网还没有给出修复版本,并且官网给的修复版本,可能只会修一个最高版本,而修一个最高版本的状况下,蚂蚁是没法落地的,蚂蚁的理论应用的版本是十分扩散的,没有做版本的收敛,所以说真的要降级的时候,兼容性是一个很大的问题。
另一个问题是咱们不晓得官网什么时候会出新版本,这段时间的危险敞口怎么办?
基于以上两个点,咱们做了一个决策,确定阉割 lookup 的性能作为修复计划,并且咱们本人去打包一些小版本来帮忙业务疾速的修复。
做完破绽剖析之后,晓得了破绽的一些特色,接下来全站下发WAF 的止血计划,进行全栈的止血;并且也晓得了RASP破绽触发的原理,确定 RASP 的止血计划,并且全栈下发计划,止血到节点,全栈的止血曾经实现了。
后续咱们要触类旁通地去排查是不是还有二三方组件存在同样的 JNDI 可能被攻打的供应链平安危险,以上这是破绽止血这一条线。
影响面排查-存量修复-增量管控
另外一条线同步进行的是影响面排查和存量修复这条线,这条线次要是依赖下面的破绽剖析的论断。
蚂蚁的 SAST(SCA)、DAST、资产威逼透视,别离从代码、内部攻击者视角、主机采集三个渠道确定残缺的影响面。确定影响面后,接下来就推修了,依据理论排查的隐射层面,主动发单给破绽经营平台,破绽经营平台利用无痛降级性能,就可能很简略地主动帮忙研发改代码,疾速实现全站修复。大大地放慢了业务去了解破绽并且修复破绽的老本。
当整个修复停顿到肯定水平的时候,就须要去思考怎么管控增量。蚂蚁在 CI|CD 的流程上配置了卡点规定,在上线前就进行一些平安的卡控。还有其余平安产品也会进行线上的增量巡检发单,实现增量管控。
在这里我举了一个比拟有代表意义的,下方比方 HIDS这类平安容器 、RASP 等在整个过程中也施展了十分重要的作用。
以上为我的残缺分享,感激大家的观看。
理解更多,搜寻关注公众号 OSCS