一、背景
大数据时代，数据窃取、篡改、个人隐私泄露等数据安全问题已成为社会关注的焦点。当前一种有效的应对方式是通过分析数据安全威胁场景的特征形成事件规则，结合规则引擎进行事件告警输出。但在真实环境中往往存在复杂的攻击，规则单一、匹配深度过浅及无关联性会导致大量的攻击行为遗漏和告警不精准问题。因而，复杂事件处理（Complex Event Processing，CEP）应运而生。本文主要结合CEP技术介绍数据安全场景案例溯源分析。
二、数据安全典型场景和CEP技术
数据安全主要包含数据安全传输、脱敏、加密、防泄露和数据溯源等场景。
数据安全传输主要是保证数据的机密性、完整性和不可否认性，以防止数据被窃听和篡改，数据加密既可以保证数据安全传输，也能保证数据安全存储，数据认证可使用消息认证码、数字签名技术来实现。
数据脱敏是对敏感数据进行变形处理，保护隐私信息，如身份信息、手机号、银行卡等，常见的脱敏方法有取整、遮蔽、截断、重排、FPE加密或使用脚本变换等。
数据防泄露一是要保证数据存储位置安全可靠，严格控制敏感数据访问权限，记录好数据相关操作记录。二是尽可能对敏感数据脱敏或加密，做到即使泄露，也不会造成过大的损失。
数据溯源主要是在触发数据泄露事件后能够追踪溯源，通过关联分析定位责任人，也可以发现潜在的威胁，加固环境，避免以后发生。
复杂事件处理（Complex Event Processing，CEP），通过关联、时序、聚合等方式对多种数据进行分析处理，以发现一些有价值的信息，是大数据处理的关键技术之一。CEP引擎是高效快速处理复杂事件的技术方案，它使得规则易调整、易管理，处理性能高效，能够使安全告警事件得到更清晰、更自然的表达。
目前，市面上CEP引擎主要有：Drools，是Java编写的CEP引擎，核心为将规则集合，以规则过滤或关联条件为节点生成网状结构，数据会在网状结构中流动并在节点临时停留，利用空间换时间思想避免重复执行相同条件以提升性能；Flink CEP，是基于Flink计算框架衍生出的一个计算算子，是实时复杂事件处理的解决方案，它利用NFA（非确定有限自动机）对象进行状态管理；Siddhi，是用于实时事件分析的开源引擎，它支持典型的事件检测模式，如筛选器、窗口、关联的事件模式，以及更高级的功能，如事件分区、将数据库值映射到事件等。Siddhi是一种轻巧、易集成的开源CEP引擎，它能识别事件流中需要关注的特征事件，并进行实时分析处理。Siddhi与流框架Flink能友好集成，并获得不错的处理性能。
由于数据安全溯源场景往往比较复杂，迫切需要一个通用的CEP引擎框架来支持各种检测场景。本文的第三部分将介绍CEP技术在数据安全场景中的应用。
三、基于CEP的数据安全场景分析
当前数据安全事件层出不穷，数据的安全传输、脱敏、加密、防泄露等主要是事前防范措施，本文主要是围绕数据溯源场景，基于CEP引擎对数据泄露相关事件进行关联分析，追根溯源。在事件运营整个流程中，针对安全设备发来的安全日志以及数据访问和传输日志，再经过平台解析、增强、归一化等技术标准化后，就需要使用CEP规则引擎对标准化的日志做深度关联分析，生成安全告警事件（如图1所示），并推送给安全运维人员，从而完成防护—检测—响应的整个安全事件运营的闭环。
随着数据安全威胁越发凸显，数据安全需求与分析场景也正变得越发错综复杂，为了适应快速变更的场景需求和保护数据的价值，规则引擎的设计架构需具备灵活的语义定制、友好的规则扩展以及高效的大数据处理能力等特点。
另外，根据日志的存储特性，CEP规则引擎可分为实时和离线两种分析模式，下面分别介绍这两种模式在数据安全事件分析场景中的应用。
3.1 实时复杂事件处理
为了快速发现数据安全事件，需要实时处理设备日志，因此需要基于实时的流式大数据处理框架开发CEP规则引擎。一般情况下，将一个数据安全事件检测场景部署到安全运营平台上，需要经历如下步骤：
Step1：理解数据安全事件的表现特征；
Step2：推理设备日志的字段特征；
Step3：归纳事件检测逻辑，并转化成事件处理语言（EPL）；
Step4：将EPL集成到CEP规则引擎中并执行；
经过上述步骤后，CEP规则引擎就可以加载该安全场景的事件检测规则，当符合该规则检测模式的设备日志进入CEP规则引擎后，即可触发生成事件。
基于Flink和Siddhi开发CEP规则引擎，是实时事件处理的典型案例，其事件处理流程的架构如图2所示。
下面以一个实际业务中的数据安全威胁检测场景为例：攻击者通过若干已知账号和通用密码尝试登陆（UEBA异常行为——单设备登陆多个不同账号），成功后登陆特定用户的confluence、邮箱等，翻阅并下载敏感信息（短时间内下载大量文件），如服务器密码、敏感文件等，进而攻陷了一批服务器，造成严重的数据泄露。该场景涉及三种日志：登陆认证、Web访问和文件传输。经过分析可知，该场景的日志具备如下特征：
登陆认证日志：多次认证失败后突然成功；
Web访问日志：某设备突然登陆若干不同的账号，偏离以往日常行为；
文件传输日志：短时间内下载大量文件。
上述特征均可以使用CEP规则引擎内置的算子来表示。
使用EPL将事件检测逻辑定义出来，然后将EPL加载到CEP规则引擎中，通过解析校验EPL等流程，最终得到一个物理执行流程图并分发到集群的各个worker节点，开始执行上述事件检测规则。
一般情况下，多数CEP引擎都提供了状态机的方案，按照事件检测规则对实时日志流进行模式匹配，在上述安全事件检测规则的具体执行过程中，有限状态机的执行过程如图3所示：
首先，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引擎，可以灵活高效进行数据安全场景的溯源分析，快速还原数据泄露过程的全貌，对责任定位、环境加固、安全预防起着重要作用。
3.2 离线复杂事件处理
虽然实时处理能检测到很多数据泄露的场景，但由于部分场景时间跨度长，且是一次性接入的历史日志，因此急需离线复杂事件处理模式。离线模式可基于历史日志，支持长时间跨度的威胁分析，还原攻击事件。绿盟科技开发出一套通用的离线规则执行框架，用以支持单源、多源关联分析、复杂事件处理以及自定义插件类规则，支持更多的场景分析，同时兼顾效率和资源。离线处理整体架构如图4所示。
规则与任务注册模块：支持在界面配置离线规则和执行模式，并注册至离线任务表中，由任务调度模块调用。
任务调度模块：常驻进程，用来监控任务表，根据任务信息从2种执行模式中选择其一：（1）立即执行，即手动触发的一次性任务；（2）周期性执行。
规则执行模块：根据配置和调度信息，基于对设备告警或流量日志、文件传输日志的简单查询或关联聚合等操作，执行规则，生成相应事件，最后将任务执行状态（成功/失败）更新至任务表。
下面我们结合具体APT攻击导致数据泄露实例场景来说明：攻击者首先通过端口和漏洞扫描尝试，发现开启SSH服务，然后制作密码字典进行暴力破解，期间有SQL注入尝试，获取密码、权限等，成功登陆系统（SSH登陆成功），进而安装病毒程序或工具进行木马远程控制活动，获取持久控制权限，登录后阅读或传输敏感文件，导致数据泄露，造成严重的数据安全事件。其攻击流程如图5所示。
根据攻击阶段的关键动作可提取特征：（1）侦查：如端口、Web漏洞扫描；（2）定向攻击：账号爆破、SQL注入等；（3）攻陷+入侵：账号爆破成功、系统登录成功等；（4）安装工具：感染木马、病毒等；（5）恶意活动：远程控制、敏感文件传输、数据泄露等。
离线模式检测当前APT攻击方法：
（1）首先根据数据攻击场景提取的关键特征配置规则，这里可以配置为5个阶段：S1（端口扫描）->S2（SSH暴力破解）-> S3（SSH登录成功）-> S4（感染木马病毒）-> S5（数据泄露）；
（2）配置完规则后选择执行模式（立即或周期执行），并注册到任务表中；
（3）任务监控进程根据注册信息执行对应任务；
（4）执行：由于是离线溯源，日志都已存储至ES中，因此可以从任意阶段开始搜索。
由于面临海量日志的关联，需解决好关联时的性能问题。这里采用最小日志源双向关联算法，核心思想为先找到各阶段各个日志源命中数量的最小值，提取关键关联条件字段信息，如sip、dip等，然后结合关联条件，将其作为前一步或后一步的追加复合搜索条件，反复迭代搜索，获取最终待关联分析的日志最小数据量，在内存数据库中完成聚合关联分析处理。
以三个日志源[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）增加反查机制，进一步降低数据量。
可以看到，定义好场景和特征后，数据泄露相关场景可以灵活通俗地转变成引擎内置识别的方式去溯源检测，使场景分析的门槛大大降低，人人都可以基于业务中的场景实例做实战分析。
四、总结
本文主要介绍了复杂事件处理相关技术在数据安全典型场景中的应用，并基于实时和离线两种安全事件分析模式进行了具体数据泄露场景案例的溯源分析。当前，复杂事件处理在网络安全行业具有重要的应用价值，尤其在数据安全事故频发的现状下越发重要。但数据泄露的场景分析、数据窃取、滥用及加密等课题仍任重而道远。在设计上，需要更加完善的数据安全治理和评估框架体系。在技术上，需要对性能、多样性和扩展性做持续探索和优化。
版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。