我們會先確認客戶環境、需要收集的設備，以及這次 POC 預計驗證哪些項目。

但當產品真的建置完成之後，第一件事情一定還是要回到最基本的問題：

我要收的資料，到底有沒有正常進來？

這件事情看起來很基本，但其實非常重要。

因為今天 SIEM 裡面沒有看到資料，不代表一定是 SIEM 出問題。

有可能是來源設備沒有送、有可能是 Syslog 設定錯誤，也可能是中間的 Firewall、Port 或網路路徑有問題。

所以 POC 建置完成之後，我一定會先確認資料收集的狀況。

我會先從 SIEM 看有沒有資料

我的習慣不是一開始就跑去檢查來源設備，而是先從 SIEM 本身確認。

例如今天預計要收：

• Firewall Syslog
• Windows Event
• EDR Log

那我就會先確認這些預計收集的資料，有沒有出現在 SIEM 裡面。

如果有收到，就繼續往下確認內容。

如果沒有收到，或是收到的資料明顯不正常，才會開始往回找問題。

大概會變成：

這樣做的好處是，我可以先知道問題大概發生在哪一段，而不是 SIEM 沒看到資料，就直接認定是 SIEM 本身有問題。

Syslog 沒收到，我會怎麼確認？

如果今天收的是 Syslog，我自己比較常設定 TCP。

這時候除了從 SIEM 畫面確認之外，也可以利用 tcpdump 協助判斷資料到底有沒有到達收集端。

這個動作主要是在回答一個很單純的問題：

封包到底有沒有送到這台機器？

如果連封包都沒有看到，那就可以繼續往來源設備、網路或相關設定確認。

反過來，如果封包明明已經到了，但是 SIEM 裡面還是沒有看到預期的資料，那排查方向就會不一樣。

所以我認為 POC 過程中很重要的一件事情，就是先知道問題在哪一段，再去處理那一段的問題。

有收到 Log，不代表確認就結束了

看到資料進來之後，我還會再確認一次：

「這些資料有沒有被正確識別？」

但這裡就沒有辦法說所有 SIEM 都要看哪些固定欄位，因為不同產品、不同 Log Source，本來就會有不同的資料格式與支援方式。

如果是我使用的商用產品，而且原廠本身就有支援這個 Log Source，通常在原廠課程、文件或建置資料裡，就可以知道這個產品正常整合之後應該呈現哪些資訊。

實際 POC 時，我就會去查看解析後的 Log，包含 JSON 內容，確認需要的資訊是不是有進到預期的位置。

例如可能會看到：

Product / Device Type
Source IP
Destination IP
Source Port
Destination Port
Action
Username
Event Type
...

實際有哪些欄位，還是要以使用的產品與 Log Source 為準。

我真正要確認的不是「一定要有這些欄位」，而是：

原本應該被辨識出來的資訊，有沒有真的被放到正確的位置。

如果 Log 明明有收到，但是重要資訊沒有被正確解析，那後續不管是搜尋、關聯分析還是 Alert，都可能受到影響。

這張圖可以直接取代很多文字說明，讓讀者理解「收到 Log」與「正確解析 Log」其實是兩件事情。

如果原廠本來就不支援呢？

這又是另外一種情況。

假設客戶今天有一台設備，但是 SIEM 原廠目前沒有提供正式的 Parser 或 Integration，那 POC 階段我至少會先確認：

Raw Log 到底收不收得到？

至於後續要解析哪些內容、欄位要怎麼定義，就可能需要另外開發 Parser。

所以我不會把「原廠支援的設備」跟「需要自行開發的設備」放在完全相同的標準下判斷。

而如果今天使用的是比較自由的開源 SIEM，情況又會有所不同，因為很多解析方式與規則本來就可以由自己調整。

以 Wazuh 為例

Wazuh 就是一個很好理解的例子。

我自己在使用 Wazuh 時，一樣會去確認解析後的內容，有沒有出現在預期的欄位。

Wazuh 的 Decoder 主要負責從收到的事件中擷取資訊並拆成欄位；後續 Rule 再利用事件內容與解析結果判斷是否符合條件。Wazuh 也允許自己建立 Custom Decoder 與 Custom Rule，因此遇到原本沒有符合需求的 Log 格式時，可以依照實際情況進行調整。

概念可以簡化成：

這也是為什麼我在 Wazuh 裡不會只確認「Log 有沒有進來」。

我還會看解析後的結果，確認需要的資料是不是有出現在預期欄位。

Wazuh 本身也提供 wazuh-logtest，可以拿 Log Sample 測試 Decoder 是否 Match、解析出了哪些欄位，以及最後符合哪些 Rule，這在自己調整 Decoder 或 Rule 時非常方便。

例如今天自己新增了一種 Log Source，就可以用它確認：

這筆 Log -> 被哪個 Decoder 處理？ -> 解析出哪些欄位？ -> 符合哪一條 Rule？
-> 是否達到 Alert 條件？

最後才是確認 Alert

當資料收得到，而且需要的內容也有正常解析之後，我才會再確認 Alert。

這裡其實也不用想得太複雜。

我至少會挑產品本身應該可以產生 Alert 的事件來確認，看看符合條件之後，系統是不是真的有產生對應的 Alert。

因為並不是每一筆 Log 都一定要產生 Alert。

以 Wazuh 來說，Rule 會根據設定的條件判斷事件；當條件符合時，才會依照規則進一步產生對應的告警結果。

所以整個 POC 收集驗證，我反而會把它想得很簡單：

有沒有收到 → 解析對不對 → 該出現的 Alert 有沒有出現

只要先把這三件事情確認清楚，後面才有意義。

POC 收集正常，其實是後面所有事情的基礎

SIEM 可以做很多事情，Dashboard、Alert、Correlation，甚至後面還可以串 Automation。

但這些功能都有一個共同前提：

前面的資料要先收得正確。

所以 POC 系統建置完成後，我不會急著先展示很多漂亮的 Dashboard。

我會先回到最基本的地方，確認原本規劃要收集的資料有沒有進來、解析結果是不是符合預期，以及原本應該產生的 Alert 能不能正常看到。

因為資料如果從一開始就沒有收對，後面的分析做得再漂亮，也沒有太大的意義。

延伸閱讀：想自己玩 Wazuh Decoder / Rule

如果看到這裡，想進一步了解 Wazuh 怎麼處理 Log，我覺得可以從官方的 Decoder 與 Logtest 開始。

Wazuh 官方：Decoders 說明
可以先了解 Decoder 在 Wazuh 裡負責什麼，以及 Log 如何被拆成欄位。

Wazuh 官方：Testing decoders and rules
這篇很適合實作，可以看到怎麼用 wazuh-logtest 驗證 Decoder、Field 與 Rule。

Wazuh 官方：Custom Decoders
當現有 Decoder 無法處理自己的 Log 格式時，可以從這裡了解自訂方式。

Wazuh 官方：Custom Rules
解析完成後，如果想自己決定哪些事件要符合告警條件，可以接著看 Rule。

另外也可以參考社群實際整理的範例：

GitHub：Wazuh Custom Rules and Decoders 範例

這類社群專案比較適合拿來看「別人怎麼寫」，不建議直接把別人的 Decoder 或 Rule 當成自己環境的標準答案；Log 格式與需求不同，最後還是要自己驗證。