前面幾天談了很多內容，
但如果今天真的要把一套資安產品導入企業環境，在正式採用以前，通常還會經過一個很重要的階段：

POC（Proof of Concept，概念驗證）。

以前我可能會把 POC 想得比較單純：

把產品建置起來，確認功能能不能正常運作。

但經過幾次實際參與 POC 後，我慢慢發現，POC 並不只是「產品能不能裝起來」。

它還需要確認：

客戶真正想解決什麼問題？

這套產品到底能不能解決？

哪些功能是產品原本就應該具備的？

哪些需求已經超出產品原本的能力範圍？

我現在會把 POC 看成：

在有限的環境、時間與驗證範圍內，實際確認產品能力是否符合需求，同時了解產品能力邊界的一個過程。

POC 開始以前，就應該先有 Baseline

我認為一套產品在還沒有遇到特定客戶以前，就應該先定義自己的 POC Baseline。

也就是：

如果今天要驗證這套產品，最基本應該確認哪些項目？

而不是每遇到一個客戶，就重新思考一次 POC 要測什麼。

以 SIEM 為例，我會希望基本的驗證模板至少包含幾個方向。

Data Collection

首先是資料到底有沒有正常收集。

例如：

• Firewall
• Windows Event
• Linux Syslog
• EDR
• Network Device
• 其他原廠支援的 Security Product

如果某些產品本來就在原廠的 Support List 裡面，而且也被列入這次 POC 的收集範圍，那原則上就應該在 POC 期間完成相關設定與資料收集。

Parser / Field

但 Log 有進來，還不能直接代表資料收集成功。

還需要確認重要欄位是否正常解析，例如：

Source IP
Destination IP
Source Port
Destination Port
Username
Hostname
Action
Event Type

如果資料全部都只有 Raw Log，沒有辦法正確解析成 SIEM 可以使用的欄位，後續 Search、Rule、Correlation 都可能受到影響。

所以我認為：

「收得到 Log」跟「這筆 Log 可以被 SIEM 使用」是兩件不同的事情。

Detection / Alert

接下來則要確認：

資料收進來之後，系統有沒有辦法正常產生 Alert？

因為 SIEM 不是單純把 Log 集中保存。

如果今天設計了一個測試情境，就應該確認相關 Rule 或 Detection 能不能正常觸發。

這也是驗證產品偵測能力的一部分。

Presentation

最後還要確認實際呈現的結果是不是符合預期。

例如：

• Dashboard
• Alert
• Event Detail
• 欄位內容
• 統計資訊
• Correlation 後的資訊

對使用者來說，資料有進 Backend 是一件事。

最後能不能透過平台清楚看到自己需要的資訊，又是另外一件事。

所以如果要把 SIEM 的基本 POC Baseline 簡化，我會整理成：

收得到 → 解析正確 → 偵測得到 → 呈現正確

至於 Automation、SOAR、Webhook、自動封鎖等功能，我會先把它們視為額外的驗證項目，而不是每一場 POC 都一定要完成的基本條件。

Baseline 不等於客戶最後的 POC 計畫

不過 Baseline 只是一套產品的基本驗證模板。

它還不能直接拿來代表某一間客戶最後真正要做的 POC。

因為這時候我們可能還不知道：

客戶的環境是什麼？

有哪些資安設備？

想收集哪些資料？

真正遇到的問題是什麼？

網路架構能不能配合？

所以有了 Baseline 之後，接下來很重要的一個階段就是：

POC 會前會議。

POC 會前會是一個雙向了解的過程

我認為 POC 會前會並不是單純問客戶：

「你有哪些設備？」

而是雙方都需要了解對方。

一方面，我們要先讓客戶知道：

這套產品基本上可以做什麼？

另一方面，我們也要知道：

客戶到底想解決什麼問題？

因為有時候客戶知道自己遇到問題，但不一定知道這個問題應該由哪一類資安產品處理。

客戶不一定知道每一種產品能做什麼

例如客戶可能會問：

「SIEM 也有 Agent，那是不是可以做到跟 EDR 一樣的事情？」

這時候就需要先釐清產品定位。

SIEM Agent 的主要目的通常是協助收集 Log、系統事件、FIM 等資訊，將資料提供給 SIEM 進一步分析。

EDR 則更著重在 Endpoint Detection & Response，
除了端點行為偵測與調查之外，部分產品還可以進行 Host Isolation / Network Containment。

所以假設客戶真正的需求是：

「如果這台電腦發生異常，我希望可以直接把它隔離。」

那我就不能因為 SIEM 有 Agent，就直接告訴客戶：

「SIEM 可以取代 EDR。」

這時候反而要先確認：

客戶真正需要的是什麼能力？

可能是：

Collection
Detection
Correlation
Investigation
Isolation
Automation

如果核心需求是 Endpoint Isolation，那可能需要 EDR。

如果希望不同產品的事件可以集中並找出關聯，那 SIEM 就比較符合。

如果希望 SIEM 發現事件後，自動通知其他產品執行封鎖或隔離，那又可能進一步涉及 SOAR、API 或其他自動化整合。

這其實就是 Capability Mapping（能力對應）。

需求訪談不是為了硬把產品套進去

我自己比較常遇到的一種客戶痛點是：

已經有很多資安產品，但是資訊彼此分散。

例如：

Firewall 有自己的事件。

EDR 有自己的 Alert。

其他產品也有自己的 Console。

真的發生事情時，可能需要到很多不同的平台分別調查。

如果客戶真正的問題是：

「我已經有很多資安設備，但缺少一個地方統整資料，也很難找出事件之間的關聯。」

那 SIEM 的 Collection、Correlation、Alert 與 Investigation 能力，就比較可能符合這個需求。

但也不是所有問題最後都一定要導向 SIEM。

需求訪談後，也可能發現問題其實來自：

網路架構、設備設定、權限、既有產品沒有正確使用，甚至是其他流程問題。

如果是這種情況，我認為就應該針對客戶真正的環境提出其他建議，而不是硬把 SIEM 當成所有問題的答案。

所以 POC 前其實還有一個很重要的判斷：

Solution Fit：這套產品到底適不適合解決客戶現在的問題？

會前會也要討論實際環境

確認產品能力與客戶需求之後，接下來才會慢慢進入比較實際的技術內容。

我通常會透過架構圖讓客戶了解：

這套產品如果放進現有環境，大概會怎麼運作。

例如：

如果還包含 Mirror Traffic、NDR 或其他元件，也會一起放進架構裡。

同時還要準備相關的 Port 表單。

因為架構圖上面的一條線，在實際環境裡可能代表很多事情：

• Firewall Policy 要不要調整？
• 哪些 Port 要開？
• Syslog 要送到哪個 IP？
• 哪些設備需要互相連線？
• Windows 要怎麼設定？
• EDR 怎麼整合？
• 是否需要帳號與特定權限？
• Sensor / Collector 要放在哪個網段？

如果客戶本身不熟悉某些設定方式，我們這邊也可以協助。

這個過程除了讓我們了解客戶環境，也是讓客戶先對整個 POC 架構有基本認知。

如果原本規劃的架構不適合客戶環境，也可以在這個階段先討論與調整。

POC 的時間也要先談清楚

除了產品、環境與驗證項目之外，另外一個很重要的事情就是：

Schedule。

因為 POC 不可能無限期進行。

所以會前會也需要確認大致的時間安排，例如：

這樣客戶知道什麼時間需要完成環境準備，我們也知道每個階段預計要做到什麼程度。

如果時程、設備或權限都沒有先確認，真正開始 POC 之後才發現環境根本還沒有準備好，就很容易影響後面的驗證。

會前會之後，Baseline 才會變成客戶的 POC 計畫

原本我們手上已經有一套：

Product POC Baseline

經過會前會之後，我們才會知道：

這時候再去調整原本的架構圖、Port 表、驗證項目與相關文件。

最後產生的版本，才是真正符合這個客戶環境的 POC 計畫。

所以我的理解並不是：

每個客戶的 POC 都完全客製化。

而是：

先有一套可以重複使用的 Baseline，再根據客戶環境進行調整。

Baseline + Additional Item

假設今天客戶有多套資安產品。

我們會先盤點：

這次預計收集哪些產品？

如果這些產品原本就在原廠支援範圍，而且已經列入這次 POC，那在 POC 期間就應該完成相關的收集與基本驗證。

例如：

Baseline

□ 預計整合的產品盤點
□ 原廠支援 Log Source
□ 原廠建議的基本收集項目
□ Data Collection
□ Parser / Field
□ Detection / Alert
□ Dashboard / Presentation

但如果 POC 進行之後，客戶又提出：

「這台設備也可以幫我接嗎？」

或者：

「可以幫我做到自動封鎖嗎？」

這些原本沒有包含在主要驗證範圍內的需求，就可以另外列成 Additional Item。

例如：

□ 額外 Log Source
□ 原廠未支援的產品
□ Custom Parser
□ 特殊 Use Case
□ 額外 Dashboard
□ Automation
□ SOAR / Webhook

只要時間與環境允許，當然可以協助驗證。

但是我認為應該把它跟原本的 Baseline 分開。

POC 也讓我們知道產品的極限

經過幾次實際參與 POC 後，我慢慢感覺到：

POC 並不只是單純的產品測試，而是一個需要客戶、業務與技術人員共同討論、確認並完成的過程。

所以在 POC 開始以前，先把 Baseline、驗證項目、客戶需求、環境條件與時程 定義清楚，我覺得非常重要。

對技術人員來說，可以清楚知道：

這次要建置與驗證到什麼程度？

對客戶來說，可以知道：

產品能不能解決自己的問題？

對業務來說，也能比較明確地說明：

這次 POC 的範圍與目標是什麼？

而真正開始驗證之後，我們也會慢慢看見另一件很重要的事情：

產品能做到什麼，以及它的能力邊界在哪裡。

如果客戶後續提出原本 Baseline 之外的需求，只要時間與環境允許，當然還是可以協助測試。

但是我會把這些內容視為 Additional Item/額外的加分事項。

因為額外功能如果做得到，可以成為這次 POC 的加分項目；如果因為產品能力或其他限制做不到，也不應該因此影響原本主要驗證項目的目的。

POC 不只是證明產品「能不能動」，而是透過客戶、業務與技術人員共同驗證，確認產品能不能解決需求、基本能力是否符合預期，以及產品的能力邊界到底在哪裡。

而把這些事情先定義清楚，除了讓技術人員比較知道該怎麼執行，也讓客戶與業務對這次 POC 有共同的認知。