資訊安全新知分享
NEITHNET 資安實驗室
一般來說，資安人員執行資訊安全的相關分析時，都會從不同的維度去執行檢查跟資料關聯。比方說使用 Endpoint 的資料在 MDR 上面做分析跟 policy 的比對；或是在相關設備做 IOC 情資分析與網路流量資料比對。另外資安人員也經常參照其他的資料做關聯，最常見的就是使用 Firewall 的 Traffic log 來分析。
但是 Firewall 設備品牌眾多，各家都有自己的格式，如果要處理各種格式的 log ，無疑需要消耗相當多的人力與時間，我們今天就來簡單談一下如何處理這些 log。
基本的方式會直接從設備匯出 log 檔案，再透過 SIEM 的輸入功能，把 log 檔案匯入資料庫做分析。但是這樣操作比較沒有效率，所以通常是把設備的 log 透過 Syslog 的傳輸協定，直接傳送給 SIEM，這樣做更直接，而且不用透過檔案轉介。（參考下圖）
把資料匯入 SIEM 來分析時，我們經常遇到這些問題，如：
- 分隔符號不固定
比方說 key-value 資料是用 = 做為 key 和 value 分隔符號，但有些設備匯出可能還會有其他分隔符號干擾。
- 資料欄位內有空格
如果 log 格式有使用雙引號當做每個欄位資料的分隔符號，如果有些欄位會出現雙引號，有些則沒有；甚至還有 escape char。
- Key-value資料不固定
Log 資料的 key-value 順序不固定，或是數量不固定。這樣的格式也是比較鬆散，輸入做log剖析都很辛苦。
- 非一般格式化的資料
大部分 log 在設計的時候，都會考慮到使用 log 資料的方便性。但是如果遇到既不是關聯式資料，也不是 JSON 格式時，剖析 log 資料的步驟就會相當繁瑣。
綜合以上的狀況，一般都會盡量讓設備可以匯出良好格式化的 log 資料，比方說：
- Key-Value
- CSV (comma-separated values)
- CEF (for Syslog)
- JSON
我通常會選擇使用 JSON 來當作設備跟 SIEM 中間的傳輸格式。
因為 JSON 格式有以下優點：
- 語法簡單。
- 有支援 schema。
- 剖析速度快。（不論 server 端、前端，還是手持裝置)
那對照第一張圖的流程來說，我們的資料處理就會變成這樣：
而在 Preprocess 這個方塊，執行下列動作：
- 去除冗餘資料
像是多出來的標點符號或分隔符號。 - 過濾資料
去蕪存菁。後續不用的資料先過濾掉。 - 格式轉換
比方說把 Key-Value 轉換成 JSON，或是把 CSV 轉換成 JSON。
現在市面上有許多現成的工具，或是 GitHub 上的開源程式，都可以做到上述這些工作。比方說：
- 在 BASH 裡面，使用 AWK, sed 等工具來框選某段文字，或是剖析、分切資料成文字區段。
- 透過程式語言來處理，比方：Python 或是 Golang 來撰寫。（有需要的讀者可以去 GitHub 搜尋CSV, JSON, KV 等關鍵字。）
以常見的開源專案 Elasticsearch 來當作例子，我們最後再加上一個 Filebeat 模組來幫我們把 JSON 檔案讀取進來 Elasticsearch :
Filebeat 原生就支援 JSON 格式的檔案，可以直接寫入Elasticsearch。底下是 filebeat.yml 的設定範例，這樣的設定非常簡潔：
最後再補充一下， ELK 的系統裡面，當我們還要對 JSON 做處理的時候，以下這幾個是不錯的選擇：
- Filebeat 的 Processor
- 丟給下一階的 Logstash 處理
- 使用 Elasticsearch的 Ingest Pipeline
這三個方案中，以第三個方案最多人應用，因為使用上彈性較高，而且處理起來效率也比較好。如果系統配置上有需求，還可以添加專責的 ingest node 來處理。
以上就是本次的介紹。