对于一家拥有上万名员工的大型企业而言，其IT资源每天都会处理数以万计甚至百万计的增删改查等各种操作，其中绝大多数都是员工的日常工作所致，这些行为都会以日志的形式被记录下来。
但如果有黑客把一次窃取敏感数据的操作伪装成合法操作，该怎么找出来呢？
先看看下面这张图，请从中找出不一样的猫。
细心的朋友可能很快就发现，第二排最后一只猫没有眼睛，用时都不到一秒。
但问题来了，毕竟这只是3×8的矩阵，如果这里有几万只甚至几百万只猫呢？这得用多长时间才能找出不一样的那只？
这时候就需要借助工具——关联分析引擎，能够把耳朵、眼睛、尾巴等所有和猫相关的信息收集起来，进行关联分析，得出正确的结果。
01 关联分析与复杂事件处理（CEP）
先介绍几个基础概念。
1、什么是事件？
在这里，事件是IT系统中某一活动产生的一组数据，一般分为简单事件和复杂事件两种。简单事件一般指数据源产生的原始数据，复杂事件则指简单事件经分析后产生的高级事件。
一个防火墙事件可能记录了这个事件源IP 、包括目的IP、目的端口等等信息，事件体现的是一个对象，它是有特定的属性和对应的属性值组成。
举个例子，你今天上班这个事件就包括了几点起床出发、乘坐什么交通工具、几点到单位、工作内容、时长等等一系列数据。
2、什么是事件关联分析？
事件关联是一类用于对数以百计的设备中产生的海量日志进行关联分析，以发现难以琢磨的攻击模式的技术。
还是举个例子。交通警察在追查肇事车辆的时候，依赖某一个摄像头所记录的路况往往是不够的，需要提取若干个摄像头所拍到的肇事车辆镜头，甚至得综合肇事人衣着、外貌等信息进行关联分析，从而还原出肇事车辆的行动轨迹。
就网络安全而言，目前的网络攻击通常是非常复杂的，尤其是APT攻击，有的跨越很长的时间，有的入侵节点会覆盖非常广。如果只对某一个点日志进行分析（例如EDR软件只能对终端上的行为日志进行分析），很难还原攻击的全貌。如果能够把整个内网的日志进行关联分析，就能把所有的攻击片段组合起来，组成一个完整的全景拼图。
3、什么是复杂事件处理（CEP）？
它由四个方面组成。
-
第一，事件的生产；
-
第二，事件的处理；
-
第三，由事件处理引擎，结合外部知识库，例如资产信息、漏洞情报、威胁情报等，对事件进行管理分析后输出告警或者新的事件；
-
第四，告警展示和处置。
还是用抓坏人举例，也可以总结成为四步：第一，立案；第二，调查走访，搜集证据；第三步，结合外部知识，对线索进行综合分析，形成完整的证据链，同时锁定犯罪嫌疑人及其藏匿地点；第四，抓捕，以及后续的移送检察院提起公诉和法院审判。
在早期的时候，事件的关联处理通常基于关系型数据库来进行的，运行速度相对缓慢，无法支持海量数据的关联分析。近十年随着大数据技术的兴起，引入了消息队列技术，逐渐形成了如今的复杂事件处理，并且成为了现如今态势感知与安全运营平台（SOC）的核心功能之一。
02 网络安全场景下的复杂事件处理
网络安全场景下的CEP有三个特点。
首先是场景定制。因为安全场景会有非常多与通常业务领域不一样的地方，它有非常独有的需求。例如路由器和防火墙，尽管这二者作为网关设备在功能上有很大的相通性，但防火墙的工作重心主要在流量数据包的过滤，而路由器则主要用于将数据包分配到对应的IP地址。
其次是资源受限。与其他IT组件一样，网络安全软硬件同样需要消耗CPU、内存、存储、网络等基础资源，但其运行的前提是不能过多干扰机构的主营业务。如果网络安全组件消耗资源过多，势必要拖慢业务系统的运行速度，影响办公效率，这是让人难以接受的。这一点其实用户感受非常深，比如在电脑上安装了xxx杀毒软件，经常会发现CPU、内存使用率爆表，电脑卡顿严重。而如果购买性能更好的服务器、更大的出口带宽等，就势必要大幅增加成本。
最后是快速响应。对于网络安全事件而言，更快的响应速度就意味着更小的损失（尤其是入侵事件）。
传统的分析流程通常是以天甚至是以周为单位。但现实是，一旦企业被网络攻击，每耽搁一秒钟，可能就会有更多的数据泄露出去；对大型工厂而言，每停工一个小时，损失便能达到成百上千万。
因此，现实的需求是小时级响应，这就需要一个适用于网络安全领域并为网络安全场景定制的分析引擎。
举三个非常典型的网络安全场景。
第一、工作时间某IP地址突现异常流量。比如，在工作时间内，某个IP在最近1小时的TCP平均流量超过这个IP最近一周内TCP平均流量的40%，这可能就意味着突发的异常事件。
第二，网站被攻击并且被成功利用。比如，发现网站后台服务器被攻击了，而且被攻击之后还被成功登陆，这个就是被成功利用的一个事件。
第三、勒索病毒在内网被发现了，并且在内网感染了其他的主机。
这三个场景可能独立发生，也可能会同时发生。所以网络安全场景下的复杂事件处理绝不是简单的找不同的猫，也可能是找不同的狗，不同的流量、不同的访问、不同的文件等等，而事先绝对不知道究竟要找什么不同。
03 关联分析引擎实践
为了满足网络安全场景下的复杂事件处理，奇安信推出了基于流式计算框架Flink设计的分布式关联分析引擎Sabre，它究竟是怎么做的？
首先是能够接入全量数据。网络安全场景下的复杂事件多种多样，为了保证分析结果的准确性，尽可能多类型的数据是基本前提，如多源异构日志，包括账户登录、数据库查询、修改、DNS解析记录等；资产信息，包括服务器、办公电脑、物联网终端、在线网站、应用的型号、版本等；内外部威胁情报以及其他相关内容，并支持对输出结果进行回注分析。
这一点对于高级威胁发现和溯源非常重要。APT攻击的发现往往在于某些细节，比如经常在北京登录的账户突然出现了一次在上海的异地登录，公司内网某台电脑突然访问了某个恶意域名，这些都有可能是已经被入侵的信号。如果采集的数据不全，这些信号就可能会被错过了。
第二步是实时计算和实时统计。常见的计算类型分为实时计算和延迟计算。所谓的延迟计算就是指在某一时间点，对过去的某一段事件内收集的事件进行计算。这种方式类似于核酸检测，先大规模收集咽拭子，然后再对样本进行检测。
相对于延迟计算而言，实时计算能够在事件发生的同时，快速统计并输出检测结果。因此在网络安全场景下，实时计算非常重要。对于IT系统而言，事件会持续发生，比如防火墙会不停的过滤数据包，公司的办公系统会不停地被访问，因此事件是无穷无尽的，只有计算速度够快才能保证实时输出结果，这就要求能够有强大的算力性能支持。
Sabre引擎继承了Flink框架优秀的分布式扩展能力，性能可从单台每秒处理3万条安全事件，扩展至数十台集群规模，相当于处理能力可以扩展至每秒处理数十万条安全事件，能够完全满足大中型机构的要求。
第三步是快速建模。你只收集这些数据还不行，还得有规则。比如你得让引擎知道，访问192.168.xx.xx这个地址是非法的，这就像法律一样，规定哪些事情是不能做的，这样法院在做出判决的时候才有法可依。
当然，规则从来不是一成不变的，它也需要“因地制宜”，灵活设计。
在过去，从遇到问题、分析原理、寻找并确定解决方法到编程开发、测试上线是个长周期且耗时耗力的工程，而借助Sabre安全分析师可以用图形拖拽的方式 （类似于Visio的感觉），就能把自己想要检测场景转化成对应的检测规则，下发到分析引擎运行。
规则主要包括三类。
第一类是规则类分析基线，它主要来自于分析人员的经验或者外部的威胁情报。例如威胁情报显示IP地址192.168.xx.xx是恶意IP，那系统的检测规则就可以检测所有内网终端试图访问该IP地址的行为。
第二类是统计类机器学习基线，它主要来自于长期的数据统计和机器学习。例如根据长期的数据统计显示，某台办公电脑的CPU使用率平均为30%，极个别情况下的峰值会达到80%，但如果在某一段时间CPU的使用率长期在70%以上，那么这台机器有可能中了挖矿木马。分析师也可以设置检测规则，该台电脑的CPU使用率不能在一段时间内一直在70%以上。
第三类是行为类的学习基线，利用”UEBA”技术（用户实体行为分析），检测异常行为。例如机器学习发现，一般而言员工不会再夜间访问公司内网或者下载敏感数据，那么规则应当可以检测非常规工作时间下载内部敏感数据的行为。
为了帮助客户快速设置规则，一方面Sabre中预置了400+条规则；另一方面Sabre提供了面向安全分析人员的DSL（Domain Specific Language，领域专用语言）。这里的DSL主要是相对于通用机器语言如Python、C++等，特地用于安全分析领域，能够以极短的代码来表达复杂的语义，下发后快速编译成一条规则。
随着技术水平的提升，在大多数企业网络安全运营者的工作实际中，通过众多厂商的安全产品、设备发现威胁已成常态，然而带给他们众多困扰的不仅仅是发现威胁，他们更多情况就像企业里负责网络安全的”警察”，要从众多设备告警中，通过分析研判，追踪溯源，找到威胁来源，采取措施保障业务系统损失最小化，网络环境更安全和稳定。
然而，众多设备和系统每天产生大量告警，再加上参差不齐的误报率，使得网络安全运营者陷入无从下手的困境。
那你看Sabre能当好这个警察么？
声明：本文来自虎符智库，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
版权归原作者所有，如若转载，请注明出处：https://www.ciocso.com/article/169.html
