引言

眼下很多單位的安全業務都深受”威脅檢測”問題的困擾。Mandiant安全公司在2018年的M-Trends報告中就指出，從攻擊開始到發現攻擊活動的平均時長是99天。在這個“貓捉老鼠”的游戲中，很明顯，現在這只貓還只是一只在喝奶的小貓咪。為了讓它迅速強大，眾多安全廠商開始鼓吹為這只嫩貓配備一個叫做“SIEM”的神器。可沒想到，投了錢，煩惱卻越來越多……

我曾在SANS開過一門“SIEM with Tactical Analytics”的課程，很多人認為我是SIEM的絕對擁護者。當然，我的確是，因為我認為SIEM是現有的、最強大的檢測解決方案之一。但是，“最強大”并不一定意味著“最好”。雖然我也希望SIEM能夠解決我們所有的問題，但事實并非如此。

[[235767]]

甲方單位采購SIEM一般都會帶著下面這些美好的愿望：

• 快速的搜索和響應時間
• 能夠與任何團隊或個人盡可能精細化地共享數據
• 內置威脅情報，突出攻擊者活動
• 零誤報
• 大數據及分析技術
• 機器學習或行為分析的自動化
• 數據關聯自動化

但實際部署后，除了最開始的采購投入，還會產生大量日常維護的費用支出和人力成本。

從目前的SIEM技術及部署情況來看，上面提到的“美好愿望”都是不合理的。首先我們要明確的一點是，SIEM只是整個安全保障項目中的其中一部分，它是否能夠發揮作用仍然依賴于其它安全組件。

一、SIEM的五大常見問題

1. 收集的數據質量越高，SIEM性能越好

明確收集哪些類型的日志比單純地收集日志更重要。

只簡單地部署一個SIEM起不到任何安全保障的作用——將數據加載到SIEM中才賦予了它真正的價值。那么問題來了：很多數據源并不理想，且大多數數據不易以二進制“好/壞”的方式分類。比如，Windows日志的收集非常普遍，對安全操作人員來說，這是一個最好也是最糟糕的數據源。

對于剛接觸的安全人員來說，Windows系統甚至都不會記錄重要的事件日志，因為進程和命令行日志、PowerShell日志和Windows驅動程序框架日志在默認情況下都是不啟用的。但如果在未調試的情況下記錄所有日志，SIEM就會因為大量的無用數據而不堪重負。默認啟用的Windows日志盡管作用很大，但也會產生大量的垃圾信息。日志的收集、解析和過濾是一門需要時間和耐心的藝術。另外，還要對日志的有效性進行反復評估。

更何況，我們還沒有考慮數據如何輸入SIEM的問題。如果該日志由syslog(一種常見的日志傳輸協議)發出，那么管理員必須執行解析。這就意味著該日志在SIEM中的狀態可能已經丟失了原始事件中的某些數據和環境信息。還是以Windows為例，單個Win10系統在本地二進制XML日志結構中有超過800個字段。然而，大多數SIEM對日志源進行解析、削減和轉換后就只有200個字段了。

這個結果就像你本來是可以開跑車的，卻去騎了馬。你能走多遠，取決于你收集了什么數據、通過什么樣的方式收集。

2. SIEM要與實際案例相結合

SIEM無法將信息安全領域的專業知識和日志應用與你的具體需求實現自動化結合。一旦數據進入SIEM，就需要你來告訴SIEM應如何處理這些數據。簡單來說，就像我們買了一個玩具，玩具本身是不帶電池的，需要我們準備好電池并完成準確的安裝。SIEM就是一個很酷的玩具，但是木有電池……

你是否也有過這樣的經歷，詢問某個廠商關于他們SIEM產品的告警規則或檢測攻擊者所使用的技術，卻只得到“每個單位都不一樣”這樣的回答?雖然一定程度上的確如此，但還是有一些基于常見攻擊方法的技術具有普適性。下面我舉兩個例子：

• MITRE ATT&CK：這個開源框架是攻擊方法與行為的模型。防御者可以用它來識別攻擊者可能使用的技術方法，查看他們的流程和控制措施，從而找出檢測和預防覆蓋面中的不足。
• Sigma：這是一種SIEM的中性規則語言，可用于編寫支持任何環境及任何SIEM的規則。為了使這個概念發揮作用，轉換過程采用SIEM非自動編寫的規則，適用于特定的SIEM。

總而言之，SIEM+應用案例=幸福的婚姻。不與實際應用相結合的SIEM早晚都會“離婚”，SIEM的“誓言”、“信任”以及強大的檢測功能都將形同虛設。

3. 數據越多并不等于檢測功能越強大

大數據時代已經來臨。安全運營團隊正在爭先恐后地收集他們可以得到的所有數據。除了搶房，還要搶數據。

最常見的錯誤就是SIEM中充斥著大量無用的數據，我把這種現象稱之為“茶歇SIEM”——即使是簡單的搜索，也需要數秒或更長時間才能完成。如果一位分析師一直都在等待搜索結果，那么他們可能就會自然而然地選擇值得搜索的內容，即返回結果最快的。

SIEM需要的是增強分析，而不是阻礙分析過程。簡單來說，less is more(過猶不及)。數據越多，SIEM性能反而越差，分析師掉的坑也就越多。

4. 缺乏環境

一個好的SIEM應由分析師構建，為分析師服務。也就是說，當分析師查看警報或日志時，SIEM能夠提供有利的環境信息。如今市場中大多數SIEM在日志豐富化(log enrichment)或為日志添加環境信息方面的功能都很完善。但是，在實際部署中，相對于log enrichment，很多人都更加注重數據的收集。

例如，如果一個分析師正在查看“covertc2.com”這個正在被訪問的可疑域名。一個DNS日志包含域名、源IP和目的IP報頭信息、產生的IP地址以及DNS記錄類型。這些信息是否足以讓分析師確定該域名為惡意、可疑還是良性?很明顯，僅根據這些有限的數據作出的決定肯定存在偏差。

現在請你想象一下，如果SIEM添加了以下這些環境信息，你能夠推測出什么?

• 該域名不在訪問的前100萬個網站中。
• 該域名注冊于2016年11月1日。
• 該IP與伊利諾伊州的一家企業有關。
• 該IP屬于Total Server Solutions L.L.C.。
• 該域名未出現在威脅情報數據庫中。
• 該域名看起來并非隨機生成。

這些環境信息并不能讓分析師百分之百地確定善惡，但無疑為分析師提供了很多背景信息，能夠幫助他們作出更加明智的決定。

5. 重心偏離：過多關注SIEM的維護

說來也怪，很多單位都能接受SIEM的一大弱點——人力成本(有時甚至是一筆巨額開銷)。他們會聘請專家或要求現有團隊為數據收集和SIEM的維護提供支持。因此，最后造成的局面就是該單位沒有發揮SIEM的服務價值，反過來消耗大量資源來“伺候”它。這方面的人力投入如果放在其它地方，完全可以實現更大的價值。

如果你花80%的時間在SIEM的維護上(代理部署、日志解析、系統升級)，那么你就很可能永遠無法實現SIEM價值的最大化。自動化對于一個成功的SIEM實施方案來說太重要了。你的環境是不斷變化的，“自動化”也應緊跟步伐，只有這樣才能將你的時間花在戰術實施方面。

二、應用案例：6周 vs. 14個月

關于第5個問題，我們來看一個實際案例。我曾供職的一家公司推出了一個SIEM解決方案。該項目中有15個全職員工，項目總時長14個月。一年以后，他們暫停了項目，反思SIEM實現了什么功能、為公司創造了什么價值。回顧結果并不理想。14個月以后，他們仍然處于數據收集的狀態，檢測功能依然無法發揮作用。

后來我有幸介入了這個項目。在不到一個月的時間內，推出了一個全新的方案：利用自動化技術部署日志代理、數據收集、數據源部署，修改或禁用默認或預警警報，并根據已豐富的日志數據實施新的警報機制。

直到第6周快結束時，不到5個正式員工所輸出的解決方案超過了15個人花了14個月的工作成果。顯然，改革后SIEM的投資回報遠超預期。

三、采購SIEM的6大關鍵前提

一個成功的SIEM方案必須具備以下條件：

• 員工具有專業的信息安全知識背景
• 員工具備對SIEM產品的充分了解
• 數據豐富功能
• 支持自動化
• 對重要數據的收集與利用
• 檢測功能與實際應用相結合

機器學習和行為分析也是非常重要的技術組成部分。但是在你還沒有做好上述準備之前，暫且不要將精力全部放在機器學習或行為分析上。一個已達到上述6個前提條件但尚未實現自動檢測功能的SIEM應用單位將比沒有做好準備卻專注于自動捕捉異常行為工具的單位更具潛力。

關鍵要點

根據一般的經驗法則來看，SIEM更適合成熟的、有經驗的安全團隊來操作。當然，這也不是硬性規定，我同樣也看到過很多初級團隊成功部署SIEM并取得正向結果。他們能夠將SIEM很好地與部署環境相結合，并實施像防火墻規則這樣的安全控制措施。但大多數情況下，很多團隊都是莽撞地加入SIEM大軍，迎面即遇上了我上述列舉的五大問題。

關鍵要點如下：SIEM絕不能成為展開安全保障的切入點，尤其是在剛成立安全部門的情況下。一口吃不成胖子，首先要從最基礎的做起。終端安全解決方案、網絡分段、防火墻等等在安全防御方面路漫漫其修遠兮，但是對于檢測功能的實現卻尤為必要的。完成基礎內容后，下一步當然也不是立馬去買個SIEM回來。只有當你符合上述要求時，才可以推進SIEM的購買和維護。

我希望以上的觀點能夠幫助你的團隊規避SIEM的常見問題，成為威脅檢測戰役中的常勝將軍。