安全運營的“天坑”？ SIEM 的殘酷真相
2020年網絡安全的焦點是“人的因素”，重心是“安全運營”，但是安全運營的發動機——SIEM，卻始終是CISO頭上的一個大包。
SANS 2019年的報告(上圖)顯示，超過70%的大型企業仍然依賴安全信息和事件管理(SIEM)系統來進行數據關聯、安全分析和運營。此外，很多企業的安全運營中心(SOC)團隊還圍繞SIEM配備了用于威脅檢測/響應、調查/查詢、威脅情報分析以及流程自動化/編排的其他工具。這就產生了一個問題：如果SIEM是安全分析和運營的“重器”，為什么企業還要補充那么多其他工具?
研究表明，盡管SIEM擅長發現已知威脅并生成安全與合規性報告，但它并不適合檢測未知威脅或其他安全運營場景。而且，有23%的安全專家表示SIEM平臺需要大量的人員培訓和經驗，而21%的人則認為SIEM需要不斷調優并消耗大量運營資源才能發揮作用?？傊?，SIEM不會很快失寵，但顯然還遠遠不夠。
安全關聯的進化怪圈
“痛苦金字塔”(Pyramid of Pain)
David Bianco于2013年提出的“痛苦金字塔”(Pyramid of Pain)眾所周知。位于塔尖的關注重點(TTP)就是檢測活動中你需要理解的那些指標。但SIEM檢測發展歷程及其當前狀態中存在一些令人費解的謎團。本文正是要破迷解密，帶您正確認知安全關聯的過去與現在，揭示關于SIEM的殘酷真相。
首先，讓我們的思緒穿越到1999年。那時主機入侵檢測系統(HIDS)是高大上的代名詞，“SIEM”這詞兒在Gartner分析師眼里也就是個華麗麗的新鮮玩意兒。但是，有些供應商居然已經開始開發和售賣“SIM”和“SEM”設備了。要知道，這可是1999年!設備可火了!
這就是第一批很快便會被稱為SIEM的工具，擁有非常基本的“關聯”規則(真的，不過是聚合和計數單條屬性，比如用戶名或源IP之類的)，例如“多個目的地址同一端口的多個連接”、“包含SYNflood的思科PIX日志消息重復50次”、“SSH登錄失敗”等等。很多此類規則都非常脆弱，攻擊行為的些微改變就可以規避規則觸發。而且，這些規則還是設備依賴的(例如，你得針對每個防火墻設備編寫此類規則)。所以，SIM/SEM供應商不得不加載成百上千條此類規則。而客戶則在啟用/禁用和調整大量規則的深淵中痛苦不堪。
1999年時，Dragon Squire之類主機入侵檢測系統真的是90年代安全技術的一大突破，可以梳理日志，查找“FTP:NESSUS-PROBE”和“FTP:USER-NULL-REFUSED”之類的東西。
略過千禧不談，我們快進到2003-2004時期——革命爆發了!SIEM產品橫空出世，放出兩個大招：規范化事件和事件分類。分析師花點時間將設備事件ID劃入SIEM分類事件類型中(如：Windows事件ID 1102該往哪兒去?)，然后對此編寫檢測規則。SIEM檢測內容編寫就此變得有趣!
SIEM的這個巨大進步為我們帶來了著名的關聯規則，例如“同一目的地址遠程訪問類事件后的多個漏洞利用類事件”。這種規則開始支持跨設備通用檢測邏輯，分析師的生活從此變得陽光明媚!通用規則的適用性強得多(就好像“任意漏洞利用”和“任意遠程訪問”與特定的攻擊(例如VNC訪問))，還能跨設備使用——只需編寫一次，隨后就算換了另一種防火墻，此關聯規則依然能檢測惡意事件。
哇哦，簡直神奇!有了這個，你就(大概)能憑借幾十條好規則走遍天下，無需再在幾十個系統和多個操作系統版本類型的無數正則表達式、子串和設備事件ID間苦不堪言。在當時，SIEM可謂是安全產品的重大進步，這就好比汽車淘汰了馬車。
此外，一些人對通用事件表達(CEE)計劃寄予厚望，開始努力生成現實可用的全球日志分類和模式(大約在2005年)。
一覺醒來還在解放前
但你絕對想不到此后發生了什么!
現在，我們快進到今天，已經跨入到2020年。實際上，當前的大多數檢測內容還是用的90年代風格——匹配原始日志的狹窄而精確的風格?？纯碨igma內容就知道，1998年的Network Intelligence enVision SIM用戶都能看懂其中大部分檢測!不可否認，我們今天也有ATT&CK框架，但這解決的是另一種問題。
還有一個特別奇怪的視角：隨著機器學習和分析的興起，如果我們想要掌握更多安全用例，而不僅僅是檢測，對干凈的結構化數據的需求肯定會不斷上升。然而，我們恰恰是只增加了數據總量，能饋送給機器學習算法的數據并沒有多少。我們需要更多干凈的、豐富過的數據，不是更多數據!現在不是人多力量大的時代，數據的質量更甚于數量!
這個進化過程就好像我們從馬車時代走到汽車時代，然后是電動汽車，然后是噴氣式汽車，結果又回到馬車時代……
那么，這些年到底發生了什么?
從揮舞關聯“魔法棒”15年的ArcSight老手，到用現代工具運營檢測團隊的安全主管，對安全同行的調查給出了答案。
但在揭曉最終答案之前，我們不妨回顧一下調查數據收集過程中同行們都是怎么想的：
原始搜索贏了
缺乏事件規范化或規范化做得很差(或懶惰到依賴客戶去做規范化工作)的產品，因不相干的原因贏得了市場(比如所收集數據的總量等)，而新一代安全運營中心(SOC)分析師從沒見過別的工具。于是，分析師用手頭的工具勉強應付。好吧，我們暫且將此推理邏輯稱之為“原始搜索贏了”。
獵手贏了
威脅獵手春風得意，把傳統檢測人員逼到墻角，一腳踢出窗外?，F在，威脅獵手試圖用自己狩獵未知威脅的方式來檢測搜索已知攻擊的蛛絲馬跡。這可稱之為“獵手贏了”。
誤報贏了
另一種想法是：對“誤報”(FP)的容忍度下降了(由于不斷惡化的人才短缺狀況)，所以編寫更窄的檢測規則降低誤報率開始流行起來(“漏報”是萬萬不可的——我們只能編寫更多規則來阻斷漏報)。規則狹窄了也更容易測試些。不妨將這種思路稱之為“誤報贏了”。
數據多樣性贏了
還有一種假說與現代威脅和所收集數據更多樣有關。由于我們需要檢測更多種類的更多東西，規范化事件和分類事件就被擠到了后面。這種思路可稱之為“數據/威脅多樣性贏了”。
以上結論您認同哪個?您在檢測工作中遇到過類似情況嗎?
顯然，上述解釋都是盲人摸象，直覺告訴我們，SIEM的魔法并不存在，當所有碎片拼接在一起，我們逐漸看清了SIEM的殘酷真相：
SIEM中的規范化和分類化方法從未切實起效!在其誕生之初的2003年就沒用，此后的每一年里都毫無效果。現在的環境中依然如此。除非某些事情來個大逆轉，否則SIEM中規范化和分類化方法無效的事實不會有任何改變。
認識到這一點真是令人傷心，尤其是對構建、宣傳、改進和試圖全球標準化該方法(通過CEE)的人而言。
事情的真相真的有這么糟嗎?很不幸，還真是!SIEM事件分類其實……
- 總落后于時代，現在比之前落后得更多;
- 跨多個事件和日志源時不一致——當今每家供應商均如是;
- 各供應商之間差異很大——無法達成只學習一次的效果;
- 隨時間流逝積累的錯誤和遺漏越來越多;
- 無法有效測試當今面對的真實威脅。
所以，我們甚至不能說“SIEM事件分類已死”，因為它就沒真正活過。舉個例子，某SIEM供應商的“身份驗證失敗”事件類別可能漏掉新版軟件(比如Windows更新引入的新型事件)，漏掉不常見日志源的事件(SAP登錄失敗)，或者漏掉錯誤映射到別的東西上的事件(例如“其他身份驗證”類別)。
人們總會自欺欺人，編寫愚蠢的字符串匹配和基于正則表達式的內容，而一旦涉及性命攸關的入侵檢測，沒有人會把希望寄托在事件分類上。
下一代SIEM，取決于下一代SOC
根據安全牛SOC報告(上圖)，下一代SOC最主要的特征之一就是擺脫被SIEM支配的困境。
下一代SOC的“大腦”，將是SIEM、風險管理和威脅情報的融合領域，威脅情報正在成為企業打造全新高效安全運營平臺，提升安全運營能力的核心。
作為企業內部安全日志的匯聚器，SIEM的基本功能永遠不會過時，而且本地安全日志也將是“內生安全”中的高價值威脅情報來源(甚至比蜜罐和商業威脅情報的價值更高)。
下一代SIEM產品log Rhythm的儀表盤界面
而下一代SIEM產品，無論在云端SaaS還是本地，也將順應SOC智能化、自動化、平臺化的大趨勢。(支持)開源、上云、自動化和智能化是SIEM產品的四個變革方向，我們在IBM Cloud Pak、Splunk Cloud、Exabeam、翰思和LogRhythm的產品路線中都看到了下一代SIEM的影子。
無論下一代SOC還是SIEM，甚至SOAR和TIP，其最終目標都是為新威脅形式下的風險管理和CISO的新業績指標服務，而這些關鍵指標背后的安全運營變革，安全牛將在《下一代SOC報告》中詳盡闡述。
【本文是51CTO專欄作者“安全牛”的原創文章，轉載請通過安全牛（微信公眾號id:gooann-sectv）獲取授權】
