足“當(dāng)郵件賬號2次登錄的IP位置距離大于2次登錄時間內(nèi)飛機(jī)的最大飛行距離時,該賬號即為異常賬號”的場景分析規(guī)則即為異常登錄行為。對符合該類場景規(guī)則的數(shù)據(jù)關(guān)聯(lián)分析最終生成告警,并由相關(guān)人員進(jìn)行不同處置。

首先通過數(shù)據(jù)采集層獲取的主機(jī)類日志,識別郵件登錄日志,對郵件登錄日志進(jìn)行去重去噪分析及語義分析,由于生產(chǎn)環(huán)境的數(shù)據(jù)類型各異,數(shù)據(jù)采集量達(dá)到上億級,所以依據(jù)該場景以1 h為單位進(jìn)行分析。

1.4.1 郵件系統(tǒng)登錄數(shù)據(jù)中的字段定義

Affiliated_Network:郵件登錄IP所屬網(wǎng)絡(luò);

Server_IP：郵件服務(wù)器IP地址;

Login_IP：郵件賬號登錄IP地址;

Login_Account：郵件登錄賬號;

LogIds：日志唯一標(biāo)識id;

Login_Longitude：郵箱登錄地址經(jīng)度;

Login_Latitude：郵箱登錄地址維度。

1.4.2 郵件賬號登錄事件流

設(shè)E為郵件賬號登錄日志事件集合：

E={en|n=1,2...n}, e={a,t0,t1}

a={ Affiliated_Network,Server_IP,Login_IP,Login_Account,LogIds,Login_Longitude,Login_Latitude}

1.4.3 郵件賬號異常登錄復(fù)雜事件EPL

事件描述：在T時間段內(nèi),同一郵件登錄賬號
2次登錄的IP地點的距離大于飛機(jī)在2次登錄時間內(nèi)所飛行的最大距離,飛機(jī)時速按500 km/h計算。

1.4.4 生成賬號異常登錄告警的流程

啟動Storm集群時將會啟動3個拓?fù)洳⒓虞dEsper引擎,每個拓?fù)涫荢torm運(yùn)行的一個實時應(yīng)用程序。在本文設(shè)計的模型中,Storm中的3個拓?fù)浞謩e對應(yīng)所設(shè)計模型中的3個引擎。

1）主題去重去噪拓?fù)?mdash;—TopologySrc

對應(yīng)模型中的標(biāo)準(zhǔn)化引擎,TopologySrc將采集到的郵件登錄日志進(jìn)行識別、解析、分類、去重、去噪,生成較為規(guī)整的數(shù)據(jù)流,發(fā)送到下一數(shù)據(jù)關(guān)聯(lián)加強(qiáng)的拓?fù)渲小?/span>

2）關(guān)聯(lián)加強(qiáng)拓?fù)?mdash;—TopologyConvert

對應(yīng)模型中的復(fù)雜事件語義分析引擎,將從上一個TopologySrc中標(biāo)準(zhǔn)化后的郵件登錄數(shù)據(jù)流發(fā)送到TopologyConvert,TopologyConvert將數(shù)據(jù)流與數(shù)據(jù)庫中的結(jié)構(gòu)化離線位置知識庫關(guān)聯(lián),加強(qiáng)出郵件登錄IP相關(guān)的位置信息,生成格式規(guī)范、信息完整的數(shù)據(jù)流。

3）分析拓?fù)?mdash;—TopologyAnalysis

對應(yīng)模型中的安全分析模型計算引擎,結(jié)合Esper引擎,經(jīng)過該步驟的事件流在Esper的1 h滑動事件窗口中,讀取數(shù)據(jù)庫中的EPL語句進(jìn)行場景關(guān)聯(lián)分析,EPL語句如下：

①create window EmailLoginFail1h.win:time_batch(1 hour) as EmailLogin;EmailLoginFail1h為
1 h內(nèi)登錄失敗時間窗口。

②create schema HostLoginDistance as (Affiliated_Network string,Server_IP string,Login_IP string,Login_Account string,LogIds string,SlogStartId long,SlogEndId long,Reality double,FlyMax double);HostLoginDistance為創(chuàng)建的模式,模式中存儲服務(wù)器IP、登錄IP等關(guān)鍵信息及經(jīng)過計算的飛行信息。

③insert into HostLoginDistance select e1.Affiliated_Network as Affiliated_Network,concat(e1.Server_IP,e2.Server_IP) as Server_IP,concat(e1.Login_IP,e2.Login_IP) as Login_IP,concat(e1.SN,e2.SN) as LogIds,e1.Login_Account as Login_Account,e1.SN as SlogStartId,e2.SN SlogEndId,calcReal(e1.Login_Longitude,e1.Login_Latitude,e2.Login_Longitude,e2.Login_Latitude) as Reality,calcFly(500D,e1.Login_Time,e2.Login_Time) as FlyMax from pattern [every e1=HostLogin -> e2=HostLogin(e2.Login_Account=e1.Login_Account and e2.Affiliated_Network=e1.Affiliated_Network and e2.Login_IP!=e1.Login_IP)]。

④insert into EventWarning select Affiliated_Network as affiliatedNetwork,Login_IP as attackSrc,Server_IP as attackTarget,SlogStartId as slogStartId,SlogEndId as slogEndId,LogIds as logIds from HostLoginDistance(Reality>FlyMax)。

符合條件的日志事件插入告警窗口,并生成最終告警,生成后,同一源IP符合關(guān)聯(lián)分析規(guī)則的生成一條告警,在平臺告警界面展示,安全分析人員在看到告警后可以回溯告警相關(guān)日志,進(jìn)行其他人工分析,告警處置人員則需要與登錄異常IP的資產(chǎn)責(zé)任人聯(lián)系,進(jìn)行排查,如確實存在問題則需封禁該源IP并按照公司內(nèi)部規(guī)定進(jìn)行其他處理操作。

以上安全關(guān)聯(lián)分析過程只需將去重去噪規(guī)則及郵件賬號異常登錄的復(fù)雜事件處理EPL固化存儲在數(shù)據(jù)庫中,待事件流到達(dá)自動執(zhí)行進(jìn)行關(guān)聯(lián)分析,無需人工干預(yù),最終將大量的數(shù)據(jù)轉(zhuǎn)化成人工易于觀察的安全告警信息。場景規(guī)則EPL也可以通過交互式用戶界面自定義配置,配置后,Esper及Storm將重啟,熱加載將新配置的EPL規(guī)則作為大數(shù)據(jù)安全關(guān)聯(lián)分析的依據(jù)。

 2 模型實現(xiàn)與應(yīng)用

本文設(shè)計的模型投入實際生產(chǎn)環(huán)境使用,模型的部署環(huán)境如下。

2.1 環(huán)境部署

使用了4臺Storm服務(wù)器組成的大數(shù)據(jù)分析集群,1臺數(shù)據(jù)庫服務(wù)器,1臺Web應(yīng)用服務(wù)器,均預(yù)裝CentOS 6.5的Linux發(fā)行版本,Java編譯環(huán)境（JDK 1.7）、Storm和Esper引擎。網(wǎng)絡(luò)結(jié)構(gòu)如圖5所示。

圖5 實際環(huán)境網(wǎng)絡(luò)結(jié)構(gòu)Fig.5 Real environment network structure

在大數(shù)據(jù)時代,機(jī)器的硬件已由以往的縱向拓展轉(zhuǎn)變?yōu)榱藱M向拓展,生產(chǎn)環(huán)境亦是如此,當(dāng)資源不夠時,大數(shù)據(jù)集群可以在現(xiàn)有部署結(jié)構(gòu)的基礎(chǔ)上,擴(kuò)展服務(wù)器節(jié)點的數(shù)量,提高安全日志的數(shù)據(jù)分析處理能力。搭建好大數(shù)據(jù)集群后,將程序部署在各節(jié)點,依照本文設(shè)計的模型實現(xiàn)大數(shù)據(jù)安全事件
分析。

2.2 實際運(yùn)行結(jié)果集分析

通過實際部署的環(huán)境及以上的操作步驟,實現(xiàn)了基于復(fù)雜事件處理的大數(shù)據(jù)安全事件分析模型的完整安全數(shù)據(jù)分析流程,并實現(xiàn)了依據(jù)預(yù)定義規(guī)則和用戶自定義建立攻擊模型進(jìn)而產(chǎn)生告警事件。在實際生產(chǎn)環(huán)境中,對采集裝置收集到的全量數(shù)據(jù)進(jìn)行處理,每天約采集到2億條來自不同系統(tǒng)、不同類型的數(shù)據(jù),基于Storm的高吞吐性及Esper引擎的關(guān)聯(lián)規(guī)則處理,在峰值時,每個worker每秒處理
2 000條數(shù)據(jù),一個Slave節(jié)點依據(jù)分配有3~4個worker,數(shù)據(jù)處理的速度優(yōu)于普通的數(shù)據(jù)處理速度,將海量數(shù)據(jù)快速識別、分解、標(biāo)準(zhǔn)化、分析,轉(zhuǎn)化為有用的信息,實現(xiàn)了大數(shù)據(jù)安全關(guān)聯(lián)分析實時、準(zhǔn)確的目標(biāo)。統(tǒng)計現(xiàn)場不同拓?fù)湓诓煌瑫r間節(jié)點處理的數(shù)據(jù)條數(shù),結(jié)果如圖6所示。

其中,影響不同拓?fù)涮幚硭俣鹊脑蛟谟冢呵爸猛負(fù)鋽?shù)據(jù)的輸出效率及每個拓?fù)涞臉I(yè)務(wù)實現(xiàn)邏輯,TopologySrc每時刻處理的數(shù)據(jù)量最大,因為TopologySrc處理的采集裝置通過消息隊列Kafka推送到Storm的數(shù)據(jù),而TopologySrc要做去重去噪會過濾掉一半左右不符合規(guī)范的數(shù)據(jù),故TopologyConvert中需處理的數(shù)據(jù)量就減少了。同時,TopologyConvert是TopologyAnalysis的前置,這也決定了TopologyAnalysis處理的數(shù)據(jù)量。
3個拓?fù)渲兄挥蠺opologyAnalysis結(jié)合了Storm和Esper 2類技術(shù),其余2個拓?fù)渲挥肧torm技術(shù)。

圖6 不同拓?fù)涞臄?shù)據(jù)處理效率Fig.6 Data processing efficiency of different topologies

從圖6不難看出,每天10點及15點左右數(shù)據(jù)量會達(dá)到一個峰值。但即使數(shù)據(jù)量增加,生產(chǎn)環(huán)境中使用所設(shè)計模型可以滿足大數(shù)據(jù)安全事件分析需求,該模型的實現(xiàn)是切實可行的。

 3 結(jié)語

本文采用Storm及Esper引擎,在已有大數(shù)據(jù)處理技術(shù)及復(fù)雜事件處理技術(shù)的結(jié)合改進(jìn)基礎(chǔ)上,設(shè)計并實現(xiàn)了基于復(fù)雜事件處理的大數(shù)據(jù)安全關(guān)聯(lián)分析模型,達(dá)到了數(shù)據(jù)關(guān)聯(lián)分析生成告警的實時性、準(zhǔn)確性的高要求。同時,在安全事件分析方法上采用了事件流語義分析、實時關(guān)聯(lián)分析兩種事件分析技術(shù)。與傳統(tǒng)的大數(shù)據(jù)安全分析方案相比,拋棄了人工的干預(yù),高效地關(guān)聯(lián)了事件關(guān)鍵信息,生成了實時告警,靈活實現(xiàn)了規(guī)則熱加載。所設(shè)計的模型投入生產(chǎn)環(huán)境中使用,有實際應(yīng)用價值。