安全事件標準化
一般的日誌系統,爲了接收日誌的效率，不去做日誌的標準化工作，收集大量冗餘日誌在數據庫，而龐大的數據庫在檢索時導致效率越來越低，更別提自動掃選出故障。當故障發生後很長時間，依然被動的在數據庫中，人工查找可疑故障日誌，效率低下。
然而，在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事件歸一化記錄格式如圖2、圖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最佳實踐》一書。