花錢買罪受？SIEM的五大常見問題

最新 07-09

引言

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

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

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

快速的搜索和響應時間

能夠與任何團隊或個人儘可能精細化地共享數據

內置威脅情報，突出攻擊者活動

零誤報

大數據及分析技術

機器學習或行為分析的自動化

數據關聯自動化

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

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

本文主要包括以下三部分內容：

SIEM的五大常見問題

實際應用案例

SIEM採購建議與功能實現的必要條件

SIEM的五大常見問題

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

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

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

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

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

嗚嗚嗚……它沒有電池…

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

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

MITRE ATT＆CK：這個開源框架是攻擊方法與行為的模型。防禦者可以用它來識別攻擊者可能使用的技術方法，查看他們的流程和控制措施，從而找出檢測和預防覆蓋面中的不足。

Sigma：這是一種SIEM的中性規則語言，可用於編寫支持任何環境及任何SIEM的規則。為了使這個概念發揮作用，轉換過程採用SIEM非自動編寫的規則，適用於特定的SIEM。

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

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

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

依然在等待……

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

讓我自己解決？我花錢不就是為了讓你來幫我的么？

一個好的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.。

該域名未出現在威脅情報資料庫中。

該域名看起來並非隨機生成。

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

說來也怪，很多單位都能接受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的常見問題，成為威脅檢測戰役中的常勝將軍。

註：本文作者Justin Henderson，SANS培訓老師（課程名稱：SIEM with Tactical Analytics），擁有十多年經驗的安全架構師與研究員，熱衷於傳道授業解惑。