寫在之前

前面四天我們分別就 SIEM 的【登場之初】、【起源】、【核心角色】與【威脅管理】
分享 SIEM 的歷史背景、需求場景、核心功能與威脅框架，
希望能讓各位邦友先在比較概念層級的階段，
大致了解 SIEM 的應用跟這個解決方案主要在著墨的點與面向：

在第一天，我們梳理這次鐵人賽的目錄、設定這次 30 天的主題內容
在第二天，我們談了資訊與資安人員不同的視角看到的需求
在第三天，我們介紹 SIEM 的日誌收容、威脅偵測與報表告警的核心應用
在第四天，我們談了 SIEM 在資安市場的位置與威脅管理框架的整合應用

接下來的 10 幾天的鐵人賽文章，
會開始進入到 SIEM 的各個核心功能的細節剖析與分享，
無可避免的會比較技術性的角度再談，
但我會將這些技術面的介紹盡量與資安部門實務維運經驗做連結，
讓我們既能夠見樹也能見林。

系統日誌 (Event/Log)

當我們買齊我們想煮的菜後，接著就是開始清洗、清理與切除多餘的部位，然後就要把料丟到鍋裡、準備炒出一盤好的佳餚；系統日誌的正規化與欄位剖析的過程，就像是廚房備料的過程，雖然繁複但卻是最重要的第一步。

我們常使用 Event/Log 來代指資訊系統上面的系統日誌紀錄，
主要是管理員都希望透過事件紀錄來了解設備、服務或機器的運作狀態，
包含像是系統操作記錄、登入／登出紀錄等等。

當不同廠牌、來源廣泛的 IT 系統拋出日誌給到 SIEM 後，
第一件事情就是 SIEM 如何有效、自動的識別不同長相的日誌事件與格式，
這整個過程就是所謂的「正規化」(Normalization)。

日誌收集 (Event Collection)

目前主流的資訊系統，
像是伺服器、端點設備、應用程式、交換器、防火牆、作業系統...
普遍支援用不同的通訊協定 (Protocols) 來傳輸相關系統日誌，
包含 Syslog 與 SNMP 屬於主動型 (Inbound) 或是，
JDBC、Log file、SMB 或 API 被動型 (Outbound) 機制。

事件正規化 (Normalization)

當系統日誌透過任一通訊協定抵達 SIEM 後，
便開始正規化的流程，它的核心目標即是：
將原始日誌的格式與內容，轉變為 SIEM 本身可以儲存與分析的機制

正規化流程裡，最為關鍵的步驟即為 **欄位剖析 (Parsing) **，
將原始事件裡的相關資訊剖析到預定義或自定義的欄位 (fields)，
接著針對特定欄位識別來源日誌是否是已識別或是新發現的日誌來源，
再將相近原始事件依照剖析設定，生效相關佇列、長度、截斷或轉送等設定。

最後再將原始事件儲存在 SIEM 專門處理日誌來源 (Log Source) 的模組內。

內建/外擴的日誌模組

當日誌事件儲存模組預先由原廠將相關日誌識別機制寫在軟體時，
我們稱這類的日誌模組為內建支援的日誌來源，
亦即前面所提的正規化、剖析出每個日誌內獨特、有用的欄位這件事，
會由產品面協助我們把它完成。

如果今天日誌不在支援的表單時，常見的方式就會透過下載「擴充模組」，
例如特別針對 Palo Alto 防火牆日誌研製的 擴充 App，
以 QRadar SIEM 為例的 Palo Alto Networks App for QRadar，
就能夠為資安管理者將 QRadar 與 Palo Alto Networks 無縫整合，
簡化與提升來自 PA 防火牆日誌、告警事件，提供很快速回應的操作功能。

支援範圍外的日誌模組

如果今天日誌屬於企業自行研發的 AP，通常不會在制式產品內有所支援，
這時候就需要透過觀察原始事件格式跟長相，找出：

1. 如何讓日誌管理模組能夠 Unique 識別這個日誌來源
2. 如何從日誌剖析出我們需要的特定欄位資訊
3. 將日誌配對到新的或既有的日誌模組內儲存

這個動作對資安工程師來說是最繁瑣，也是最枯燥的一環，
但千里之行，始於足下，處理完善的日誌的蒐集、分類、正規化、欄位剖析，
才能夠 SIEM 在後續的關聯分析應用實戰上，事半功倍。

明日預告

今天我們簡介了日誌收集的過程，
以及 SIEM 會透過怎麼樣的機制將原始資料轉化成適合自身平台的儲存，
明天我們會繼續第二篇的 SIEM 日誌收容技術 II，
再繼續針對 SIEM 做日誌收容時，
分享幾種常用的通訊協定與 Parsing 機制。

參考來源

1. Palo Alto Networks App for QRadar https://exchange.xforce.ibmcloud.com/hub/extension/Palo%20Alto%20Networks:Palo%20Alto%20Networks%20App%20for%20QRadar