一般的日志系統,為了接收日志的效率，不去做日志的標準化工作，收集大量冗余日志在數據庫，而龐大的數據庫在檢索時導致效率越來越低，更別提自動掃選出故障。當故障發生后很長時間，依然被動的在數據庫中，人工查找可疑故障日志，效率低下。

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

• Alarm 報警名稱
• Event id 安全事件編號
• Sensor id: 發出事件的傳感器編號
• Source IP :src_ip 安全事件源IP地址
• Source Port :src_port 安全事件源端口
• Type 類型分為兩類一類是detector，另一類是monitor
• Signature 觸發安全事件的特征值
• Reliability 安全事件的可信度(描述了一個檢測到的攻擊是否真的成功可能性，側面反映了安全事件的嚴重性質)

為了更好的學習以后要介紹的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所示。

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

• 源和目標地址：在關聯分析中屬于很重要的內容。
• 源和目標端口：可以分析訪問和試圖訪問的那些服務端口。
• 消息分類： 根據用戶登錄成功或失敗或者嘗試的消息分類。
• 時間戳： 這里包括日志消息在設備上產生的時間和系統接收消息的時間(因為有各種延遲存在，時間不同)。
• 優先級： 例如網絡設備(交換機)的日志包含了優先級(設備供應商制定)。作為規范化的一部分也需要日志包含優先級。
• 接口： 通過那個網絡接口接收到的日志消息。

原始日志是規范化過程的一個重要環節，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最佳實踐》一書。

本文出自 “李晨光原創技術博客” 博客，謝絕轉載!