寫在開頭

昨日我們就基本面的 SIEM 做梳理介紹，
今天來到第 27 天 SIEM 核心功能篇，
也要來精華提取我們在「寫在啟程」九篇關於
SIEM 的精華功能：日誌蒐集、關聯分析與事件回應。

日誌蒐集與存管

鐵人賽開宗明義我們即強調 SIEM 最大的價值，
在於企業組織一個完整的威脅可視性，
以及針對企業資安威脅生命週期的管理。
而第一步就是日誌的蒐集與存管的議題。

資料管道 (Pipeline)

當日誌來到 SIEM 工具時，
就像菜餚要來排排坐、開始清洗的過程，
像個管線 (Pipeline) 要依序來處理原始資料。
而整個過程即是最重要的「正規化」的過程，
來將原始事件的資訊、切成合適的欄位進到儲存位置，
方面後續索引 (Index)、搜尋 (Search) 或是關聯 (Correlate)。

資料傳輸機制 (Protocal)

各個資訊系統或多或少都有支援不同的傳輸機制，
像是 Syslog 與 SNMP 屬於被動型 (Inbound) 蒐集機制，
而 JDBC、Log file 或 SMB 則屬主動型 (Outbound) 機制。

而在核心的資訊系統，例如 Windows 系列，
也會支援以 Agent 代理程式的的方式，
來針對 Windows Event 等，進行更深度的支援。
或是 Linux 系統透過 Syslog 機制，
將系統日誌或特定行為傳輸至 SIEM 平台進行監控。

日誌授權與計價模型

幾乎各主流 SIEM 的解決方案的授權，
都是圍繞在日誌收集時或是關聯分析的用量來計價。
而在日誌攝取量 (GB/Day) 或是事件數 (Event per second)，
之間具有一定的換算公式與比例，
關鍵則會是在「封包長度」拿多少當作基準：

換算公式：? GB = ? EPS * bytes avg. size * 3600 seconds * 24 hours / 1073741824 bytes

封包長度

因為 EPS 沒有考慮到事件封包長度，
因此「事件長度」拿多少來帶入，都會直接影響算出來的 GB。
以常見取平均封包長度來看，通常會是 500~700 bytes，
但還是會依照不同的資訊系統有不同的長度需要考慮。

秒 -> 天

因為 EPS 是 每秒計算，
故要換成 per Day，就需要乘上 86400 秒、變成 24 小時的基準。

Bytes -> GB

最後就是 bytes -> GB 之間的換算，
1GB = 1,024 MB = 1,048,576 KB = 1,073,741,824 bytes

因此 5000 EPS 約莫等於：

281.6 GB = 5000 events/s * 700 bytes avg. event size * 3600 seconds/hour * 24 hours/day / 1073741824 bytes

延伸閱讀：

1. Day 5: 寫在啟程 - SIEM 日誌收容 (基本篇)
2. Day 6: 寫在啟程 - SIEM 日誌收容 (應用篇)
3. Day 7: 寫在啟程 - SIEM 日誌收容 (授權篇)

威脅偵測與關聯

當我們擁有充足、來自各方的日誌之後，
接著便是在平台上使用「關聯分析」機制，
而關聯分析其實就是 Rule-Based 的本質，
透過一條條靜態、層級由大而下規則的撰寫，
來達到異常條件的撰寫。

關聯規則細節

典型的關聯規則長相，大概會是：

• 規則名稱：Excessive Firewall Denies from Single Source
• 偵測範圍：Local
• 例外排除：NOT...BB:HostDefinition Servers
• 關聯規則：當任一 Firewall or ACL 防護設備，偵測相同來源 IP 在過去 5 分鐘，對對一個目的 IP 存取被拒超過 400 次

關聯規則應用

當關聯規則觸發的各式告警時，
各式的解決方案都應用不同核心技術，
將偵測的告警依據一定基準來排序，
來讓資安維運中心可以有優先順序的方式來處理威脅。

可能依據的指標，像是相關性、可信度或嚴重程度等等，
待計算出不同的威脅優先值後，
讓資安分析師可以就高風險的優先進行關注與處置。

威脅情資關聯

當 SIEM 工具有整合相關外部威脅情資匯入時，
亦可在關聯分析時，比對相關 IP/URL/C2 資訊，
意即將威脅情資的 IoCs 指標，
作為比對的一個靜態條件欄位來查找，
持續比對與查找有無出現在組織環境內部。

動態威脅 (Risk Score)

當內、外部既有威脅型態透過規則撰寫後，
關於身份、人員的活動，我們會導入機器學習的模型，
針對人員活動依據個人(Person)、部門(Peer)來建模，
建立相關活動基準值之後，來進行行為異常判定。

常見的用戶行為分析，像是有：

• 存取活動的頻率異常
• 資料量的下載量異常
• 長期未使用帳戶有活動
• 重要資產的訪問活動過高

案例庫與攻擊矩陣

透過一個個累積的實務關聯機制，
可以透過完整的案例庫 (Use Cases)，
檢視目前 SIEM 平台的偵測機制有無妥善規劃，
同時也可以自動將 MITRE ATT@CK 的攻擊矩陣，
配對在威脅偵測機制與事件調查當中，
透過標準的網路攻擊鍊與攻擊矩陣，
可以讓組織執行資訊安全防護時，有所基準依循。

延伸閱讀：

1. Day 8: 寫在啟程 - SIEM 關聯分析 (基本篇)
2. Day 9: 寫在啟程 - SIEM 關聯分析 (進階篇)
3. Day 10: 寫在啟程 - SIEM 關聯分析 (應用篇)

威脅回應與處置

在威脅(事件)回應的章節，
我們談了關於 SIEM 偵測相關事件後，
該如何針對相關告警與事件進行查處，
以及如何有效利用相關自動化工具 (例如SOAR)，
來協助組織將日常維運半自動或自動化處理。

另外各式商售解決方案，透過豐富生態系支援，
一方面透過擴充 app 方式加深與各個解決方案的整合使用，
另一方面也讓各種事件調查後的回應得以更多些原生整合與自動化，
有效強化基於 SIEM 平台為資安核心大腦的角色與位置。

而另一塊我們談到的 SIEM 的偵測與回應的挑戰，
如何透過補強 EDR 端點解決方案來達成現在流行的 XDR 策略，
來將相關威脅偵測機制能推展到 APT 攻擊最長肇生的第一線戰場。

以上均是從各個面向，
希望能有效強化與提升整體威脅回應效率。

延伸閱讀：

1. Day 11: 寫在啟程 - SIEM 事件回應 (基本篇)
2. Day 12: 寫在啟程 - SIEM 事件回應 (趨勢篇)
3. Day 13: 寫在啟程 - SIEM 事件回應 (應用篇)

明日預告

今天我們把 SIEM 核心功能進行回顧，
把威脅偵測與回應的範疇都很快的整理一遍，
希望能讓各位邦友有所收穫。

明天我們繼續進入到 SIEM 整合應用精華回顧，
透過瞭解 SIEM 與周邊關聯的整合與應用，
更加瞭解其扮演的角色與功用效益為何。

我們明天繼續空中相會。