作者 | 烨陌
來源 | 阿裡技術公衆号
一 SIEM概念及發展趨勢
随着企業數字化轉型的深入推進，網絡安全越來越被企業所重視。為了建構完備的安全防禦體系，企業通常會引入了防火牆(Firewall)、防病毒系統(Anti-Virus System，AVS)、入侵防禦系統(Intrusion Prevention System，IPS)、入侵檢測系統(Intrusion Detection System，IDS)、審計系統等大量安全産品，然而這些安全産品往往各自為政、缺乏關聯，難以形成有價值的、全面系統的安全态勢分析報告，也就難以應對複雜多變的安全威脅。
安全資訊和事件管理 (SIEM，Security Information and Event Management) 正好可以滿足這方面的需求。SIEM可以收集和存儲來自各種網絡、安全裝置等日志和事件，并能夠持續分析接入的資料，用以持續地進行威脅檢測和合規性檢測，幫助提升企業威脅響應能力；另外，SIEM也可以綜合所采集的安全日志和事件，提供系統全面地安全報告，以便企業完整地評估系統風險。
1 SIEM簡介
Gartner在2021年度的《SIEM市場魔力象限分析（MQ）報告》中将SIEM定義為滿足以下客戶需求的解決方案：
- 實時收集安全事件日志和telemetry資料，用于威脅檢測和合規性檢測；
- 實時并持續分析接入資料，以檢測攻擊和其他感興趣的活動；
- 調查安全事件以确定其潛在的嚴重性和對業務的影響；
- 報告上述活動；
- 存儲相關事件和日志。
2 SIEM發展趨勢
與自然界事物的發展規律類似，SIEM也有一個從簡單到進階的發展過程。
早期的日志管理系統
日志采集的需求由來已久，在計算機領域，日志一般用于記錄計算機作業系統或應用程式運作狀态或者外部請求事件。SIEM産生之前，安全場景主要是利用一些日志管理工具收集來自各種網絡裝置的日志，并進行統一存儲，以便當異常事件發生時，可以進行事後的日志審計。
SIM和SEM
到了上世紀90年代末，日志分析的需求逐漸強烈，開始出現了SIM（Security Information Management，安全資訊管理）和SEM（Security Event Management，安全事件管理）兩種技術。在SIM和SEM發展的早期，兩者是分開的，比較公認的了解是：SIM注重安全事件的曆史分析和報告，包括驗證分析；而SEM則更關注實時事件監控和應急處理，更多的強調事件歸一化、關聯分析。
SIEM
随着企業在IT建設上的持續投入，企業擁有了更多的網絡裝置和安全裝置，會有更加複雜的網絡環境，同時對企業安全也越來越重視。随之而來的是更多的安全資料需要處理，并且希望能夠從衆多資料中提取出威脅事件和安全情報，用于達到安全防火或合規審計的需求。之前單一的基于日志分析的模式不在适用，需要一種新型的工具滿足安全分析場景的需求，SIEM的出現正好比對上這些需求。
SIEM可以收集企業群組織中所有IT資源（包括網絡、系統和應用）産生的安全資訊（包括日志、告警等）進行統一的實時監控、曆史分析，對來自外部的威脅和内部的違規、誤操作行為進行監控、審計分析、調查驗證、出具各種報表報告，達到IT資源合規性管理的目标，同時提升企業群組織的安全營運、威脅管理和應急響應能力。
SIEM AS A SERVICE
随着企業數字化轉型的深入，企業往往需要有更進階的安全分析的能力，同時SIEM也變得越來越複雜，想要掌握整套的SIEM系統使用能力要求也越來越高。托管式的SIEM出現，很大程度上降低了本地部署的運維成本，提供了更多開箱即用的功能，可以一定程度上降低SIEM的使用門檻，助力企業的安全能力建設。
SIEM AS A UTILITY
未來SIEM可能會作為網絡裝置的基礎功能，作為一個内置工具存在。目前越來越多的雲廠商開始将SIEM方案内嵌到自家的雲産品中，作為一個基本的功能與雲産品基礎能力打包售賣。
3 SIEM如何保護企業組織安全？
識别未知威脅：SIEM可以通過針對日志或者安全事件提供實時的資料監控能力，并結合人工智能、威脅情報能力，幫助企業發現潛在的安全風險。
威脅追本溯源：因為安全事件的發生往往會有個很長的持續周期（例如資料庫拖庫的表象是一次資料庫拖庫行為，背後可能隐藏着更早之前的某個時間的跳闆機密碼的洩露），SIEM提供了對于曆史資料的分析能力，能夠長達幾個月甚至更長時間内協助企業發現安全事件發生的蛛絲馬迹，還原事件現場。
支援自定義審計：通過SIEM提供的開放的規則引擎，企業可以根據自身的業務場景配置一些持續的審計監控規則，實時監控網絡安全。
及時威脅響應：當威脅事件發生時，監控規則會将探測到的異常通過告警等形式通知給相關人員及時進行響應處理，形成問題閉環。
二 數字化時代企業安全面臨的全新挑戰
1 企業數字化帶來了新的安全挑戰
傳統的網絡安全架構理念是基于邊界的安全架構，企業建構網絡安全體系時，首先要做的是尋找安全邊界，把網絡劃分為外網、内網等不同的區域，然後在邊界上部署防火牆、入侵檢測、WAF等産品。然而這種網絡安全架構是基于内網比外網更安全的假設建立起來，在某種程度上預設了對内網中的人、裝置和系統的信任，忽視加強内網安全措施。不法分子一旦突破企業的邊界安全防護進入内網，會像進入無人之境，将帶來嚴重的後果。此外，内部人員100%安全的假說也是不成立的，我們可以從《内部威脅成本全球報告》裡看到，不管是内部威脅的數量，還是成本從2018年到2020年都有大幅的提升。
此外，随着雲計算、大資料、物聯網、移動辦公等新技術與業務的深度融合，網絡安全邊界也逐漸變得更加模糊，傳統邊界安全防護理念面臨巨大挑戰。在這樣的背景下，零信任架構（Zero Trust Architecture, ZTA）應運而生。它打破傳統的認證，即信任邊界防護、靜态通路控制、以網絡為中心等防護思路，建立起一套以身份為中心，以持續認證、動态通路控制、審計以及監測為鍊條，以最小化實時授權為核心，以多元信任算法為基礎，認證達末端的動态安全架構。
我們可以看到，零信任政策下，監控無邊界、持續監控的需求也給SIEM提出了新的挑戰。
2 數字化對工程師的挑戰
随着DevOps的逐漸深入人心，工程師的開發職責也逐漸發生了變化，開發、測試、運維逐漸成為趨勢。但是DevOps模式下，安全産品、安全能力其實是外置的，在整個軟體生命周期中安全防護隻是安全團隊的責任，在開發的最後階段才會介入。然而在DevOps有效推進快速疊代的今天，過時的安全措施則可能會拖累整個開發流程，由此催生出了“DevSecOps”的概念。
DevSecOps認為安全防護是整個 IT 團隊的共同責任，需要貫穿至整個生命周期的每一個環節。DevSecOps更多關注的是過程安全，這種安全前置的理念，可以把安全植入到開發、測試、部署的各個環節，從源頭上屏蔽掉一些風險。
DevSecOps分為了如下幾個階段，每個階段都有自己的安全要求。左邊的“Dev 段”，聚焦軟體開發過程的安全保障；右邊的“Ops 段”，聚焦軟體運作時安全。具體階段如下：
- Plan+Create 階段，從宏觀上可以認為是在進行軟體的安全設計與開發前準備，更注重安全規則的制定、安全需求分析、軟體設計時的安全考慮；
- Verify+Preproduction 階段，即是對開發階段進行安全保障，可以進行 AST、Fuzz、SCA 等；
- Predict+Respond 階段，可以了解為軟體的在網安全監測，比如監測和響應安全事件等；
- Configure+Detect 階段，可以了解為對應用程式的運作時的安全保障，比如容器和基礎設施安全、RASP、WAF 等。
我們可以看到，“Ops 段”涉及的威脅探測、應急響應、威脅預測與SIEM的特性是比較符合的，為了應對DevSecOps中安全融合、快速疊代的要求，對SIEM也提出了輕量化、便捷化的需求。
3 SIEM的全新挑戰
基于上述的趨勢，我們可以看到零信任（從不信任，始終驗證）理念、DevSecOps都給SIEM提出了新的發展要求。新一代的SIEM需要滿足零信任下無邊界持續動态監控的訴求，就需要監控更廣泛的資料，并提供更強的關聯分析能力。為了提升DevSecOps的效率，就需要做的更輕量，作為一個基礎的工具與DevSecOps進行融合，提供更多開箱即用的功能。同時，與可觀測平台一體化融合也是一個發展的趨勢。
4 雲上一體化SIEM平台
為了适應這些挑戰，我們認為一個雲上一體化的SIEM平台需要具備如下特征：
- 平台能力：
- 對包括日志、Metric、Trace和事件的資料提供統一的采集、存儲能力。
- 在統一存儲的基礎上，提供統一的資料處理、分析，并且具備機器學習分析能力。
- 基于可視化的安全态勢，告警檢測事件管理能力。
- 業務場景：基于統一的平台上層業務，支撐上層業務方（開發營運、監控、安全、使用者營運）。
- 生态對接：可以對接上下遊系統的安全生态支援。
三 Cloud SIEM核心技術及行業方案
1 SIEM的核心技術及挑戰
要實作一個SIEM系統，需要經過采集（Collection）-> 探測（Detection）-> 調查（Investigation）-> 響應（Response）四個階段。四個階段面臨的挑戰如下：
- 采集：如何将資料便捷接入的問題，以及如何低成本存儲。
- 探測：如何通過各種資料的關聯分析，捕獲未知的威脅。
- 調查：如何審計安全事件及還原威脅過程。
- 響應：如何将安全事件通知給使用者的能力。
2 常用的行業方案
Splunk的思路是基于“将資料轉化為一切(Data-to-Everything)”的平台，提供了一整套融合了SIEM、UEBA、SOAR的完整解決方案。
Elastic以開源為基礎，通過Logstash、Elasticsearch、Kibana組合奠定了資料的基本采集、分析、可視化能力。其中，Logstash作為一個日志聚合器，可以收集和處理來自幾乎任何資料源的資料；Elasticsearch是存儲引擎，用于解析大量資料；Kibana作為可視化層，用于可視化處理及問題分析。Elastic 7.14 版釋出了首個免費開放的Limitless XDR，能夠在一個平台中提供一體化的 SIEM 和 Endpoint Security 功能。
Exabeam 的 SIEM 解決方案可作為 SaaS（Exabeam Fusion SIEM）使用，也可用于混合、聯合部署。它包括 Exabeam資料湖、進階分析、威脅捕獲、實體分析、案例管理和事件響應。基于定制部署的子產品化架構，使用者可以靈活購買。Exabeam 的機器學習 (ML) 驅動的使用者和實體行為檢測，能為使用者提供風險評分和自動的上下文富化能力。
從上述的行業方案我們可以看出SIEM廠商普遍是平台化、SaaS的發展思路。
3 SIEM核心特性及落地方案
基于上文提到的SIEM平台化的思路，我們可以看到SIEM系統一些核心的特性（左圖），而右圖是我們最佳實踐的落地方案。
四 建構Cloud SIEM方案的最佳實踐
接下來我們将重點闡述建構Cloud SIEM方案一些最佳實踐，主要從如下四個方面展開。
- 廣泛的資料接入：資料采集（特别是雲上場景：跨賬号、多雲）、處理、存儲能力。
- 統一的查詢分析能力：互動式的查詢分析文法、ML算法支援、可視化分析能力。
- 威脅探測和響應：使用内置告警規則和自定義規則進行威脅探測，将發現的威脅事件通知給使用者，并能夠進行事件管理。
- 安全生态內建：如何與第三方平台內建。
1 廣泛的資料接入
建構Cloud SIEM方案，首先要解決的問題是海量資料的統一接入問題。然而目前行業中涉及的接入方案衆多，例如日志可能會使用logstash、FluentD等，名額會使用Prometheus等。這也造成了資料接入管理的諸多痛點：
- 運維成本高：完整的資料接入需要數個軟體的協同，進而也帶了極高的運維成本。
- 學習成本高：每個軟體都有自己的使用插件及配置規則，學習成本非常高。
我們的方案是建立了标準化的資料接入方式，支援SDK及Agent采集兩種方式，可以友善的将各類資料（日志、Metric、Trace、Meta）統一地采集到統一存儲系統中。除了支援伺服器與應用日志采集外，對于開源軟體、标準協定也有很好的支援。最主要的是，針對阿裡雲雲原生場景提供了一鍵式的采集方案，例如，日志RDS審計日志、K8s審計日志等；并且與阿裡雲資源目錄內建支援跨賬号采集的能力（因為很多企業可能會有多個賬号，每個賬号對應一個部門的業務）。
Cloud SIEM場景下，往往需要采集多種資料源的資料（格式可能比較雜亂），同時也有長時間跨度、海量資料的分析需求，而我們的做法是提供了一套低代碼、可擴充的資料加工服務，通過Schema On Write的方式提前進行資料規整，能夠為後續的分析處理提供很大的便捷。
資料加工服務可以對結構化或非結構化的日志進行實時的ETL處理。該功能目前包含200+算子，廣泛應用于資料規整、資料聚合、富化、分發等場景。對于安全場景，資料加工也有很好的安全類算子支援。例如，資料加工提供的資料脫敏算子，可以有效地減少敏感資料在加工、傳輸、使用等環節中的暴露，降低敏感資料洩露的風險，保護使用者權益。常見脫敏場景有為手機号、銀行卡号、郵箱、IP、AK、身份證号網址、訂單号、字元串等敏感資訊脫敏。
2 統一的資料查詢分析能力
Cloud SIEM系統一個重要的能力就是對采集到的資料，進行實時的合規監控分析，支援對曆史資料的合規審計，對來自外部的威脅和内部的違規進行審計分析。但是，安全威脅的方法往往是一個逐漸的過程，可能需要幾個月或更長的時間才會真正暴露出來；此外，安全威脅可能需要多種資料的關聯分析才能發現。
為了應對這些挑戰，我們将日志、名額、Meta等資料全部接入到統一的存儲中，在此之上，我們建構了一套統一的查詢分析引擎，用于支撐查詢分析、可視化、監控告警、AI 等上層能力。
基于統一的存儲，我們建構的統一的查詢分析引擎，以标準 SQL 為基礎，進行了SQL 函數擴充，并融合了 PromQL，進而讓不同的資料之間進行聯合查詢也變成了可能。
SLS SQL = Search + SQL92（Agg，WIndow，GroupBy...）+ PromQL + ...
以下就是一個複雜分析的例子：
- 我們可以通過标準 SQL 語句對日志進行分析。
- 還可以通過 PromQL 擴充的 SQL 函數對名額資料進行分析
- 還可以通過嵌套查詢，對名額資料的分析結果進行再聚合
- 此外還可以再通過機器學習函數，給查詢和分析賦予 AI 的能力
雖然不同階段的資料産生自不同的系統，也有着不同的格式，但是由于它們的存儲和分析是一緻的，我們可以非常輕松地實作統一的安全态勢及安全事件監控。
同時，提供了大量基于AI的巡檢、預測、聚類、根因分析等算法，以SQL/DSL函數的形式向使用者提供，在人工分析和自動巡檢告警中都能使用到。
3 威脅探測與響應
通過上文提到的統一的資料接入、統一的查詢分析能力，我們可以做到對安全威脅的基本的探測能力。但是要建構完備的監控體系，接下來就要解決如何持續監控的問題。基于這個問題，我們開發了一套一站式智能運維告警系統。它提供對日志、時序等各類資料的告警監控，亦可接受三方告警，對告警進行降噪、事件管理、通知管理等。
我們提供了超過數百個内置告警規則，開箱即用并持續增加中。這些規則庫有覆寫了CIS（覆寫了賬号安全、資料庫安全等）和安全場景的最佳實踐，使用者僅需開啟對應規則，即可享受到全天候的安全保障。
當告警規則探測到異常發生時，需要盡快的将威脅事件通知給相應的開發人員。我們對接了豐富的通知管道，便于威脅事件的全方位觸達。
- 多管道：支援短信、語音、郵件、釘釘、企業微信、飛書、Slack等多種通知管道，同時還支援通過自定義 Webhook 進行擴充。同一個告警，支援同時通過多個管道、每個管道使用不同的通知内容進行發送。例如通過語音和釘釘來進行告警通知，既可以保證觸達強度，又可以保證通知内容的豐富程度。
- 動态通知：可以根據告警屬性動态分派通知。例如：測試環境的告警，通過短信通知到張三，并且隻在工作時間通知；而生産環境的告警，通過電話通知到張三和李四，并且無論何時，都要進行通知。
- 通知更新：長時間未解決的告警要進行更新。例如某告警觸發後，通過短信通知到了某員工，但是該問題長時間未被處理，導緻告警一直沒有恢複，此時需要通知更新，通過語音的方式通知到該員工的上司。
安全事件發生後，如果不及時處理或不慎遺漏都會造成更大的安全風險擴充。是以，一定要建立完備的回報機制，将安全問題處理形成閉環。基于這個問題，我們提供了安全事件管理中心，便于使用者全局檢視安全事件，并進行相應的管理動作。當開發或安全人員接收到安全告警事件通知後，可以登陸安全事件管理中心進行事件的确認、處理人的指派、處理動作記錄等操作。
最後，我們提供了安全态勢大盤，幫助使用者全局了解安全事件、安全态勢，便于進行告警鍊路檢視及排錯使用。此外，報表還可自由擴充。
4 安全生态內建
現代企業上雲後，有時會将業務部署在多家雲廠商上，那麼安全場景可能就涉及多家雲廠商資料的同步問題。我們提供了與第三方SIEM方案（例如Splunk）對接的方式，以便確定阿裡雲上的所有法規、審計、與其他相關日志能夠導入到使用者的安全運維中心（SOC）中。
五 總結
我們總體上介紹了SIEM的背景趨勢、以及數字化時代新的挑戰，并且介紹了建構雲上SIEM的最佳實踐。
另外，我們可以看到雲上SIEM也在朝着平台化、SaaS化的方向發展，并且不斷的優化以适應新的業務挑戰。
參考
- 新一代SIEM與SOAR的技術對比： https://www.secrss.com/articles/19340
- 避坑指南：頂級安全專家談SIEM如何選型： https://www.aqniu.com/learn/68347.html
- Gartner：2021年SIEM (安全資訊與事件管理) 市場分析： https://www.secrss.com/articles/34092
- 什麼是 DevSecOps?： https://www.redhat.com/zh/topics/devops/what-is-devsecops
- 業務安全與 DevSecOps 的最佳實踐： https://blog.51cto.com/u_15127503/2657790
- 10 Best SIEM Tools for 2021: Vendors & Solutions Ranked： https://www.comparitech.com/net-admin/siem-tools/
- 10 Must-Have Features to be a Modern SIEM： https://www.exabeam.com/siem/next-gen-siem/
基于ELK+Flink日志全觀測最佳實踐
分享内容：1. 日志全觀測場景及技術痛點剖析；2. 基于ELK+Flink的場景化方案能力解讀；3. 日志全觀測解決方案客戶案例解析。
點選這裡,檢視詳情！