2011年6月26日 星期日

關於日誌管理產品的十個注意事項

 SecurityWarrior ConsultingAnton Chuvakin博士在去年底的時候寫過一篇文章:Top 10 Things Your Log Management Vendor Won't Tell You,很有意思。實際上,他提醒用戶在選擇日誌審計產品,尤其是用它來做內控的目的的時候應該注意的問題。這些注意事項有助於幫助客戶建立起合理的產品預期,也有助於督促日誌審計/日誌管理廠商去思考這些問題背後的解決方案。好吧,讓我們大家都擦亮眼睛。


原文摘錄如下:
While many people have seen the “Top 10 things that your chef, real-estate agent, wedding planner or pilot won't tell you,” the world has not yet seen Top 10 things your log management vendor won't tell you. Finally , this gap has been closed.

·         “We talk analytics, but really, most of our customers only use us for collection.” 
While some products within SIEM and log management offer advanced analytics features, many customers are not truly ready for them. They need to  start dealing with the basics— logging, log collection, log review — before delving into advanced areas. Buying a product based on features you won't use is a mistake.
·         “Our tool won't make you PCI compliant. You'd have to do A LOT of things yourself – every day – to get and maintain compliance.”
Sadly, many security solutions—and SIEM / log management are no exception—are sometimes sold as “compliance in a box.” You need to be aware that to stay PCI compliant you need to do more than purchase tools.
·         “No, you cannot buy an entire SOC in this small box.”
Just as with compliance, you cannot buy an entire Security Operations Center in a box, big or small. However, some will try to sell you their SIEM as “SOC- in-a-box.” Running an effective SOC includes multiple processes and procedures which are just as necessary as a market-leading SIEM tool.
·         “We are cloud-ready, because … mmmmm… well, we are ready for it!”
Many vendors will tell you that their tools are cloud-ready – without really thinking about what they mean. Effectively monitoring traditional and multi-tenant cloud environments distributed across regions and countries requires more than updated marketing materials! As a customer, you will need to carefully test the tool in your own hybrid environment before concluding that it is “cloud ready.”
·         “Our SIEM is really just a renamed log management tool. But that's all you probably need.”
The confusion around SIEM and log management functionality rages on – it also allows some tools to be sold as SIEM without having any critical SIEM functionality such as correlation and real-time dashboards. Even though it might be all many customers need, it does not make such tool a SIEM tool.
·         “We can do everything with logs, but it might require some SMALL customizations. Our PS team is standing by!”
More than a few SIEM vendors will promise support for every possible log including logs they have never seen. However, fully integrating a new log source for reporting, correlation and visualization will always takes work and cannot be taken for granted.
·         “If you make a mistake with capacity planning, we'd be happy to sell you more log management than you really need.”
Many organizations are having trouble estimating how much log data will be coming into their SIEM or log management tools. Both underestimating and overestimating are common. It is recommended that you spend about a week measuring log volumes across the systems that will be reporting to a SIEM.
·         “We think our tool is scalable, but we don't really have production customers of your size. Our engineers believe that it might work.” 
Scalability claims are cheap and frequently made ​​by SIEM and log management vendors. However, the only real proof that the tool will scale to your requirements is testing the tool in your environment.  Thus, you should insist on performance testing during the pilot if there are any doubts.
·         “We estimate our performance using really small log message sizes.”
Yes, our tools can do a million messages an instant – but these are our special messages that we create in the lab. Nowadays, application logs and the proliferation of XML-based logging has pushed message sizes up to 1 kb or more from the traditional 200 byte logs from firewalls.  Thus, you need to be wary of performance estimates based on such artificially short logs.
·         “Our tool offers predictive security intelligence. No, we don't know what it means either – and we can't really predict it.”
SIEM is one of the most over-hyped and over-marketed security technologies out there. The only way to make sure that a particular tool will satisfy your requirements is too carefully spell out those requirements and then test the tool yourself.

讀完這篇文章,我也是頗有體會。
的確,對於我接觸到的目前國內大部分客戶而言,使用日誌審計/日誌管理產品的主要用途就是收集日誌,進行查詢、統計和報表。關聯分析幾乎很少使用。一方面,關聯分析功能是一個吃力難討好的技術,要么就要做到滿足用戶期望80分以上,否則再做也沒啥用。用戶對於關聯分析的期望往往較高,即要求分析能力強,又要求對普通管理員易用易懂。從技術層面來說,還有一段路要走,要看商業智能(Business Intelligence)技術發展到什麼程度了。另一方面,即便有較強的關聯分析功能,大部分用戶也並不關注。對於他們而言,當前工作的重心還是在收集、存儲、查詢、統計上,因為這些功能對用戶是切實有用的,是基本的功能點。我覺得這是當前LM產品的重點所在。實際上,即便是這些看似基本的功能點也隱藏著巨大的技術挑戰。因為面對海量異常事件的收集、存儲和查詢,LM廠商們將必須將性能提升到一個用戶可以接受的水平。與Anton Chuvakin的觀點差不多,我也認為對於用戶而言,在考慮SOC之前最好先考慮SIEM,或者乾脆先考慮LM。至少不要在考慮的SOC的同時忽略SIEMLM。既然對於用戶而言,對於當前的日誌審計/LM產品重點是考察收集、存儲和查詢統計,那麼又如何去甄別各個廠商對此的宣傳和技術參數呢?例如,最重要的一個技術參數叫做EPSEvent per Second),亦即每秒事件數。實際上,各個廠商在給出這個值的時候,其條件和內涵可能完全不同。首先,你需要知道這個值是在什麼條件下獲得的,至少要知道是什麼CPU、多少RAM、多少硬件資源的條件下獲得的;可能的話,還要知道測試的基準日誌源是什麼樣的,這些日誌是單設備日誌,還是多源日誌,平均日誌長度是多少?除此之外,你還需要知道EPS的內涵所指為何?是單純收集上來的EPS?還是指收集上來且歸一化後的EPS?抑或是收集上來、歸一化並持久化存儲後的EPS。內涵不同,LM產品的工作機制不同,進行EPS的數值比較可能沒有什麼意義。而往往,幾乎不會有廠商主動告訴你這些。如果你比較 Care這些,最好的方式是建立自己的測試基準,進行橫向實際測試比較。所以,對於重要的客戶,我比較強調PoC。用戶必須清楚的認識 到,LM是一類管理系統,其運用必須遵循管理類系統的生命週期。簡單的說,無論廠商如何說LM,用戶都是清楚認識到實施LM的工作內容,並且這些工作有很 多是你必須參與其中,無法逃脫的。例如,我們在上LM的時候,應該了解到日誌源種類和類型、規劃日誌容量、設計查詢統計模板,同時,配套的運維也需要建立起來。別幻想一聽完廠商的產品介紹就認為有了這個產品一切都OK了。

沒有留言: