我今天來說明自身對於 SIEM 的經驗，

比起建置，會有一個在前面要更先準備的，

那就是 "調查客戶的環境"

雖然進去的系統都是一樣的，但是會因為一些不同的因素而有不同的架構。

例如：

• 客戶預算有限
• 客戶 POC　環境不大
• 客戶有很多外點
• 客戶的 Log 量或 Network Traffic 過大，超過一台普通規格的負擔的範圍
  之類的原因都有可能導致每次的架構會不同，會需要考慮實際的情況。

那麼具體 SIEM 要開多大的規格呢?

最開始在規劃 SIEM 規格的時候，我碰到的一個名詞就是 EPS（Events Per Second）。
簡單來說，就是平均每秒會進來多少筆 Event。

不過我碰到產品是用針對所解析的流量去計費的，無法作為參考
所以等等會給一個參考公式可以去換算大概的每日流量。
但是知道 EPS，就代表我知道一天會有多少資料嗎？
其實沒那麼直接就能知道

有時問題不是客戶的 EPS 多少，而是他們不知道自己家裡面的 EPS 是多少，
沒有一個固定的算法，但是我之前是用一台一般電腦每日約 500 MB 。
因為還有每筆 event 平均大小不同的差異，所以不是那麼好估算，能知道的話當然是好。

大概的參考公式:

(每日資料量 = EPS times 平均Event大小 times 86,400)

假設今天客戶的環境大約是 1,000 EPS，看起來好像沒有很多，但如果換算成一天：
1,000 × 60 × 60 × 24 = 86,400,000

公式其實不難，真正比較麻煩的反而是另外一件事情：
客戶不知道自己的 EPS 是多少。
如果客戶原本就有 SIEM 或其他 Log 管理平台，可能還有既有數據可以參考；但如果今天是第一次導入 SIEM，就不一定有現成的 EPS 可以直接告訴我們。
那這時候怎麼辦？

我們只能先從客戶目前的設備與環境去做初步推估。

• 使用者電腦有多少台？
• Server 有多少台？
• Firewall 有幾台？
• Domain Controller 有幾台？
• EDR 有多少 Endpoint？
• 還有哪些設備預計送 Log？

以前我在做 Stellar Cyber Sizing 時，原廠曾提供一個估算方式，會先以一台一般 Endpoint 每天約 500 MB 的資料量作為初步估算值。
所以假設今天客戶有 1,000 台 Endpoint：
500 MB × 1,000 = 500,000 MB/day
粗略來看就是 500 GB/day。
不過要特別說明，這是我當時做 Stellar Cyber 專案時使用過的原廠估算參考值，並不是說所有 Endpoint 每天都一定會產生 500 MB 的 Log。
實際資料量還是會受到 Log Source、Audit Policy、收集項目與使用行為等因素影響。

那為什麼我們要花這麼多時間估算每天到底會進來多少資料？

因為這個數字最後會直接影響 SIEM 後端到底需要多大的規格，當資料量繼續增加時，甚至不是把 CPU、RAM、Disk 加大就能解決，而是可能需要開始考慮 Cluster 的架構。
例如：
每日資料量 -> 需要處理多少資料 -> 需要多少 CPU / RAM -> 資料要保存多久
-> 需要多少 Storage

假設今天每天大約會進來 500 GB 的資料，而且客戶希望保存 30 天。
先不考慮產品本身的資料處理、壓縮、Index、Replication 等機制，只用最簡單的方式來看：
500 GB × 30 Days = 15 TB

光是這樣就已經有大約 15 TB 的資料。
所以 Retention 要留多久，也會直接影響我們最後需要準備多少 Storage。
當然，實際需要的空間不能單純只用這個公式決定，因為不同產品怎麼處理與保存資料都不一樣。
但至少在前期規劃的時候，我們可以先知道客戶的資料規模大概落在哪裡。

前面一直在講規格，但是到底是甚麼東西需要這些規格？
這邊我還是用自己最熟悉的 Stellar Cyber 當作例子。

SIEM 大致上有哪些功能部件？

不同 SIEM 的產品架構、名稱與實作方式其實都不太一樣。
所以這邊我不打算說：
「所有 SIEM 都一定是這個架構。」

而是用我自己比較熟悉的 Stellar Cyber 當作例子，來說明一套 SIEM 大概會需要哪些功能。
以我過去接觸 Stellar Cyber 的經驗來看，我會先簡單把整個架構理解成：

其實可以先理解成兩個大方向：
靠近客戶環境的地方負責取得資料，後端則負責把這些資料處理、分析、保存，最後提供給 SOC 人員使用。

Sensor：部署在靠近資料來源的位置

我自己實際建置 Stellar Cyber 時，最常接觸到的其中一個 Component 就是 Sensor。
Sensor 通常會部署在客戶端，或是靠近資料來源的位置。
例如 Firewall、Server 或其他設備，可以把 Syslog 送到 Sensor。
但 Stellar Cyber 又有一個比較特別的地方。
它除了處理 Log 之外，本身也有 NDR（Network Detection and Response） 的能力。
所以 Sensor 除了接收 Syslog 之外，也可能需要接收從 Switch Mirror / SPAN 過來的 Network Traffic。

這時候 Sensor 放在哪裡就很重要了。
因為 Syslog 只要網路可以正常把資料送到 Sensor，通常就有辦法處理。
但 Network Traffic 不太一樣。
如果今天希望看到某一段 Network Traffic，就需要知道：

• Switch 在哪裡？
• Mirror / SPAN 要設定在哪個 Port？
• Sensor 要接在哪個 Network Segment？
• 要監控的是 North-South Traffic 還是 East-West Traffic？
• Sensor 可以處理多少 Network Throughput？

所以 Sensor 並不是找一台 VM 裝起來就結束了。
我自己也曾經碰過 Switch Mirror 明明設定正常，但是到了虛擬化環境之後，Sensor 就是收不到 Network Traffic。
最後一路去檢查 Virtual Switch、Promiscuous Mode、VLAN 等設定，才找到真正的問題。
架構圖上可能只是一條：
Switch → Sensor
但實際建置的時候，中間可能有很多東西需要確認。

Center：SIEM 的後端核心

Sensor 收到前端資料之後，最後還是需要把資料送到後端。
這邊我先用 Center 來稱呼 Stellar Cyber 後端這一塊。
Center 不一定非得放在跟 Sensor 相同的位置。
依照客戶環境與部署方式，可以放在客戶端，也可能部署在其他 Data Center 等環境。
Center 裡面又包含不同功能。

Analyzer：負責後端的分析

Analyzer 這部分，可以先把它理解成後端負責資料分析的一個重要角色。
前幾天一直在提一件事情：
Firewall 看到的是 Firewall 的資訊。
EDR 看到的是 Endpoint。
Network Traffic 又是另外一個角度。
如果所有資料進到 SIEM 之後還是各看各的，那其實就只是把很多 Log 集中放在同一個地方。
SIEM 後面真正重要的事情之一，是怎麼把這些資料拿來做分析、偵測以及關聯。
也就是把原本分散在不同 Data Source 的資訊，慢慢拼成一個比較完整的事件。
至於 Rule 怎麼判斷、Event 怎麼分類、Correlation 怎麼做，這部分我會留到後面的文章再說。

Database：資料總要有地方放

Database / Storage 相對就比較容易理解。
SIEM 每天收進來這麼大量的資料，不可能分析完之後就直接丟掉。
因為 SOC 在調查事件的時候，很常需要回頭查歷史資料。

例如：

• 這個 IP 上星期有沒有出現過？
• 這台 Host 前幾天有沒有發生類似的 Event？
• 這個帳號在事件發生以前做過甚麼？

這也是為甚麼前面提到的 Retention 很重要。
今天資料留 7 天、30 天、90 天甚至更久，Storage 的需求一定不同。
所以前面算的：
每天會進來多少 GB？

到了這裡就真正開始影響架構。

Dashboard：SOC 人員實際操作的地方

Dashboard 就比較好理解了。
它就是 SOC Analyst 或管理人員平常登入 SIEM 後會看到的操作介面。
例如：

• 查看 Alert
• Search Log
• 調查 Event
• 查看 Dashboard
• 查詢不同 Host / User / IP
• 產生 Report
• 進行其他 SIEM 操作
  使用者平常可能只看到一個 Web UI。
  但是 Dashboard 顯示出來的資料，其實是前面 Sensor、Analyzer、Database 等不同功能共同處理之後的結果。

Collector：在 Center 裡主動去其他產品拿資料

另外一個比較容易因為名字而誤會的就是 Collector。
第一次看到 Collector 這個名字，可能很直覺會認為：
「它是不是另外一台放在客戶端收 Log 的設備？」

但以我當時接觸的 Stellar Cyber 架構來說，Collector 是在 Center 裡面的功能。
它跟 Sensor 收資料的方式也不太一樣。
有些資安產品本身會提供 API，Stellar Cyber 已經針對部分產品做好對應的 Connector。
這時候 Collector 就可以透過這些 Connector，主動去呼叫其他產品的 API，把需要的資料取回來。

所以 Sensor 跟 Collector 可以用一個很簡單的方式理解。
Sensor 比較像：

Firewall -> Syslog -> Sensor
Switch -> Mirror -> Sensor

也就是：
資料送到 Sensor。

Collector 則比較像：

Collector -> API Request -> 其他產品
Collector <- Data <- 其他產品

也就是：
Collector 主動去其他產品取得資料。

這也是為甚麼在前期調查客戶環境的時候，我們不只是確認：
「設備能不能送 Syslog？」

有時候還會需要知道：
「這個產品有沒有 API？」
因為有些產品有針對 API 提供的資訊做優化，會比單純的 log 更好讓人抓到重點

「Stellar Cyber 有沒有對應的 Connector？」
因為如果沒有的話通常還需要跟原廠填寫表單來申請製作 Parser 才能進行解析

「API 可以取得哪些資料？」
這部分會需要看產品所開放的規格書中，每段不同的定義，有製作好 Parser 的話基本上原廠資料會寫

「需要甚麼帳號或 API 權限？」
有些產品會需要特定的權限才可以，防火牆為例子的話，會需要使用的帳號可以支援寫入的功能

這些都會影響最後資料怎麼進 SIEM。

Windows / Linux 還有 Agent 可以使用

除了 Sensor 與 API 之外，SIEM 本身通常也會有一些方式可以直接從 Endpoint 或 Server 取得 Event。
例如安裝 Agent 在 Windows / Linux 上，將需要的 Event 或 Log 送回 SIEM。
概念上：
Windows / Linux -> SIEM Agent -> SIEM

這時候客戶很容易碰到另外一個問題：
「那我已經有 EDR 了，還需要 SIEM Agent 嗎？」

我自己的理解是，兩個東西看的面向不一定完全重疊。
SIEM Agent 主要還是為了取得 SIEM 所需要的 Event、Log 或其他 Telemetry。
EDR 則比較著重在 Endpoint 上面的 Detection and Response。
例如 EDR 可能可以看到：
Process -> Parent / Child Process -> Command Line -> File / Registry -> Network Connection

以及後續的：
Host Isolation
Kill Process
Quarantine
Threat Hunting
...

實際功能當然還是依照不同產品而定。
所以不能直接說：
有 EDR 就完全不需要 SIEM Agent。

也不能反過來說：
有 SIEM Agent 就可以取代 EDR。

真正需要確認的還是：
今天想取得的是甚麼資料？
如果兩邊收集的資訊並不完全重疊，那同時使用並沒有甚麼問題。

講到這裡，就可以回到最前面講的 Sizing。

如果今天是一個 POC：
客戶環境不大 -> 資料來源少 -> EPS 不高 -> Network Traffic 不大 ->可能使用比較小的架構

但是換成另外一個客戶：
多個 Site + 大量 Endpoint + 大量 Firewall / Server Log + 大量 Network Traffic

架構就可能完全不同。
例如：

所以 Sensor 要幾台，不是單純看：
「這個產品正常要裝幾台？」

而是要看：
客戶的資料到底在哪裡。

如果客戶有很多不同 Site，而且每個 Site 都有需要分析的 Network Traffic，就可能需要分散部署 Sensor。
同樣的道理，Center 後端需要多大的 CPU、RAM、Storage，也會受到每天實際進來的資料量影響。
當一台不夠的時候，就開始碰到 Cluster
當客戶規模越來越大之後，就可能出現一個問題：
單台設備已經沒有辦法負擔。
以前我剛接觸 Server 的時候，會比較容易把規格問題想成：
CPU 不夠 → 加 CPU

RAM 不夠 → 加 RAM

Disk 不夠 → 加 Disk
這種做法其實就是一直把單台設備往上擴。
但是設備還是有它的上限。
而且 SIEM 不只是 Storage，還需要持續接收、處理、搜尋以及分析大量資料。
當資料量到了一定程度之後，就可能需要使用 Cluster 的架構。
概念上：

透過多個 Node 一起處理資料，而不是把所有工作都壓在同一台設備上。
至於不同 Node 到底負責甚麼、資料怎麼分配、怎麼擴充，就會依不同 SIEM 的架構而有所不同。
這裡我比較想講的不是Stellar Cyber Cluster 要怎麼安裝。

而是：
為甚麼我們在前面要先把客戶的資料量估出來。

因為如果一開始連客戶每天會產生多少資料都不知道，後面自然很難知道到底要準備一台 Server，還是需要多個 Node。
Cluster 之外，還有 HA
最後還有另外一種需求，也會直接影響架構：
客戶不能接受系統中斷。

SIEM 本身就是拿來監控企業資安事件。
如果剛好 SIEM 發生問題的這段期間，又碰上真正的資安事件，就可能造成監控上的空窗。
所以某些比較重視 Availability 的環境，還會需要考慮 HA（High Availability）。
最簡單的概念就是：

當其中一個 Component 或 Node 發生問題的時候，希望還有另外一個可以接手，降低 Single Point of Failure 帶來的影響。
但這邊有一件事情要注意：
Cluster 跟 HA 並不是完全相同的概念。
Cluster 有時候是為了增加處理能力：

實際上兩者有可能會結合，而且不同產品可能有 Active / Standby、Active / Active，或 Cluster 本身就具備一定程度的容錯能力。
所以真正建置的時候，還是要回到各產品自己的架構。

回到客戶環境

講到最後，其實又回到今天一開始提到的事情：
「調查客戶的環境。」
如果今天只是 POC，資料量不大，架構可能相對單純。
如果客戶有很多不同的 Site，就可能需要考慮 Sensor 要怎麼分散部署。
如果每天的 Log 量非常大，Center 後端就要考慮更大的 CPU、RAM、Storage，甚至 Cluster。
如果 Network Traffic 很大，Sensor 的 Throughput 又會變成另外一個問題。
如果客戶要求系統不能中斷，那 HA、Redundancy 又會進到架構裡面。
最後當然還有一個很現實的問題：
預算。
所以同樣都是 SIEM，同樣都是 Stellar Cyber，最後在不同客戶環境裡面，架構不一定會長得一樣。
我以前可能會覺得 SIEM 建置就是把 Server 建起來、把 Log 收進來，然後看到 Alert 就差不多了。
但實際做過不同環境之後，才發現真正開始建置以前，要先確認的事情其實很多：

• 客戶有甚麼設備？
• 要收甚麼 Log？
• EPS / 每日網路流量大概多少？
• 每天會進來多少資料？
• 有多少個 Site？
• 資料要保存多久？
• 系統能不能停？
  這些東西慢慢確認完之後，
  SIEM 的架構才真的開始成形。
  但是架構建好了、Log 也都收進來之後，下一個問題才真正開始：
  這些收到的 Event 跟 Alert，到底有沒有用？

今天先到這邊，感謝有看到的人