復雜事件處理（CEP）技術在數據安全場景中的應用
大數據時代，數據竊取、篡改、個人隱私泄露等數據安全問題已成為社會關注的焦點。當前一種解決方式是通過分析數據安全威脅場景的特征形成事件規(guī)則，結合規(guī)則引擎進行事件告警輸出。但在企業(yè)生產及工作環(huán)境中往往存在復雜的攻擊，規(guī)則單一、匹配深度過淺及無關聯性會產生大量的攻擊行為遺漏和告警不精準問題。復雜事件處理(CEP, Complex Event Processin-g)技術應運而生。
基于復雜事件處理技術，通過關聯、時序、聚合等方式對多種數據進行分析處理，可以發(fā)現一些有價值的信息，是大數據處理的關鍵技術之一。目前，市面上CEP引擎主要有：
- Drools是Java編寫的CEP引擎，核心為將規(guī)則集合，以規(guī)則過濾或關聯條件為節(jié)點生成網狀結構，數據會在網狀結構中流動并在節(jié)點臨時停留，利用空間換時間思想避免重復執(zhí)行相同條件以提升性能;
- Flink CEP是基于Flink計算框架衍生出的一個計算算子，是實時復雜事件處理的解決方案，它利用NFA(非確定有限自動機)對象進行狀態(tài)管理;
- Siddhi是用于實時事件分析的開源引擎，它支持典型的事件檢測模式，如篩選器、窗口、關聯的事件模式，以及更高級的功能，如事件分區(qū)、將數據庫值映射到事件等;
- Siddhi是一種輕巧、易集成的開源CEP引擎，它識別事件流中需要關注的特征事件，并進行實時分析處理，Siddhi與流框架Flink能友好集成，并獲得不錯的處理性能。
當前數據安全事件層出不窮，數據的安全傳輸、脫敏、加密、防泄漏等主要是事前防范措施，我們將圍繞數據溯源場景，基于CEP引擎對數據泄露相關事件進行關聯分析，追蹤溯源。在事件運營整個流程中，針對安全設備發(fā)來的安全日志以及數據訪問和傳輸日志，再經過平臺解析、增強、歸一化等技術標準化后，就需要使用CEP規(guī)則引擎對標準化的日志做深度關聯分析，生成安全告警事件(如圖1)，并推送給安全運維人員，從而完成防護—檢測—響應的整個安全事件運營的閉環(huán)。
圖1 安全日志分析流程
數據安全需求與分析場景非常復雜，為了適應快速變更的場景需求和保護數據的價值，規(guī)則引擎的設計架構需具備靈活的語義定制、友好的規(guī)則擴展以及高效的大數據處理能力等特點。另外，根據日志的存儲特性，CEP規(guī)則引擎可分為實時和離線兩種分析模式，下面分別介紹這兩種模式在數據安全事件分析場景中的應用。
模式一、實時復雜事件處理
為了快速發(fā)現數據安全事件，需要實時處理設備日志，因此需要基于實時的流式大數據處理框架開發(fā)CEP規(guī)則引擎。一般情況下，將一個數據安全事件檢測場景部署到安全運營平臺上，需要經歷如下步驟：
- Step1：理解數據安全事件的表現特征;
- Step2：推理設備日志的字段特征;
- Step3：歸納事件檢測邏輯，并轉化成事件處理語言(EPL);
- Step4：將EPL集成到CEP規(guī)則引擎中并執(zhí)行;
經過上述步驟后，CEP規(guī)則引擎就可以加載該安全場景的事件檢測規(guī)則，當符合該規(guī)則檢測模式的設備日志進入到CEP規(guī)則引擎后，即可觸發(fā)生成事件。
基于Flink和Siddhi開發(fā)CEP規(guī)則引擎，是實時事件處理的典型案例，其事件處理流程的架構如圖2。
圖2 Flink-Siddhi流程圖
下面以一個實際業(yè)務中的數據安全威脅檢測場景為例：攻擊者通過若干已知賬號和通用密碼嘗試登陸(UEBA異常行為—單設備登陸多個不同賬號)，成功后登陸特定用戶的confluence、郵箱等，翻閱并下載敏感信息(短時間內下載大量文件)，如服務器密碼、敏感文件等，進而攻陷了一批服務器，造成嚴重的數據泄露。該場景涉及到三種日志：登陸認證、Web訪問和文件傳輸。經過分析可知，該場景的日志具備如下特征：
- 登陸認證日志：多次認證失敗后突然成功;
- Web訪問日志：某設備突然登陸若干不同的賬號，偏離以往日常行為;
- 文件傳輸日志：短時間內下載大量文件。
上述特征均可以使用CEP規(guī)則引擎內置的算子來表示。
使用EPL將事件檢測邏輯定義出來，然后將EPL加載到CEP規(guī)則引擎中，通過解析校驗EPL等流程，最終得到一個物理執(zhí)行流程圖并分發(fā)到集群的各個worker節(jié)點，開始執(zhí)行上述事件檢測規(guī)則。
一般情況下，多數CEP引擎都提供了狀態(tài)機的方案，按照事件檢測規(guī)則對實時日志流進行模式匹配，在上述安全事件檢測規(guī)則的具體執(zhí)行過程中，有限狀態(tài)機的執(zhí)行過程如圖3所示：
圖3 CEP規(guī)則執(zhí)行EPL基本流程
首先，CEP規(guī)則引擎持續(xù)檢測第一步的登陸認證日志，如果檢測到多次認證失敗突然登陸成功的日志，則判定為異常，并將異常登陸認證日志緩存起來，記為集合A。同時，實時監(jiān)控集合A中日志源/目的IP，若有Web訪問日志短時間內登陸大量不同賬號，且登陸賬號的數量超過正常基線(或閾值)的情況，記為異常的Web訪問日志集合B。至此，得到了兩個日志集合A和B，并且將集合A和B中按源/目的IP條件關聯得到的集合記為[A&B]模式序列。
同理，以[A&B]模式序列中集合A的目的IP持續(xù)監(jiān)控文件傳輸日志是否有和關聯條件相匹配的文件傳輸日志，并且在登陸成功后的一段時間內發(fā)生了大量的文件傳輸行為，于是得到集合C。并最終得到[A&B->C]模式序列。如果該模式序列[A&B->C]不為空，則說明日志觸發(fā)該事件檢測規(guī)則，即可生成最終的賬號爆破成功后的數據泄露告警事件。
通過我們的CEP引擎，可以靈活高效處理數據安全場景的溯源分析，快速還原數據泄露過程的全貌，對責任定位、環(huán)境加固、安全預防起著重要作用。
模式二、離線復雜事件處理
雖然實時處理能檢測到很多數據泄露的場景，但由于部分場景時間跨度長，且是一次性接入的歷史日志，因此亟需離線復雜事件處理模式。離線模式可基于歷史日志，支持長時間跨度的威脅分析，還原攻擊事件。綠盟科技開發(fā)出一套通用的離線規(guī)則執(zhí)行框架，用以支持單源、多源關聯分析、復雜事件處理以及自定義插件類規(guī)則，支持更多的場景分析，同時兼顧效率和資源。離線處理整體架構如圖4所示。
圖4 離線規(guī)則執(zhí)行流程
- 規(guī)則與任務注冊模塊：支持在界面配置離線規(guī)則和執(zhí)行模式，并注冊至離線任務表中，由任務調度模塊調用。
- 任務調度模塊：常駐進程，用來監(jiān)控任務表，根據任務信息來選擇2種執(zhí)行模式：(1)立即執(zhí)行，即手動觸發(fā)的一次性任務;(2)周期性執(zhí)行。
- 規(guī)則執(zhí)行模塊：根據配置和調度信息，基于對設備告警或流量日志、文件傳輸日志的簡單查詢或關聯聚合等操作，執(zhí)行規(guī)則，生成相應事件，最后將任務執(zhí)行狀態(tài)(成功/失敗)更新至任務表。
下面我們結合具體APT攻擊導致數據泄露實例場景來說明：攻擊者首先通過端口和漏洞掃描嘗試，發(fā)現開啟SSH服務，然后制作密碼字典進行暴力破解，期間有SQL注入嘗試，獲取密碼、權限等，成功登陸系統(tǒng)(SSH登陸成功)，進而安裝病毒程序或工具進行木馬遠程控制活動，獲取持久控制權限，登錄后閱讀或傳輸敏感文件，導致數據泄露，造成嚴重的數據安全事件。其攻擊流程如圖5所示。
圖5 復雜持續(xù)攻擊數據泄露案例
根據攻擊階段的關鍵動作可提取特征：
(1)偵查：如端口、Web漏洞掃描;
(2)定向攻擊：賬號爆破、SQL注入等;
(3)攻陷+入侵：賬號爆破成功、系統(tǒng)登錄成功等;
(4)安裝工具：感染木馬、病毒等;
(5)惡意活動：遠程控制、敏感文件傳輸、數據泄露等。
離線模式檢測當前APT攻擊方法：
(1)首先根據數據攻擊場景提取的關鍵特征配置規(guī)則，這里可以配置為5個階段：S1(端口掃描)->S2(SSH暴力破解)-> S3(SSH登錄成功)-> S4(感染木馬病毒)-> S5(數據泄露);
(2)配置完規(guī)則后選擇執(zhí)行模式(立即或周期執(zhí)行)，并注冊到任務表中;
(3)任務監(jiān)控進程根據注冊信息執(zhí)行對應任務;
(4)執(zhí)行：由于是離線溯源，日志都已存儲至ES中，因此可以從任意階段開始搜索。
由于面臨海量日志的關聯，需解決好關聯時的性能問題。這里采用最小日志源雙向關聯算法，核心思想為先找到各階段各個日志源命中數量的最小值，提取關鍵關聯條件字段信息，如sip、dip等，然后結合關聯條件，將其作為前一步或后一步的追加復合搜索條件，反復迭代搜索，獲取最終待關聯分析的日志最小數據量，在內存數據庫中完成聚合關聯分析處理。
圖6 最小日志源雙向關聯搜索執(zhí)行流程示例
以三個日志源[s1,s2,s3]的多源關聯分析規(guī)則為例，描述詳細執(zhí)行邏輯：
(1)先查詢三個日志源的每個規(guī)則過濾條件分別命中的日志總數列表log_cnt_list =[cnt1,cnt2,cnt3], 假設cnt2為最小值;
(2)將第二個日志源過濾規(guī)則命中的日志數據Data2從日志數據庫中取出來，結合關聯條件(如s1.sip=s2.dip)，將s2的查詢結果Data2作為追加查詢條件，向前以及向后關聯查詢日志源s1和s3分別命中的日志數據Data1和Data3。需要注意的是，以Data2中的值作為約束關聯條件查詢s1或s3，可能會查詢不到結果，即Data1和Data3可能為空，若為空，則需要及時終止向前或向后關聯查詢，并退出規(guī)則執(zhí)行模塊，以避免對日志數據庫不必要的查詢并及時釋放系統(tǒng)資源。
(3)雙向查詢日志結束后，將查詢到的日志數據集[Data1,Data2,Data3]寫入到內存數據庫中，然后參與后續(xù)的關聯聚合并輸出事件，并及時清空內存中的臨時數據;
(4)增加反查機制，進一步降低數據量。
可以看到，定義好場景和特征后，數據泄露相關場景可以靈活通俗的轉變成引擎內置識別的方式去溯源檢測，使場景分析的門檻大大降低，人人都可以基于業(yè)務中的場景實例做實戰(zhàn)分析。
結語
通過上文對復雜事件處理相關技術在數據安全典型場景中的應用探討，并基于實時和離線兩種安全事件分析模式分析具體數據泄露場景案例的溯源實踐，我們可以看到復雜事件處理技術在網絡安全行業(yè)具有重要的應用價值，尤其在數據安全事故頻發(fā)的現狀下其價值體現將更加明顯。但數據泄露的場景分析、數據竊取、濫用及加密等課題研究仍任重而道遠。在設計上，需要更加完善的數據安全治理和評估框架體系;在技術上，需要對方案的性能、多樣性和擴展性做持續(xù)探索和優(yōu)化。
【本文是51CTO專欄作者“安全牛”的原創(chuàng)文章，轉載請通過安全牛（微信公眾號id:gooann-sectv）獲取授權】
