以企業入侵檢測日志分析為場景漫談大數據安全

寫這篇文章有三個原因，一是在工作中一直艱難地摸索著這塊也曾寫過一篇很粗略的大數據之安全漫談 (想繼續吐槽);二是看到了阿里的招聘廣告-一起來聊聊這個新職位：大數據安全分析師;三是整個2015的RSA會議 Intelligence Data-Driven 出境率太高了，于是想談談。

大數據安全，顧名思義，用大數據技術解決安全問題。核心——解決安全問題，手段——大數據技術。

我們從核心出發，安全問題抽象來說就是攻擊與防御，接下來明確防御對象是什么?攻擊目的是什么?攻擊手段是怎樣的?攻擊者的特征?一句話——搞清楚誰為了什么目的通過什么手段攻擊了誰。

比如說防御對象有企業內部安全，有對外發布產品安全，同時防御對象又決定了不同的攻擊目的與攻擊手段，有企業入侵，有對產品本身的攻擊(比如說軟件破解，游戲外掛，訂單欺詐)，有對產品用戶的攻擊(比如利用支付漏洞竊取用戶財產)，同樣發起攻擊的攻擊者們特征又是迥異的，有無特定目的批量散彈攻擊，有靠接單掙錢的賞金黑客，有外掛作坊等等。

在明確了的問題后，接下來就是確定解決問題的方法，傳統方法的缺陷是什么?大數據技術解決問題的優勢又是什么?比如說WAF系統中，傳統的檢測機制——基于簽名庫(黑名單)，缺陷是對未知漏洞(0day) 不可感知。解決方案——基于異常(白名單)，如何鑒定異?！?a href='/map/jiqixuexi/' style='color:#000;font-size:inherit;'>機器學習(學習正常的行為模式)，如何對大量數據鑒定異?！髷祿夹g支撐下的機器學習。

在這一過程，我們需要具備領域知識(安全知識)，數據科學知識(數據分析知識，機器學習，文本分析，可視化)，大數據知識(數據收集，數據存儲，數據傳輸，數據分布式計算)，編程知識。

路漫漫其修遠兮，吾將死磕到底…

本文就以企業入侵檢測日志分析為場景來談談大數據安全。

一、安全領域

大數據安全分析最容易走偏的就是過度強調數據計算平臺(大數據)，算法(機器學習)，而失去了本心，忽略了我們使用這一技術的目的，以入侵檢測為例，我們希望日志分析達到以下目的：

如何感知威脅，我們可以先對攻擊者進行畫像，攻擊手段進行建模。

1. 攻擊者畫像

這里是非常粗略的分類，實際上我們可以用關系圖(社交網挖掘)的方式將攻擊者關聯起來，對取證抓壞人也是有效果的。

2. 攻擊手段建模

相信喜歡擼paper、ppt的人對Attack Models、 Attack Trees、 Kill Chain這三個術語特別熟悉，特別是看過2013年后的各大安全會議文檔后，其實說的都是攻擊行為建模。

(1) 滲透模型

(2)普通攻擊模型

(3)攻擊模型(升級版)

注意以上攻擊手段只是高度精煉的攻擊環節，實際的攻擊檢測中，我們需要盡可能精確的還原入侵場景(包括對應的正常場景是怎樣的)，從入侵場景中提煉關鍵環節，從而檢測出異常的攻擊行為。

在熟悉了殺生鏈(kill chain)后，接下來要做的就是在構成鏈的每個環節進行狙擊，注意越往后成本越高。而每個階段的操作必然會雁過留痕，這些痕跡，就是我們進行數據分析的數據源，知道對什么數據進行分析是最最重要的(數據量要恰到好處，要多到足夠支撐數據分析與取證，要少到篩選掉噪音數據)。

二、數據科學

在明確了我們要解決的問題，接下來我們來普及一下數據分析的基本流程：

從上圖可以看出，傳統的數據分析在模型選擇上都僅僅用了0——規則，1——統計分析，設置基線，依靠閾值的方法。

數據分析與領域知識是緊密耦合的，千萬不要誤入套用算法的誤區，要進行基于行為建模(攻擊行為，正常行為)的數據分析，可以從單點分析(單條數據的深度分析，例如分析單條HTTP請求是否是攻擊請求)，簡單的關聯分析(例如分析一個session下，多條HTTP請求的關聯關系，是否為掃描器行為，是否有嘗試繞過WAF的操作，是否符合攻擊鏈的關鍵步驟)，復雜的關聯分析(例如Web日志，數據庫日志，操作系統日志的聯動分析，例如SQL注入寫馬攻擊中HTTP請求對應的數據庫操作，主機操作)來逐步深入分析，當攻擊場景很復雜的時候，我們可以考慮從結果出發的方式來回溯，這些技巧都取決于領域知識。

下面列舉一些傳統的關聯技巧：

1.規則關聯

If the system sees an EVENT E1 where E1.eventType=portscan

followed by

an event E2 where E2.srcip=E1.srcip and E2.dstip = E1.dstip and

E2.eventType = fw.reject then

doSomething

2.漏洞關聯：將漏洞掃描數據和實時事件數據結合起來，以便幫助減少假陽性 false positive

e.g. 如果IDS檢測到了端口掃描，可以對網絡進行例行的漏洞掃描，來驗證問題中的主機是否真的打開了個端口，是否容易遭到攻擊

3.指紋關聯

4.反端口關聯

if (event E1.dstport != (Known_Open_Ports on event E1.dstip))

then

doSomething

5.關聯列表關聯： 外部情報列表，例如攻擊者列表

6. 環境關聯 e.g.如何知道公司的假期安排，可以使用這一信息，在每個人都不上班的時候發現內部資源的訪問。

• 休假時間表
• 業務時間
• 假日計劃
• 內部資源訪問權限
• 重復的網絡“事件”例如漏洞掃描
• 計劃的系統、數據存儲備份等
• 維護安排，例如操作系統補丁等
• 常見的關聯搜索模式：
• x次登錄失敗后有一次登錄成功
• 創建非管理員賬戶之后進行權限提升
• VPN用戶在工作時間內/外登錄，并向網絡之外傳輸更多的數據
• 網絡上的一臺主機開始攻擊或者探查網絡上的其他主機
• 在很接近的時間內X次嘗試訪問用戶沒有權限的共享/文件/目錄等
• 從同一個工作站以多個用戶名登錄
• 在多個系統上有多個防病毒軟件失效
• 攻擊DMZ系統，隨后有出站連接
• 攻擊DMZ系統，隨后在同一個系統上更改配置
• 在幾分鐘內有許多Web 404，401 500和其他web錯誤碼

以上都是單靠領域知識感知威脅，領域知識的缺陷是太依賴于專家知識了，而專家知識是有限的，這個時候機器學習就可以發揮長度了，例如理工渣眼中的HMM及安全應用。

即使是使用機器學習也仍離不開安全領域知識，有安全領域背景的人在數據預處理階段、feature選擇階段會事半功倍，比如對訪問日志進行白名單建模時，從訪問日志中篩選出異常日志(攻擊日志、不存在的日志、服務器錯誤日志)，需要安全領域知識(知道什么是攻擊)、web服務器知識(知道什么是異常，url重寫)進行數據清理;比如HMM web安全檢測 feature的選擇，我們知道攻擊注入點在哪里，就不需要進行運氣流的feature選擇、降維處理。

機器學習雖然能彌補單靠領域知識分析的缺陷，但由于其存在準確率的問題而不能直接在線上應用，只存在于運維離線的環境下?；蛟S是算法需要優化，但個人認為能解決當前方法不能解決的問題就是很大的進步了，比如說能發現一個0 day。我想當電燈剛發明出來的時候，也是絕對沒有蠟燭好用，也希望架構師們不要單一的靠準確率這個唯一的標準來評價機器學習的結果。

在知道了如何進行數據分析后，接下來的就是如何在數據量巨大的情況下進行分析。玩單機腳本的年代要一去不返了，分布式需要搞起。

三、大數據技術

我們要使用的大數據技術的核心其實就是是分布式存儲與分布式計算，當然能利用已有的數據預處理接口，算法接口也是很有幫助的。

以下是一個完整的大數據分析架構圖：

得出這個架構，也走了不少彎路，最開始由于不了解ElasticSearch的特性，采用的是直接使用ElasticSearch對數據源進行分析與結果存儲，ElasticSearch全文索引的設計決定了ta不適合頻繁寫操作并且會很夸張的擴大數據量，所以最后引入了更適合及時讀寫操作的HBase數據庫來做持久化存儲，同時增加了算法層這塊，只在ElasticSearch離存儲最終結果。

大數據有著龐大的生態圈，較之機器學習(人工智能，深度學習)的發展，數據存儲、數據計算方面簡直是突飛猛進，為算法的發展提供了良好的支撐，當然學習的成本也非常高。

萬事具備，就差第四個能力——編程，這是將想法落實的能力，否則都是鏡花水月。不是有一句老話嗎?“Talk is cheap, show me the code”。

四、編程

對于戰斗力負5的渣，編程方面的心得是在太多了，每天都有新發現，這里就說說經驗之談吧。

1. 語言選擇

先使用Python或者R去做小數據量(樣本數據)的分析，然后使用Java實現分布式算法(在大數據的生態圈中，為了避免不必要的麻煩還是用原生語言Java好)。

2. 日志格式問題

日志處理中，輸入日志的格式會直接影響模型運行時間，特別是采用正則的方式對文本格式的輸入進行解析會極度消耗時間，所以在模型運算時需要先對日志進行序列化處理，Protocol Buffer就是很好的選擇，但千萬注意jar包的版本哦。

結語

大數據安全涉及的內容非常深入，每個方面都是幾本厚厚的書，這里只是非常淺顯的漫談，給大家一幅平面的框架圖，期待更多的數據科學(數據分析，機器學習，大數據處理)領域的人進入這個行業，或者安全行業的人開拓自己在數據分析方面的深度，大數據安全將發展的更好，不僅僅是叫好不叫座了。