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

SIEM定義

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

SIEM技術成熟度

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

知識點補充：

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

SIEM價值體現

1.外部驅動

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

2.內部驅動

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

領導層：

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

運維層：

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

業務層安全：

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

SIEM投入產出

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

SIEM架構

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

1.日志采集

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

2.范式化

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

3.事件過濾歸

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

4.關聯分析

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

5.告警

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

6.安全事件運維

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

7.可視化展現

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

SIEM關鍵技術指標

• 底層數據的收集和管理

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

• 架構和部署

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

• 分析檢索

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

• 異構產品協作

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

• 易用性

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

• 技術棧

產品各模塊實現所使用的技術棧是否穩定、安全、主流等也是需要進行考慮的問題。

• 實施人員

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

SIEM建設建議

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

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

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

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

威脅類：

更多的是企業安全團隊優先考慮的問題，可能是現有安全產品和系統日志層面的組合，發現互聯網側和內網側的可疑攻擊風險，做的更好的可以結合威脅情報和ATT&CK框架，觀察和發現攻擊者的TTP(技術、戰術和過程)。

合規類：

更多的可以和內部合規團隊溝通，將他們的審計要求體現在輸出中，如防范內部人員數據泄露、運維人員異常操作等。

業務類：

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

以上的這些方向可以分階段、在充分考慮優先級和資源投入的基礎上做一個統籌規劃。

3.現有安全產品的性能考慮

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

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

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

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

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

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

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

5.場景創建

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

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

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

• 不要試圖一次性調優多條策略。

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

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

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

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

6.報表和展現

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

7.維護工作

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

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

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

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

• 限制項目范圍

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

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

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

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

8.云上SIEM的思考

近幾年疫情的流行改變了許多企業的戰略方向，特別是云計算的可擴展性、彈性計算、云上安全組件等優勢，讓原來較多不愿嘗試上云的企業轉變為主動擁抱云，并且思考云上的架構、云上的安全、云上的運維和云原生等問題。SIEM在云上運行您可能需要考慮的問題：

帶寬：

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

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

數據安全：

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

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

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

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

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

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

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

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