日誌的儲存與授權

在前面兩天，我們分別就日誌蒐集的流程與作法做了介紹，
也分享 Splunk 與 IBM Qradar SIEM 在不同系統上如何做日誌蒐集。
我們知道了日誌收容的關鍵其實在正規化與剖析技術，
但其實還有一個更重要的議題通常也會在日誌收集時討論。

今天是日誌收容技術的第三篇、也是區段章節的最後一篇，
主要想跟邦友聊聊關於 SIEM 日誌的儲存跟授權的區塊，
也就是關於【日誌的儲存與授權】我們應該知道哪些事？

日誌計價模型

談到日誌儲存，無可避免的就是會談到各家的計價模式，
因為現在商用的 SIEM 都不在關聯分析收費、也不在告警機制收費，
而通通都是集合在「日誌儲存量」或「每秒事件數量」來進行計價。

日誌儲存量 GB/Day vs 每秒事件數量 EPS

日誌儲存量 GB/Day 顧名思義就是每天 24 小時，
當 SIEM 做完正規化後所儲存的「日誌儲存量」 (Gigabyte per day)，
它不管後續的關聯分析階段會用到多少事件量，
它只會在第一時間日誌收容的期間進行授權量的消耗，
通常在超過日誌授權的限制時，就會停止收集日誌，
或是停用 SIEM 相關的使用功能，讓使用者必須增購授權。

而 每秒事件數量 Event Per Second (EPS)，
它關注的是當日誌進入到 SIEM 進行正規化時，
會消耗多少**「每秒鐘的事件數量」**。

意即 EPS 並沒有考慮事件封包長短的顆粒度 (bytes)，
因為每個資訊系統的事件長度都會不一樣，
這時候到底 by amount 或是 by number，
就會在兩者計價模型的換算，會有相關的細節需要納入考慮。

5000 EPS 範例換算

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

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

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

3. 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

相反的話，大概 300 GB 約略等於 5326 EPS，
大家可以自己玩看看 100 GB 大概會是多少 EPS 呢？
（答案放在文章底部）

Arcsight SIEM

以我們在 Day 2: 寫在之前 - SIEM 的起源 分享到的，
其實最早在臺灣市場登陸、
知名度與市占率都很高的 Micro Focus Arcsight，
便是典型按照 SIM 與 SEM 精神所研製的的解決方案，
至今仍是業界相當經典的 SIEM 解決方案鼻祖。

因此以 Arcsight 來說，
它分別座落的日誌儲存模組 (ADP) 以及關聯分析模組 (ESM)，
就會產生兩種日誌計價單位，
也就是 ADP 會以 GB/Day 計價；ESM 則以 EPS 計價。

這是最典型 SIEM 的計價方式，用哪一塊就算哪一塊的授權。

Splunk SIEM

在 Splunk 這邊，它的計價模式開始變得相對單純些，
只採用 GB/Day 來進行計價，
意即它無論使用什麼基本 SIEM 功能，
它只看整體收集了多少日誌量。

這解決了客戶可以不用同時考量兩個以上的計價授權模式，
只需要單純考慮現有以及未來系統的日誌增長量的規劃即可，
當使用超過或授權不足時，
只需單純的挪移系統日誌量是否進入 SIEM 來均勻調配即可。

相較 Arcsight 對客戶角度而言，
這樣的計算用量的機制變得非常單純，也很好維護未來的授權增長。

IBM QRadar SIEM

第三個在 QRadar SIEM 這邊，
計價模式仿照 Arcsight 與 Splunk 的授權方式，
但是是採用「日誌量一次性授權」跟「按事件數量增長授權」機制。

意即，考量日誌收集本身，通常用戶都會希望更多的收集日誌，
不希望在第一時間會有日誌沒有收進來 SIEM 的情況，
希望能夠先全部收集後，再視情況進行威脅關聯分析，

這時候用戶一樣只需要關注事件數量的增長授權 (EPS)，
但同時也可以先蒐集資訊環境內的所有日誌 (一次性授權)，
達到既能日誌收集符規，又能不用一次買足高額EPS 授權量，
可以日後在逐年增購因應可能的事件數量增長量。

這樣的計價模式，有效的解決有些客戶想做日誌保存的需求，
不用擔心只收、不做關聯分析的日誌白白消耗掉珍貴的授權數量。

日誌篇小結論

其實不管是目前哪一套主流 SIEM 的計價模式，
都無可避免的還是讓客戶感到頭疼，
還是不好抓 3-5 年應該預估多少的授權量。

所以現在無論是 Splunk 或 QRadar SIEM，
都有推出所謂的「吃到飽」方案，
依據資訊基礎設施環境的數量，給予一定範圍的吃到飽方案，
而不是看個別系統丟多少事件出來到 SIEM，

或是有技術能量的，
就會開始考慮採用開源的解決方案，
來因應日誌量的授權計價問題。

但無論是商售或開源，都有其個別利弊，
還是得看企業客戶屬性，來決定哪一種方案是最適恰的。

明日預告

日誌篇我們就以簡單的三天的篇幅先談到這，
希望能夠讓你/妳 SIEM 對第一個重要日誌功能模塊，
有很清楚跟全面的認識與了解。

明天開始就要進入我們 SIEM 的重頭戲：
也是我們 SIEM 的第二塊重要功能模組，
同時也是 SIEM 最 Powerful 的 關聯分析引擎。

期待明天繼續與大家「空中相會～！」

-> 100 GB 大概等於 1775 EPS (700 bytes avg. Event length)

參考來源

1. Arcsight https://community.microfocus.com/cyberres/arcsight/f/arcsight-discussions/289988/arcsight-license-and-enforcement-information
2. Splunk https://www.splunk.com/en_us/products/pricing/enterprise-platform.html
3. IBM QRadar SIEM https://www.ibm.com/docs/en/qsip/7.5?topic=management-event-flow-processing-capacity