在做 SIEM 導入或 POC 時，我不會只確認「Log 有沒有進來」，還會看這些資料有沒有被正常解析。

因為一筆 Log 就算成功送進 SIEM，如果所有內容都只是整串放在 full_log 裡，對後續分析的幫助其實很有限。

我比較在意的是，原始 Log 裡面的資訊有沒有被拆到正確欄位，例如 Source IP、Destination IP、Port、User、Action、Device Type 等。

這些欄位如果沒有被正確解析，SIEM 很多功能就會受到影響，包含搜尋、規則比對、Dashboard 統計，甚至更重要的關聯分析。

從設備到 Dashboard，中間其實還有很多步驟

我自己會把整個流程理解成：

設備產生 Log → 傳送到 Sensor → Parser 解析與正規化 → 傳送到 SIEM Data Lake → SIEM 進行分析與關聯 → 顯示在 Dashboard、Alert 或 Case

資料來源可能是 Firewall、Server、EDR、Windows Event Log 或其他網路設備。

這些原始資料先送到 Sensor，Sensor 裡的 Parser 會負責解析不同格式的 Log，並把裡面的值拆到對應欄位。

例如原始 Log 裡面可能同時包含：

• Source IP
• Destination IP
• Source Port
• Destination Port
• User
• Action
• Device Type

Parser 的工作，就是告訴 SIEM：

「這一段資料到底代表什麼。」

解析完成後，資料會被正規化成平台可以理解的格式，再送進 SIEM Data Lake 儲存。

接下來 SIEM 才能從 Data Lake 裡做搜尋、規則比對與關聯分析，最後再把結果顯示到 Dashboard、Alert 或 Case。

所以 Parser 其實位在整個流程很前面的位置。

如果前面解析錯了，後面即使資料已經成功進入平台，SIEM 也很難正確使用。

Log 有進來，不代表真的能分析

這也是我在做 POC 時很常確認的一件事。

有時候平台看起來已經有收到資料，但如果所有內容都只存在 full_log，沒有被拆成可使用的欄位，那這些資料對 SIEM 來說就很難拿來做關聯。

例如 Firewall 裡面出現一個來源 IP，EDR 裡面也出現相同 IP。

如果兩邊的 IP 都被正確解析到相同類型的欄位，SIEM 才有機會把這些資料放在一起分析。

但如果其中一邊只是整串文字躺在 full_log，系統就很難知道那一段其實也是 IP。

所以對我來說：

資料有收到，只代表收集成功；欄位解析正確，才代表這筆資料真的開始能被 SIEM 使用。

為什麼 POC 前一定要先確認資料來源

這也是為什麼每次做 POC 前，我都會參與會前會，或由我負責技術面的確認。

我會先了解客戶環境裡有哪些設備、有哪些 Log 需要收，以及平台目前是否支援這些資料來源。

主流 Firewall、EDR 或系統通常比較容易有既有 Parser，但如果遇到國產設備或比較小眾的廠牌，就不一定已經有完整支援。

這時候就有可能出現：

Log 傳得進來，但平台不知道怎麼拆。

如果確認是 Parser 不支援或解析不完整，我就會請原廠協助撰寫或調整 Parser，把原始 Log 裡面的值轉換到正確欄位。

所以 POC 會前會對我來說不只是確認「有哪些設備要收」。

它其實也是在提早確認：

這些資料進來之後，到底能不能被平台正確理解。

收到資料只是第一步

以前如果只看「平台有沒有資料」，很容易覺得 Log 有進來就代表完成了。

但實際做 SIEM 之後，我會更在意後面的事情：

資料有沒有解析？

欄位有沒有對？

平台能不能拿來搜尋？

能不能做 Alert？

能不能跟其他資料做關聯？

最後能不能把有意義的結果呈現在 Dashboard 上？

所以我現在看 SIEM 的資料收集，不會只停在「有沒有收到」。

真正重要的是：

原始 Log 能不能經過 Parser 正確解析與正規化，最後變成 SIEM 可以分析的資料。

這也是為什麼在整個流程裡，Parser 看起來只是一個中間步驟，但其實它會直接影響後面所有分析結果。