基于复杂事件处理技术，通过关联、时序、聚合等方式对多种数据进行分析处理，可以发现一些有价值的信息，是大数据处理的关键技术之一。目前，市面上CEP引擎主要有：
- Drools是Java编写的CEP引擎，核心为将规则集合，以规则过滤或关联条件为节点生成网状结构，数据会在网状结构中流动并在节点临时停留，利用空间换时间思想避免重复执行相同条件以提升性能;
- Flink CEP是基于Flink计算框架衍生出的一个计算算子，是实时复杂事件处理的解决方案，它利用NFA(非确定有限自动机)对象进行状态管理;
- Siddhi是用于实时事件分析的开源引擎，它支持典型的事件检测模式，如筛选器、窗口、关联的事件模式，以及更高级的功能，如事件分区、将数据库值映射到事件等;
- Siddhi是一种轻巧、易集成的开源CEP引擎，它识别事件流中需要关注的特征事件，并进行实时分析处理，Siddhi与流框架Flink能友好集成，并获得不错的处理性能。
当前数据安全事件层出不穷，数据的安全传输、脱敏、加密、防泄漏等主要是事前防范措施，我们将围绕数据溯源场景，基于CEP引擎对数据泄露相关事件进行关联分析，追踪溯源。在事件运营整个流程中，针对安全设备发来的安全日志以及数据访问和传输日志，再经过平台解析、增强、归一化等技术标准化后，就需要使用CEP规则引擎对标准化的日志做深度关联分析，生成安全告警事件(如图1)，并推送给安全运维人员，从而完成防护—检测—响应的整个安全事件运营的闭环。
图1 安全日志分析流程
数据安全需求与分析场景非常复杂，为了适应快速变更的场景需求和保护数据的价值，规则引擎的设计架构需具备灵活的语义定制、友好的规则扩展以及高效的大数据处理能力等特点。另外，根据日志的存储特性，CEP规则引擎可分为实时和离线两种分析模式，下面分别介绍这两种模式在数据安全事件分析场景中的应用。
模式一、实时复杂事件处理
为了快速发现数据安全事件，需要实时处理设备日志，因此需要基于实时的流式大数据处理框架开发CEP规则引擎。一般情况下，将一个数据安全事件检测场景部署到安全运营平台上，需要经历如下步骤：
- Step1：理解数据安全事件的表现特征;
- Step2：推理设备日志的字段特征;
- Step3：归纳事件检测逻辑，并转化成事件处理语言(EPL);
- Step4：将EPL集成到CEP规则引擎中并执行;
经过上述步骤后，CEP规则引擎就可以加载该安全场景的事件检测规则，当符合该规则检测模式的设备日志进入到CEP规则引擎后，即可触发生成事件。
基于Flink和Siddhi开发CEP规则引擎，是实时事件处理的典型案例，其事件处理流程的架构如图2。
图2 Flink-Siddhi流程图
下面以一个实际业务中的数据安全威胁检测场景为例：攻击者通过若干已知账号和通用密码尝试登陆(UEBA异常行为—单设备登陆多个不同账号)，成功后登陆特定用户的confluence、邮箱等，翻阅并下载敏感信息(短时间内下载大量文件)，如服务器密码、敏感文件等，进而攻陷了一批服务器，造成严重的数据泄露。该场景涉及到三种日志：登陆认证、Web访问和文件传输。经过分析可知，该场景的日志具备如下特征：
- 登陆认证日志：多次认证失败后突然成功;
- Web访问日志：某设备突然登陆若干不同的账号，偏离以往日常行为;
- 文件传输日志：短时间内下载大量文件。
上述特征均可以使用CEP规则引擎内置的算子来表示。
使用EPL将事件检测逻辑定义出来，然后将EPL加载到CEP规则引擎中，通过解析校验EPL等流程，最终得到一个物理执行流程图并分发到集群的各个worker节点，开始执行上述事件检测规则。
一般情况下，多数CEP引擎都提供了状态机的方案，按照事件检测规则对实时日志流进行模式匹配，在上述安全事件检测规则的具体执行过程中，有限状态机的执行过程如图3所示：
图3 CEP规则执行EPL基本流程
首先，CEP规则引擎持续检测第一步的登陆认证日志，如果检测到多次认证失败突然登陆成功的日志，则判定为异常，并将异常登陆认证日志缓存起来，记为集合A。同时，实时监控集合A中日志源/目的IP，若有Web访问日志短时间内登陆大量不同账号，且登陆账号的数量超过正常基线(或阈值)的情况，记为异常的Web访问日志集合B。至此，得到了两个日志集合A和B，并且将集合A和B中按源/目的IP条件关联得到的集合记为[A&B]模式序列。
同理，以[A&B]模式序列中集合A的目的IP持续监控文件传输日志是否有和关联条件相匹配的文件传输日志，并且在登陆成功后的一段时间内发生了大量的文件传输行为，于是得到集合C。并最终得到[A&B->C]模式序列。如果该模式序列[A&B->C]不为空，则说明日志触发该事件检测规则，即可生成最终的账号爆破成功后的数据泄露告警事件。
通过我们的CEP引擎，可以灵活高效处理数据安全场景的溯源分析，快速还原数据泄露过程的全貌，对责任定位、环境加固、安全预防起着重要作用。
模式二、离线复杂事件处理
虽然实时处理能检测到很多数据泄露的场景，但由于部分场景时间跨度长，且是一次性接入的历史日志，因此亟需离线复杂事件处理模式。离线模式可基于历史日志，支持长时间跨度的威胁分析，还原攻击事件。绿盟科技开发出一套通用的离线规则执行框架，用以支持单源、多源关联分析、复杂事件处理以及自定义插件类规则，支持更多的场景分析，同时兼顾效率和资源。离线处理整体架构如图4所示。
图4 离线规则执行流程
- 规则与任务注册模块：支持在界面配置离线规则和执行模式，并注册至离线任务表中，由任务调度模块调用。
- 任务调度模块：常驻进程，用来监控任务表，根据任务信息来选择2种执行模式：(1)立即执行，即手动触发的一次性任务;(2)周期性执行。
- 规则执行模块：根据配置和调度信息，基于对设备告警或流量日志、文件传输日志的简单查询或关联聚合等操作，执行规则，生成相应事件，最后将任务执行状态(成功/失败)更新至任务表。
下面我们结合具体APT攻击导致数据泄露实例场景来说明：攻击者首先通过端口和漏洞扫描尝试，发现开启SSH服务，然后制作密码字典进行暴力破解，期间有SQL注入尝试，获取密码、权限等，成功登陆系统(SSH登陆成功)，进而安装病毒程序或工具进行木马远程控制活动，获取持久控制权限，登录后阅读或传输敏感文件，导致数据泄露，造成严重的数据安全事件。其攻击流程如图5所示。
图5 复杂持续攻击数据泄露案例
根据攻击阶段的关键动作可提取特征：
(1)侦查：如端口、Web漏洞扫描;
(2)定向攻击：账号爆破、SQL注入等;
(3)攻陷+入侵：账号爆破成功、系统登录成功等;
(4)安装工具：感染木马、病毒等;
(5)恶意活动：远程控制、敏感文件传输、数据泄露等。
离线模式检测当前APT攻击方法：
(1)首先根据数据攻击场景提取的关键特征配置规则，这里可以配置为5个阶段：S1(端口扫描)->S2(SSH暴力破解)-> S3(SSH登录成功)-> S4(感染木马病毒)-> S5(数据泄露);
(2)配置完规则后选择执行模式(立即或周期执行)，并注册到任务表中;
(3)任务监控进程根据注册信息执行对应任务;
(4)执行：由于是离线溯源，日志都已存储至ES中，因此可以从任意阶段开始搜索。
由于面临海量日志的关联，需解决好关联时的性能问题。这里采用最小日志源双向关联算法，核心思想为先找到各阶段各个日志源命中数量的最小值，提取关键关联条件字段信息，如sip、dip等，然后结合关联条件，将其作为前一步或后一步的追加复合搜索条件，反复迭代搜索，获取最终待关联分析的日志最小数据量，在内存数据库中完成聚合关联分析处理。
图6 最小日志源双向关联搜索执行流程示例
以三个日志源[s1,s2,s3]的多源关联分析规则为例，描述详细执行逻辑：
(1)先查询三个日志源的每个规则过滤条件分别命中的日志总数列表log_cnt_list =[cnt1,cnt2,cnt3], 假设cnt2为最小值;
(2)将第二个日志源过滤规则命中的日志数据Data2从日志数据库中取出来，结合关联条件(如s1.sip=s2.dip)，将s2的查询结果Data2作为追加查询条件，向前以及向后关联查询日志源s1和s3分别命中的日志数据Data1和Data3。需要注意的是，以Data2中的值作为约束关联条件查询s1或s3，可能会查询不到结果，即Data1和Data3可能为空，若为空，则需要及时终止向前或向后关联查询，并退出规则执行模块，以避免对日志数据库不必要的查询并及时释放系统资源。
(3)双向查询日志结束后，将查询到的日志数据集[Data1,Data2,Data3]写入到内存数据库中，然后参与后续的关联聚合并输出事件，并及时清空内存中的临时数据;
(4)增加反查机制，进一步降低数据量。
可以看到，定义好场景和特征后，数据泄露相关场景可以灵活通俗的转变成引擎内置识别的方式去溯源检测，使场景分析的门槛大大降低，人人都可以基于业务中的场景实例做实战分析。
结语
通过上文对复杂事件处理相关技术在数据安全典型场景中的应用探讨，并基于实时和离线两种安全事件分析模式分析具体数据泄露场景案例的溯源实践，我们可以看到复杂事件处理技术在网络安全行业具有重要的应用价值，尤其在数据安全事故频发的现状下其价值体现将更加明显。但数据泄露的场景分析、数据窃取、滥用及加密等课题研究仍任重而道远。在设计上，需要更加完善的数据安全治理和评估框架体系;在技术上，需要对方案的性能、多样性和扩展性做持续探索和优化。
【本文是51CTO专栏作者“安全牛”的原创文章，转载请通过安全牛（微信公众号id:gooann-sectv）获取授权】
