SIEM部署失敗的五大緣由

TT安全上的這篇文章談及了SIEM實施的負面問題，指出了四個可能存在的主要緣由。實際上，這篇文章源自DarkReading在2010年9月27日發表的這篇文章《Five Reasons SIEM Deployments Fail》，是一個採訪多位業內人士的綜合報道。原文指出的是五個緣由。第五個緣由談及的是「SIEM的伸縮性問題，尤爲是事件採集和處理性能的問題」。

其實，文章說起的四個問題，我以前也都有提到，針對國內的狀況，咱們也一直在試圖緩解或者處理這些問題，至少儘量地規避這些問題。
1）SIEM 很難用，若是是SOC就更難用。沒錯。所以，這不只須要技術策略，還須要市場策略，正如咱們從2008年開始實踐的那樣，咱們開始一個「Make SIEM Simple！」的行動，簡化SIEM，咱們倡導日誌審計。根據客戶需求和市場細分，咱們從多個方面簡化SIEM的技術複雜度，部署複雜度，維護複雜度。 固然，永遠沒有銀彈，簡化不等於簡單，問題的關鍵在於如何找到一個細分市場，這個市場的客戶可以接受目前程度的簡化。我要告訴SIEM從業人員的是，這個 細分市場是存在的！因此，需求分析很重要！

2）事件標準化的問題。早期有人從IDS的角度出發提出了IDMEF，不過無人問津，後來，ArcSight也搞出了一個標準化格式CEF，不過有點可能會成爲另外一個CheckPoint的OPSEC。目前比較火的是美國MITRE搞的CEE。MITRE具備軍方背景，他們以前搞出了CVE。若是國內有人致力於研究和運用這個，我們能夠交流。

3）關於技術與管理的衝突問題。這個主要是指SIEM爲了得到最終的分析效果，須要收集各類門類的信息，但不幸的是這些信息每每隸屬於不一樣的部門，例如網 絡和主機，還有應用可能就分屬於2到3個部門，如何統一收集和分析這些信息，同時確保不會引起你們的或真或假的擔心，以及不介入部門間的利益糾葛，是一個 問題。這個問題的規避須要在規劃和實施的時候進行很好的預處理。很重要地，在規劃的時候十分重要。一個好的Consultant可以減輕不少壓力。更多的 信息，我會在之後的博文中陸續介紹。實際上，我以前也有說起過。

4）一些甲方的技術和管理人員把SIEM當作安全管理的銀彈，也就是指望太高的問題。這個，我以前也屢次說起，關鍵仍是要在一開始規劃的時候，定位要準確，需求要明確。「Don't Boil the Ocean！」。

5）關於SIEM的性能和伸縮性的問題。這個就是SIEM從業的技術人員須要潛心研究的問題了。