SIEM技術已經(jīng)存在并被使用了25年以上，起初只是在海外和國內(nèi)部分頭部企業(yè)使用，用以解決數(shù)據(jù)孤島、安全事件分析、運維管等問題。鑒于技術原因起初的它并不好伺候，甚至是花錢買罪受。但隨著技術的不斷發(fā)展和實際需求，它又再次回歸我們的視線。本文將帶您了解SIEM并提供SIEM建設的一些建議。

SIEM定義

Security information and event management (SIEM) 安全信息和事件管理，通過多個維度的日志收集和場景分析，實現(xiàn)實時和歷史事件的分析，旨在幫忙企業(yè)提升事前預測、事中檢測和事后調(diào)查取證的能力，同時配合企業(yè)內(nèi)部工作流程做到信息安全事件的閉環(huán)落地，以提高信息安全防御水平，提升信息安全管理能力。

SIEM技術成熟度

在Gartner發(fā)布的2021安全運營技術成熟度曲線中(如下圖)，對主流的安全運營技術進行了分析，其中SIEM已步入穩(wěn)步發(fā)展并趨進成熟的階段，這個分析也正符合市場的現(xiàn)狀，很多企業(yè)在安全運營中已把SIEM(或者叫做態(tài)勢感知)作為主要實現(xiàn)平臺。

知識點補充：

技術成熟度曲線中指出技術的發(fā)展需要經(jīng)歷：萌芽期、膨脹期、低谷期、恢復期、成熟期(對應上圖橫軸的5個階段)。在判斷時先看報告的出具年份①，其次查看您關注的技術成熟度②，根據(jù)標注的淡藍色③來看還有多少年到達成熟期。以SIEM為例就是2021+2~5年，在2023-2026年是SIEM技術徹底成熟的時候。

SIEM價值體現(xiàn)

1.外部驅(qū)動

不管是國家一把手在重要精神講話中提到態(tài)勢感知，還是等保2.0中的“一個安全管理中心+三重防護”的要求，都可以與SIEM進行契合。

2.內(nèi)部驅(qū)動

以SIEM為抓手，幫助企業(yè)內(nèi)部各層面人員開展安全運營工作。

領導層：

可縱覽安全現(xiàn)狀和決策：這里特指CIO這個層面，他們普遍對于業(yè)務非常熟悉，也懂部分技術。他們的職責是規(guī)劃信息化建設，搭建IT團隊，向上層匯報獲得老板的支持，為企業(yè)降本增效和體現(xiàn)個人價值。那一個運營良好的SIEM可以幫助CIO判斷現(xiàn)有安全現(xiàn)狀，如安全態(tài)勢展現(xiàn)、攻擊可溯源、工作量可視化。

運維層：

可集中管理和舒心運維：運維人員考慮的是確保各服務安全穩(wěn)定的運行，及時發(fā)現(xiàn)可以安全事件。他們的點在于保障業(yè)務對老板有交代，同時在運維中盡可能的便捷和自動化。通過SIEM可以解決分散日志的管理、解決各安全產(chǎn)品多控制臺界面查詢、解決設備間聯(lián)動、告警事件工單流轉(zhuǎn)、并可依托此平臺進行攻防演練，提升自身應急響應能力。

業(yè)務層安全：

業(yè)務更多的關注系統(tǒng)的可用性，以及業(yè)務數(shù)據(jù)分析挖掘給他們帶來創(chuàng)收機會。SIEM通過收集業(yè)務埋點數(shù)據(jù)采集，分析業(yè)務關注的指標點，并結(jié)合場景給到一些建議和提示(不能替代風控產(chǎn)品)。

SIEM投入產(chǎn)出

如果問這個解決方案貴嗎?回答是，相比其他安全產(chǎn)品會略貴。但是這個投入主要看怎么衡量，如果采購了只是安全團隊自己在“玩兒”(產(chǎn)品定位主打安全可再看下定義)，那只是少部分人在使用，并沒有充分發(fā)揮它的價值。在實施之前因充分評估，特別是跨部門跨團隊的場景協(xié)作(起初肯定應該定位在安全場景用例)，用的人越多參與的需求越多，性價比就越高。

SIEM架構

SIEM的整體架構大致如上圖所示，以一條Windows系統(tǒng)登錄日志為例，來過一遍經(jīng)過的所有流程。

1.日志采集

當用戶成功登錄windows電腦時，會產(chǎn)生一條Event ID 4624的日志，系統(tǒng)會記錄下很多信息，包括但不僅限于時間、IP地址、系統(tǒng)版本、登錄類型(本地或遠程)、用戶名、登出狀態(tài)。

2.范式化

在SIEM中就是把這一整串的原始日志進行拆分，并按廠商定義的說明或者企業(yè)自行定義來豐富標簽內(nèi)容。

3.事件過濾歸

并就是把同類型的日志進行歸類，如windows、Linux的登錄日志其實格式是不一樣的，可以歸為2大類。并把暫時不關注的字段篩選去除，把需要關注的內(nèi)容提取出來。

4.關聯(lián)分析

這部分內(nèi)容是SIEM的精髓，如何制定策略使誤報率低，并產(chǎn)生有價值的場景(usecase)是各使用相關方需要重點考慮的。當然場景制定的優(yōu)劣離不開日志源的質(zhì)量、分析人員的經(jīng)驗等多方因素。繼續(xù)以上為例，可以定義在30分鐘內(nèi)記錄張三共產(chǎn)生了多少次登錄行為。

5.告警

如果30分鐘內(nèi)有上百次的登錄行為，那我們要判斷下是否電腦有被入侵的可能?如果30分鐘內(nèi)有5次左右登錄，那會不會張三同學上班在摸魚呢(勤接水勤走動勤登錄)? 具體告警閾值和產(chǎn)生結(jié)果的判斷，由各位充分發(fā)揮想象或者根據(jù)實際情況來制定。

6.安全事件運維

就是根據(jù)產(chǎn)生的告警來判斷和處理。可以人工處置去現(xiàn)場或者電話確認情況。如被確定為高危行為也可以聯(lián)動相關產(chǎn)品進行實時封禁操作。

7.可視化展現(xiàn)

設定預制報表，定期出具一份統(tǒng)計結(jié)果。也可直接在大屏展示以上事件的結(jié)果，如攻擊事件+1 或 摸魚事件+1 (UEBA用戶實體行為分析更偏向此塊內(nèi)容分析)

SIEM關鍵技術指標

• 底層數(shù)據(jù)的收集和管理

這塊個人覺得是最重要的內(nèi)容，如果最基礎的日志收集和管理都不穩(wěn)定，那上層的分析和告警必定會受到影響，至少應該支持每日TB級的數(shù)據(jù)收集和管理能力。日志來源包括內(nèi)部本地和云環(huán)境的日志。

• 架構和部署

這塊主要指系統(tǒng)的橫向擴展能力，如有大型企業(yè)涉及多個分公司的情況，架構應能適應異地的擴展和日志的同步。

• 分析檢索

產(chǎn)品應支持統(tǒng)計學模型和AI算法(ML機器學習、NLP自然語言處理)方面的能力。

• 異構產(chǎn)品協(xié)作

與其它安全產(chǎn)品的協(xié)作能力，如果選購的SIEM產(chǎn)品只支持同廠商的安全設備聯(lián)動和對接，后期涉及自動化編排和聯(lián)動等都會造成約束。

• 易用性

產(chǎn)品界面的易用性設計，對于運營人員的體驗來說也非常的重要。

• 技術棧

產(chǎn)品各模塊實現(xiàn)所使用的技術棧是否穩(wěn)定、安全、主流等也是需要進行考慮的問題。

• 實施人員

SIEM項目的建設同樣需要考慮項目團隊的實施經(jīng)驗和能力，一個具有豐富經(jīng)驗的實施團隊，對于項目的完美交付絕對起著至關重要的作用，他們能快速準確的理解客戶需求，將人、技術、流程進行合理串聯(lián)設計，并擅長疑難問題的排錯。

SIEM建設建議

1.需要有一定的安全建設基礎才開始SIEM之旅。

這里的安全建設指安全產(chǎn)品的部署，如殺毒軟件、終端管控、網(wǎng)絡準入、VPN、上網(wǎng)行為管控、數(shù)據(jù)防泄漏、IDPS、防火墻、WAF、流量探針、主機安全、蜜罐、微隔離、EDR、威脅情報、漏洞掃描、郵件安全網(wǎng)關、堡壘機等。并不是說沒有這些設備不能開始SIEM的建設，但是SIEM更多的還是考慮威脅方向的發(fā)現(xiàn)。如果沒有足夠的上下文和數(shù)據(jù)源關聯(lián)，SIEM就不能被充分利用。同樣的道理CMDB、應用服務器和系統(tǒng)日志也同樣重要，比如應用服務器訪問日志可以用來確定WAF或者IDPS上的攻擊是否成功，如果沒有相關數(shù)據(jù)SIEM的判斷也是不精準的。

2.建設之初做好整體規(guī)劃，包括項目的范圍和期望輸出價值。

范圍指的是定義好最終交付場景的方向。一般分為威脅類方向、合規(guī)類方向、業(yè)務類方向。根據(jù)范圍考慮每個方向輸出的價值：

威脅類：

更多的是企業(yè)安全團隊優(yōu)先考慮的問題，可能是現(xiàn)有安全產(chǎn)品和系統(tǒng)日志層面的組合，發(fā)現(xiàn)互聯(lián)網(wǎng)側(cè)和內(nèi)網(wǎng)側(cè)的可疑攻擊風險，做的更好的可以結(jié)合威脅情報和ATT&CK框架，觀察和發(fā)現(xiàn)攻擊者的TTP(技術、戰(zhàn)術和過程)。

合規(guī)類：

更多的可以和內(nèi)部合規(guī)團隊溝通，將他們的審計要求體現(xiàn)在輸出中，如防范內(nèi)部人員數(shù)據(jù)泄露、運維人員異常操作等。

業(yè)務類：

為業(yè)務賦能相對于前兩者的優(yōu)先級會靠后一些，但不影響在建設初期協(xié)同參與討論。如針對特定業(yè)務場景的風險控制指標的監(jiān)控，重復報表工作的優(yōu)化等。

以上的這些方向可以分階段、在充分考慮優(yōu)先級和資源投入的基礎上做一個統(tǒng)籌規(guī)劃。

3.現(xiàn)有安全產(chǎn)品的性能考慮

在開啟安全日志分析后產(chǎn)品的資源利用率，比如CPU、內(nèi)存、I/O、存儲的增加是否會影響現(xiàn)有產(chǎn)品輸出內(nèi)容的質(zhì)量。

另外這些安全日志是否可以被讀取到，是否存在技術限制不對外提供接口，這些都是在建設前需要調(diào)研和考慮的問題。如果已經(jīng)有集中日志管理平臺，建議從它入手優(yōu)先獲取數(shù)據(jù)。

注：SIEM和集中日志管理平臺還是有區(qū)別的，SIEM收集和存儲的每條日志應該是更有價值的或者說經(jīng)過初次研判后的日志，用以發(fā)現(xiàn)威脅、取證或者合規(guī)等方面。如果已經(jīng)有集中日志管理平臺，那他與SIEM的使用場景和定位也是需要考慮的。

4.不要試圖一次性將所有可接入的日志源導入SIEM平臺，而忽略思考日志未來產(chǎn)出的價值和后續(xù)跟進，如場景、運營、報告、展現(xiàn)等方面。

建議：圍繞場景展開工作，將安全團隊、合規(guī)團隊、業(yè)務團隊最關心的場景做個優(yōu)先級排序。從那些投入小但展現(xiàn)價值高的場景入手。

比如，安全團隊原來要登錄多個安全平臺排查的問題將優(yōu)先考慮。比如，合規(guī)團隊以往定期關注的報表自動化展現(xiàn)。比如，業(yè)務團隊關心的某個監(jiān)控指標。建設初期充分討論這些場景，以及為了滿足這些場景所需要的日志源。

這些調(diào)研和頭腦風暴是真正有價值，是項目初期成功的關鍵，也能有效的論證商業(yè)產(chǎn)品。會比直接使用開箱即用的場景更具價值，當然這些開箱即用的場景可以作為引發(fā)思路。

5.場景創(chuàng)建

• 把您最關注的各類安全平臺日志威脅在SIEM中呈現(xiàn)(單一策略未做多場景聯(lián)動)，減輕跨平臺監(jiān)控的工作量。
• 建立如上那些有價值的場景，這些場景中的策略明細以最小化滿足的方式接入。比如，不要試圖把殺毒管理控制臺中的所有告警日志都發(fā)送到SIEM平臺，而考慮把未部署的殺毒軟件終端數(shù)量和IP地址引入，或者把離線的殺毒終端信息在SIEM中展現(xiàn)，以便后續(xù)的運營跟進處理。

如果您覺得僅從殺軟管理控制臺的離線數(shù)據(jù)不能判斷，那可以考慮網(wǎng)絡層的數(shù)據(jù)和這臺終端人員是否離職注銷等信息來進一步完善這個“未安裝殺毒軟件”的場景。

雖然這個場景的設計是不合理的，因為殺軟會ping這臺終端是否存活，不一定需要網(wǎng)絡層的日志，人員離職與未安裝殺軟的關系也不是特別大，但是這邊想要表達的核心思想是最小化日志接入，不要試圖把可能與該場景有關的所有日志接入，這樣只會產(chǎn)生大量的噪聲和誤報。只有當現(xiàn)有的日志不滿足場景時才陸續(xù)將可能輔助產(chǎn)生最終效果的日志接入，并陸續(xù)調(diào)優(yōu)。

• 不要試圖一次性調(diào)優(yōu)多條策略。

首先，策略的準確性是需要一定時間驗證和優(yōu)化的，可能是人為模擬觸發(fā)或者真實安全事件的觸發(fā)。 這種觸發(fā)到最終SIEM平臺的告警展現(xiàn)的實時性和誤報可能是需要判斷和調(diào)優(yōu)的。

其次，安全事件的落地閉環(huán)過程中人和流程也是需要去制定和磨合的。正常運營人員在系統(tǒng)、網(wǎng)絡、業(yè)務人員配合的情況下，一天能處理并最終確認的事件也就2-3個，不排除復雜和不能及時反饋的情況。所以SIEM實施過程中人和流程也是需要提前考慮和設計的。

再者，部分場景的策略涉及模型的學習時間，不是部署初期就特別準確的，需要持續(xù)跟進驗證策略的有效性。

• 創(chuàng)建多個臨時監(jiān)控指標(watchlist)，作為黑白名單知識庫參數(shù)，在后續(xù)其他場景的創(chuàng)建中嵌套這些黑白名單庫，以提高研判的準確性和排除誤報。比如從WAF攻擊行為中提取攻擊IP地址，作為黑名單池保存，并與其他攻擊場景或防火墻日志做關聯(lián)，當匹配此黑名單IP池時，判定為高威脅安全事件。再比如，讀取由某業(yè)務系統(tǒng)中產(chǎn)出的白名單用戶列表，與現(xiàn)有的“風險用戶清單”場景做匹配，作為排除指標，以降低告警誤判。
• 如果某些日志源在SIEM平臺中難以處理或者會增加現(xiàn)有SIEM平臺的性能開銷，那可以考慮將這些日志暫時導入到獨立的服務器中，在這臺服務器上使用批處理或者腳本，對數(shù)據(jù)做二次加工后再錄入SIEM中協(xié)同。
• 將一條場景規(guī)則從產(chǎn)生到最終人員落地閉合的運營流程梳理清楚，并與相關協(xié)同人演練順暢后再步入新場景的建設。如果有分公司的情況，建議將此場景在分公司演練到位。這樣做的好處是讓大家知道有這樣一個平臺存在，其次是大家以可接受的工作量來熟練每一個場景。如果在項目初期就把所有的場景投入使用，且沒有相關運營支撐，會讓最終處理人員手忙腳亂，壓力巨大。不但沒有優(yōu)化運營，而且會增加很多額外的工作量，并讓配合人員抵觸此平臺。只有持續(xù)運營優(yōu)化場景調(diào)優(yōu)策略，解決相關方的根本需求，才能吸引更多人參與進來。
• 創(chuàng)建一個場景跟蹤清單，列清楚需求方和目的，創(chuàng)建時間，使用到的日志源，策略優(yōu)先級，策略場景分類，策略階段(調(diào)研、新建、調(diào)優(yōu)、投產(chǎn))，策略的運營處置人，策略更新記錄等。

6.報表和展現(xiàn)

這塊主要是對分析后指標的呈現(xiàn)，過程中需要考慮匯報的對象是管理層、運維、安全、合規(guī)或業(yè)務相關方關心的指標背后帶來的價值。通過數(shù)值、直方圖、餅圖、趨勢圖、百分比圖、TopX等多種角度多種維度對數(shù)據(jù)進行分析呈現(xiàn)，并以不同對象可接受可理解的方式呈現(xiàn)。如果企業(yè)對于SIEM提供商給到的呈現(xiàn)不滿意，想優(yōu)化展示界面，也需要提前考慮從團隊內(nèi)部或者外部招聘前端工程師和UI設計師來完善相關工作。

7.維護工作

成功的SIEM部署需要專業(yè)的人才儲備，一旦有任何威脅告警，將不可避免對發(fā)現(xiàn)的事件進行響應。人員需要配合環(huán)境的變化進行持續(xù)的調(diào)優(yōu)和維護，這些變化包括威脅、合規(guī)要求以及數(shù)據(jù)源采集本身。在項目開始之前您至少需要考慮以下3類人才：

因此，不僅需要有足夠知識的員工來管理和維護SIEM，而且需要為SIEM帶來的額外工作做好心理準備。事件需要被審查和處理，流程需要被制定，還要考慮與其他部門和團隊的協(xié)作。這些都是需要提前準備和思考的而不是找到3名適合的員工就能開展的工作。這個過程中還不排除員工的事假、病假等額外因素，如果需要7*24小時的安全事件監(jiān)控操作，人數(shù)還需要進行翻倍。

最佳實踐：控制項目范圍和聘請外部服務供應商

SIEM是一種有效好用的工具，它能夠使特定的工作和場景更高效的執(zhí)行和展現(xiàn)價值，但它不會完全自己運行。以下2個方面建議可供參考：

• 限制項目范圍

就是在項目開始時控制本次項目的范圍和需要達到的目的，將項目規(guī)模和資源進行可行性匹配。配合實際風險和企業(yè)風險偏好來制定優(yōu)先級，還是圍繞場景、日志源、報表、流程和產(chǎn)出價值去落地項目。并在后續(xù)年份通過二期、三期項目的方式持續(xù)迭代擴展。

• 聘請外部安全服務提供商

如果企業(yè)有一定的規(guī)模及合適的人才，完全可以在分析考慮清楚之后開展建設工作。如果企業(yè)由于缺乏內(nèi)部資源或?qū)I(yè)人才，可以考慮統(tǒng)SaaS化部署+安全管理服務(MSS) 的組合來落地此類項目，通過外部力量幫助企業(yè)顯著提高安全能力，而無需進行大量的軟硬件和人員投入，交付中包含持續(xù)運營和管理，而企業(yè)本身更多的關注安全場景和業(yè)務需求。托管安全服務提供商(MSSP)提供對安全事件的實時監(jiān)控和分析，并通過他們自己的SIEM解決方案來進行日志收集，并應用于報告和調(diào)查。

注：管理安全服務(MSS)是為那些希望更多的減輕網(wǎng)絡安全責任企業(yè)提供的選擇。通過MSS，一個可信的合伙伴將協(xié)助處理公司的部分或全部安全流程，MSS可以在內(nèi)部或遠程進行。公司獲得了MSS合作伙伴的分析人員和運維工程師的經(jīng)驗和技能，他們可以提供從安裝到威脅檢測到響應等系列服務。

8.云上SIEM的思考

近幾年疫情的流行改變了許多企業(yè)的戰(zhàn)略方向，特別是云計算的可擴展性、彈性計算、云上安全組件等優(yōu)勢，讓原來較多不愿嘗試上云的企業(yè)轉(zhuǎn)變?yōu)橹鲃訐肀г疲⑶宜伎荚粕系募軜嫛⒃粕系陌踩⒃粕系倪\維和云原生等問題。SIEM在云上運行您可能需要考慮的問題：

帶寬：

云上SIEM需要一定的帶寬來獲取企業(yè)內(nèi)部數(shù)據(jù)以及訪問云上的用戶界面。如果企業(yè)內(nèi)部沒有足夠的帶寬為基于云上的SIEM提供

它所需要的日志文件和訪問SIEM的用戶界面。那云上的可擴展性和彈性優(yōu)勢將享受不到，反而帶來一些網(wǎng)絡問題，這塊是需要考慮和評估的。

數(shù)據(jù)安全：

雖然SIEM的常見作用之一是合規(guī)和滿足監(jiān)管要求，但在選擇云SIEM解決方案時，也可能有監(jiān)管、數(shù)據(jù)安全、法律方面的限制。

鑒于以上原因很多企業(yè)都在使用混合云管理。就是將企業(yè)內(nèi)部的計算、存儲和服務與公有云中的服務連接起來。混合云允許企業(yè)保留對內(nèi)部敏感數(shù)據(jù)的控制，同時利用SaaS的相關優(yōu)勢。這種設計可以解決許多監(jiān)管方面的問題，并使云上SIEM變的更為可行。

您可以考慮把SIEM部署在私有云中(下圖標紅)，或者部署在云上的專屬云中(下圖標綠)，并通過采集器和云上接口將數(shù)據(jù)同步到一處后再匯總分析。

9.云上SIEM中的角色和責任

對于不想在SIEM上投入太多資源的企業(yè)來說，由托管安全服務提供商(MSSP)來執(zhí)行是一個很好的選擇。但是首先需要清楚的了解角色和責任。這里將用到RACI矩陣來直觀的明確企業(yè)、云SIEM供應商和MSSP之間的關系。

注：誰負責R = Responsible, 即負責執(zhí)行任務的角色，具體負責操控項目、解決問題。誰批準A = Accountable, 即對任務負全責的角色，需經(jīng)過他同意或簽署之后，才能進行。咨詢誰C = Consulted , 擁有完成項目所需的信息或能力的人員。通知誰 I =Informed ,即擁有特權、應及時被通知結(jié)果的人員，卻不必向他咨詢、征求意見。

總的來說，云SIEM供應商更多的職責是初期建設部署和圍繞他們自己產(chǎn)品的功能更新等工作。MSSP更多的職責是中后期的場景優(yōu)化及事件跟蹤處置。企業(yè)在這個模式中更多的是需求的提出和確認決策。

總結(jié)：在SIEM建設初期確認好項目范圍和預期價值。過程中圍繞場景、日志、流程開展推進，將每個場景落實演練到位后才進入新的場景。根據(jù)企業(yè)合規(guī)和資源投入情況，考慮本地數(shù)據(jù)中心或云上SIEM的部署。人員方面需提前規(guī)劃準備或?qū)ふ襇SSP合作伙伴協(xié)助落地。