安全事件標準化

安全事件標準化

 

      通常的日誌系統,爲了接收日誌的效率，不去作日誌的標準化工做，收集大量冗餘日誌在數據庫，而龐大的數據庫在檢索時致使效率愈來愈低，更別提自動掃選出故障。當故障發生後很長時間，依然被動的在數據庫中，人工查找可疑故障日誌，效率低下。

      然而，在OSSIM系統中不只須要統一格式，並且要專門的屬性，這位系統中的關聯分析引擎的數據源奠基了良好的基礎，咱們先看幾個典型字段及說明：

• Alarm 報警名稱

•  Event id 安全事件編號

• Sensor id: 發出事件的傳感器編號

• Source IP :src_ip 安全事件源IP地址

• Source Port :src_port 安全事件源端口

• Type 類型分爲兩類一類是detector，另外一類是monitor

• Signature 觸發安全事件的特徵值

• Reliability 安全事件的可信度（描述了一個檢測到的攻擊是否真的成功可能性，側面反映了安全事件的嚴重性質）

爲了更好的學習第2章介紹的SIEM控制檯，下面先看幾個統一格式安全事件的實例，

在Redis服務器中處理大量的非結構化數據，但最終通過一系列規則檢測發出的報警，再通過聚合後產生的聚合報警具備統一格式，並集中存儲在MySQL數據庫中。下面給出典型的記錄格式。

1）Raw Log典型記錄格式如圖1所示。

圖1 Raw Log記錄格式

2） SIEM事件歸一化記錄格式如圖二、圖3所示。

圖2 事件歸一化處理格式

圖3 SIEM記錄格式

在OSSIM中的事件是如何實現存儲呢？傳感器從各類網絡設備和服務器上經過Rsyslog收集原始日誌，存儲在Sensor所在服務器的硬盤等待處理，當收到日誌後，安裝在探針服務器上的代理開始工做，利用事先設定好的安全插件開始對日誌進行預處理（也就是進行歸一化處理），流程如圖4所示。

 

圖4傳感器日誌採集流程

Agent將插件收到的日誌送往Server再進行深度加工，將字段按照類別從新組合，成下面的格式（這樣就從RAW Log變成了歸一化處理的日誌，歸一化處理格式如表1所示。

表1 歸一化處理日誌格式

Date	Src_port
Sensor	Dst_ip
Interface	Dst_port
Plugin_id	username
Plugin_sid	password
Prority	filename
Protocol	Userdata1～Userdata5
Src_ip	Userdata6～Userdata9

 

 

歸一化處理，重要字段含義以下：

• 源和目標地址：在關聯分析中屬於很重要的內容。

• 源和目標端口：能夠分析訪問和試圖訪問的那些服務端口。

• 消息分類： 根據用戶登陸成功或失敗或者嘗試的消息分類。

• 時間戳： 這裏包括日誌消息在設備上產生的時間和系統接收消息的時間（由於有各類延遲存在，時間不一樣）。

• 優先級： 例如網絡設備(交換機)的日誌包含了優先級（設備供應商制定）。做爲規範化的一部分也須要日誌包含優先級。

• 接口： 經過那個網絡接口接收到的日誌消息。

原始日誌是規範化過程的一個重要環節，OSSIM在歸一化處理日誌的同時也保留了原始日誌，可用於日誌歸檔，提供了一種從規範化事件中提取原始日誌的手段。

通過歸一化處理的日誌，再經過TCP 3306端口存儲到MySQL數據庫中，接着就由關聯引擎根據規則、優先級、可靠性等參數進行交叉關聯分析，得出風險值併發出各類報警提示信息（詳情在後續章節再分析）。

圖5 日誌存儲

接下來，咱們再看個實例，下面是一段Apache的原始日誌，如圖6所示。

圖6原始日誌

先通過OSSIM系統收集加工後，再經過Web前端展示給你們，方便閱讀的格式如圖7所示。歸一化處理後的事件和原始日誌的對比方法咱們在後面還會講解。

圖7 歸一化處理之後的Apache訪問日誌

在圖7所示的例子當中，僅使用了Userdata1和Userdata2，並無用到Userdata3～Userdata9這些是擴展位，主要是爲了預留給其餘設備或服務使用。

圖8 SIEM控制檯下的主機標識形式

通過歸一化處理以後，目標地址會標記成Host-IP地址的形式，例如：Host-192-168-0-1。實際上歸一化處理這種操做發生在系統採集和存儲事件以後，關聯和數據分析以前，在SIEM工具中把採集過程當中把數據轉換成易讀懂的格式，如同圖7顯示的那樣，採用格式化的數據咱們能更容易理解。若是您但願繼續學習有關安全事件標準化的技術請參考《開源安全運維平臺-OSSIM最佳實踐》一書。