硬科技解密:利用事件关联让网络攻击无所遁形
作者: 日期:2019年09月12日 阅:4,502

本文作者:奇安信集团大数据与安全运营公司高级研发总监韩鹏

2019北京网络安全大会期间,奇安信集团发布了面向实战化的态势感知与安全运营平台NGSOC(下文简称NGSOC),NGSOC搭载了国内首款分布式流式关联分析引擎Sabre。本文将详细阐述如何基于事件关联,还原网络攻击的全貌,从而让网络攻击无所遁形。

Sabre是什么?

Sabre是一个项目代号,即分布式流是关联分析引引擎的一个代号。严格的说是CEP技术在大数据领域的一个实现,CEP(复杂事件处理)是流式事件分析的一种通用技术。

网络攻击是复杂的、多阶段、持续相当长时间、跨多节点的动态过程,独立的日志源无法看到攻击的全貌,而只能看到完整攻击的一个片段,不进行关联,就无法把大量的片段组合起来完成全景拼图。在实际使用场景中,用户经常会淹没在多个设备频繁告警中,无法通过智能手段将这些告警集中并进行关联处理。

什么是事件?

我们这里所说的事件跟日常生活中的事件是不一样的,它是计算机世界中的事件,指的是由计算机系统在运行中所生成的一组数据。

举个例子,右面是个防火墙生成的事件,这是json的表现形式,整个事件是完全结构化的,由两部分组成。Key跟Value,Key叫做字段,Value叫做值,这是一个标准的结构化事件。对于计算机系统来说这样一条完全结构化的数据才可以被处理、被分析。一般情况下,从非结构化数据到结构化数据的过程,叫做事件的归一化。事件归一化之后,就会变成这种形式。
对海量的结构化日志数据做分析,目的是发现难以琢磨的攻击模式的技术,称之为事件关联技术。

在网络安全中,溯源一个攻击事件的全貌,就像现实生活中的警察破案,以一般典型案例的侦查为例(指须综合运用多种侦查措施、手段的专案侦查),其一般程序如下:

1.初步收集与案件有关的各种线索,如现场痕迹、遗留物品、被害人基本情况、作案手法工具特征等;

2.汇总案情,综合分析,作出判断(提出假说)
这是整个侦查工作中很关键的一个环节,是确定侦查方向,制订正确侦查计划的前提。

3.确定侦查方向、划定侦查范围,安排分配侦查力量展开进一步地具体侦查,直到找到真凶,破案。

事件关联技术就是这里面的汇总案情进行综合分析的环节。

在网络安全世界为什么要做事件关联?

因为在我们现在这个世界,现实中的网络攻击是非常复杂的一个过程,它不是某个瞬间发生的一个事件,而是一个漫长的过程,一般来说,跨越非常长的时间段、非常多的网络节点,它在这个过程中会从A节点移动到B节点,再移动到C节点。比如,通过外部的系统漏洞,攻击进来之后,要做提权,做横向移动,拿下你的域控,接着偷你的数据,最后留下后门。在整个过程中从网络角度看涉及到非常多的节点,而这个过程也不是在瞬间完成,往往要持续几个小时到几天甚至更长,而且是一个动态的过程,这会导致什么结果?

我们现有所有的检测体系,包括网络边界的防火墙、WAF、IPS、终端,分别只能看到整个攻击过程中的某一个片段。那么怎么能从一系列的片段中,把整个攻击过程完整的还原出来,这就是事件关联分析的作用,也是NGSOC的核心功能。
事件关联分析用什么技术来实现?用CEP技术。

什么是CEP?

CEP标准的学术名称叫复杂事件处理,如图是一个事件的生产和消费的处理模型和关系。左边是事件的生产者,右边是事件的消费者,而中间的就是事件处理。CEP的主要应用领域就是在事件处理上,这个事件处理会非常复杂,包括模式发现,验证,数据富化及路由等等各种比较复杂的处理,在生产者跟消费者之间进行的很多计算都是要由CEP来完成。

CEP可以做实时的事件处理,但是这个事件处理,还有点特殊,这是四种典型的应用技术,每个技术应用的领域不太一样。从这个横轴上看,把处理速度分为两类,人类速度和机器速度。从纵轴上来看,把事件分为简单事件和复杂事件。严格定义的话,CEP技术的应用领域是用机器速度来生成复杂事件。

那么什么是简单事件呢?

举一个很简单的例子,房间里有一个温度传感器,温度传感器的作用是每隔一分钟报告即时温度,它会不停的报,这是简单事件。但是如果根据简单事件做一个长期的分析,例如房间温度已经持续30分钟上升,接近火警警戒线,这个屋子里面可能存在着火的隐患,这种就是简单事件经过分析后生成复杂事件的典型例子。

传统的商业智能技术(BI)最常用于做企业的财务分析,CFO要看财务报表,在看的时候,他会得出一些结论,比如这个月的财务数据是平稳的,这就是一条复杂事件产生。

关系型数据库,在查询数据的时候,一般的以秒为单位返回数据,这个速度实际上是人类可以接受的速度。同理,BI也是这个意思,当CFO在看到报表的时候,要在一毫秒内得出结论,那基本不可能。人类速度是以秒为单位是可以的,但是对于消息队列来说,处理消息要考虑到低延时,不可能说是这个消息一秒钟之后再转发出去,复杂事件处理同样也是这个道理,就是技术要求实时或者是准实时。

复杂事件处理技术两个最常应用领域,一个是金融反欺诈及程序化交易。程序化交易指的是由电脑来做自动交易,它的决策速度非常非常快。因为如果晚一秒钟交易价格就会出现巨大的波动,一笔买卖就会从赚钱变成亏钱。同样金融机构的风控系统必须要快速得出结论,以阻止恶意交易的发生。

第二个比较典型的应用领域是物联网IoT领域。在万物互联的时代,整个世界上的传感器比人类的总数要多上几十倍,每个传感器都会生成大量的简单事件。那么这些简单事件如何处理?答案是主要依赖CEP技术。CEP在物联网时代,是一个核心的、关键的、决定性的技术。

在NGSOC中,会输入海量的告警和日志,对于NGSOC来说都是简单事件,CEP技术的应用场景是从这些简单事件中分析出复杂事件,还原攻击的全景拼图。

那么CEP技术跟数据库技术有什么区别?

如果非要把数据库技术和CEP技术做对比的话,可以认为数据库技术是一个水库,CEP技术是一个水管,水管里的水是不停流动的,不能停。数据库技术相对简单多了,先把水倒进来,保存下来之后再来做查询跟分析,这是数据库技术的原理。但是对于CEP来说,它这个水不停流动不能停,数据是动态,它是把数据直接推到查询,打个比方说,CEP技术类似SQL on Stream, 但这个比方也不完全合适。因为其实本质上CEP这里不是用的SQL,是EPL事件处理语言,要比SQL强大的多。
在大数据场景下,CEP技术是比较有历史的,已经发展很多年了。但是为什么说大数据场景下,CEP关联分析会不太一样,是因为我们在目前的大数据场景下遇到了更多的困难。

首先从场景上来看,大数据时代,数据要比原来单设备的数据要多上一到两个数量级,拥有更海量的数据、更大量的告警。现在的现实情况下,大数据平台建好之后,用户也比较愿意去把所有设备产生的告警集中起来,但是一般一个比较好的安全分析师,一天最多处理二十条告警。但是在我们实际的工作中,他可能一天要处理几十万,甚至上百万的告警。怎么办?
而且这些告警越来越复杂,从原来的暴力破解、扫描,现在已经扩展到很多需要AI的介入做长期的基线分析,场景会越来越复杂,而且越来越广,在一个框架里面描述的攻击方法,其实每一种攻击方法都可以作为一种场景来做解读。客户对产品的需求,就是你能支持哪些场景,而这些场景后面支撑的是什么?其实就是关联规则。

只是这个关联规则,可能写的很简单,也可以写得复杂。现在检测APT都不仅仅依赖威胁情报,还有相关的上下文、资产、漏洞信息、网络信息,这些上下文信息都是数据,需要把它们全部引入NGSOC,引入之后,发现除了正常导进来的这些日志、告警之外,上下文信息的数据量也非常大。

高级威胁一定要结合上下文信息来做分析,在这个方面仍然会遇到很多的问题。而且在那个大数据场景下,工程上也会有很多的难点。

大数据场景下的工程难点

第一、计算与存储资源的平台化趋势,这使得卖传统设备那个阶段各个安全厂商的东西都可以独立部署已成为过去。现在的平台化趋势越来越明显,用户单位所有的计算资源、存储资源要都在平台上,最终交付给客户的是跑在大数据平台上的一个应用,这种新的交互形式带来了工程上的问题,你拿不到独立的设备资源,甚至虚拟机也没有。很多客户那里大数据平台已经有了,上面没有应用,怎么把你的安全能力落到客户的大数据平台上去?你的检测原理、兼容性怎么保障?

第二、很多客户的大数据平台的部署实施是早于安全应用采购的,如果这个大数据平台相关的组件版本是一个非常老版本的,你会发现对应用的要求更高,很多API要重新调整,在工程上会这个难度会更大。

第三、也是最难的一点,在大数据平台上做应用,做分析,很多互联网公司走前一种路线,依赖重运维的自有系统,但是我们卖给客户的产品必须是轻运维的。如果依赖重度运维的话,成本是非是非常高的。比如你的产品是互联网公司的内部系统,为了确保业务 24小时稳定,可以放一个五个人团队来进行7*24小时保障。但如果要求你的产品是面向企业用户的话,为了减轻运维压力,工程上要跨越一个鸿沟。你的产品的成熟度,必须要能达到完全意义上的轻运维,技术上非常困难。

在大数据场景下做CEP关联分析,过程比较简单,就三步。首先选一个流式计算框架;然后把所有的复杂逻辑做拆分,使能分布式;然后最后计算任务的生命周期管理,做完整的生命周期的创建、运行、监控。简单说,就跟把大象放冰箱里是一样的,打开门、塞进去、关门。但是,这是目前的通用方法,必须且只能这么做。

因为前面所说的工程上的那些问题,只能按这个套路走。因为开发的不是一个设备,而是一个应用,就是前面提到的Sabre。

Sabre的特性

Sabre是一个分布式关联分析引擎。Sabre有三项独有的技术,我们自己定义的EPL语言、图计算、代码生成。通过这三项技术来支撑引擎特性,包括聚合计算、序列分析,关联计算,时间窗口、分组去重、表计算。封装这些特性,推出产品。在大数据环境下做出一个产品是非常困难的,把这些技术做成一个产品集成,这个花了我们相当长的时间。

为了保证分析结果的准确性,尽可能多类型的数据是基本前提。Sabre支持接入各种类型和维度的数据,如多源异构日志、漏洞、资产信息、威胁情报以及自定义对象内容,并支持对输出结果进行回注分析。

在过去,从遇到问题、分析原理、寻找并确定解决方法到编程开发、测试上线是个长周期且耗时耗力的工程,而我们希望可以借助Sabre,通过类似VISIO界面的操作,进行规则配置,灵活易用。Sabre本身具备规则监测能力,可对配置的规则进行快速精准验证。Sabre中预置150+条规则,将专业的安全运营经验不断通过规则更新传递给用户。配完规则之后,可以在1到2分钟之内就直接上线验证。这个可以大大节省开发的成本。

分析引擎的分布式扩展能力一直是关注的重点,在用户规模从小变大的过程中如何适应不断增长的数据分析诉求是设计的关键要素。Sabre基于流处理框架分析引擎,支持对流数据进行实时关联分析。

支持分布式意味是可以横向扩展的,性能可从单台3W+EPS向扩展至数十台集群规模,性能可达10WEPS的实时处理能力,能分析来源非常丰富的威胁。

为满足大安全时代,企业级对云、智、物、移大数据背景下的异常威胁检测要求,目前主流的流式数据处理和分析框架有两个,要么Spark,要么Flink。Flink在国内最近几年发展比较快,在各大互联网公司用得比较多,因此我们选择了Flink。

但是Flink也有一个CEP,Flink的CEP目前的代码发展速度很快,代码的成熟度欠佳。如果用这个的话,代码会少很多,但在工程上会遇到非常复杂的问题,所以我们最终选择用Sabre跟它并行,对于Flink的依赖做到最小化,基本上对于Library没有依赖。很容易适配到Flink的各个版本。即便客户用很老的大数据平台,也能在上面运行,保证能够适应非常多的客户。最后一点,我们的整个开发分为两条线,上面线是产品版本规划,下面线是Sabre版本规划,两个版本分别规划,Sabre提前一个版本进行预研,这样双线开发会让开发风险降得非常低。

本文根据奇安信集团大数据与安全运营公司高级研发总监韩鹏在2019北京网络安全大会技术沙龙分享整理。

 

申明:本文系厂商投稿收录,所涉观点不代表安全牛立场!


相关文章