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