從被動響應到主動感知：雲原生自動化應急響應實戰
最近參加了Xcon2020安全技術峰會，趁熱打鐵跟大家聊聊雲平臺上的原生自動化應急響應。
隨著雲端計算的大規模普及，公有云的應急響應趨勢已逐漸從"被動響應"發展為"主動感知"。一方面雲端計算的靈活性、可擴充套件性和價效比吸引了更多的企業上雲；另一方面雲端計算的網路開放，資源共享特性也給網路攻擊提供了更為廣闊的土壤。
傳統單點對抗的應急響應已無法滿足雲時代的複雜攻擊形態和規模。如何在攻擊前做好預防措施，攻擊後快速有效的自動化溯源取證和風險收斂已經成為雲時代應急響應技術的核心競爭力。
應急響應的發展
IDC時代企業環境部署應用多以linux和windows為主，這一階段事件響應檢測方法論多以單點對抗為主。隨著雲端計算的普及的普及，越來越多的企業上雲，企業環境和資產形態已由傳統的實體化向虛擬化和多樣化轉換，雲端計算的靈活性、可擴充套件性和價效比吸引了更多的企業上雲，同時也帶來了新一輪的安全風險。

IDC時代的資產形態以windows和Linux實體機為主，數量在百臺以下。其特點是：成本高、不易擴充套件、維護和恢復比較複雜，這一階段的應急響應方法論一般為被動式單機檢測。雲時代的資產形態則更加多樣化和多元化。數量更是有千臺甚至以上。其特點是：低成本、易擴充套件、資產數量多、安全責任共擔。雲端計算的提供便利的同時，其規模也帶來很大安全運營成本。對於安全事件應急響應的自動化溯源取證已經成為必然趨勢。






雲上應急響應簡述
安全行業的小夥伴應該都明白一個道理，那就是沒有絕對安全的系統。而當系統被入侵和破壞時，不可避免的會導致業務中斷。應急響應的核心價值就是在安全事件突發時，快速有序的處理，最大限度的快速恢復業務和減少損失。因此響應和恢復速度將是雲上應急響應的核心競爭力。
以上是我總結的雲上應急響應的現狀，從圖中可以看到雲租戶的訴求和運營商的交付方案存在很大的不對等，這也是雲上應急的主要矛盾。大量的差評工單和投訴都是因為這個產生的。這也是客戶和運營商面臨的一個重大難題。
既然是難題，難在哪裡？從圖中我們可以看到有六大困難，並get到三個關鍵點：海量事件的困擾，分析投入大、人員要求高；證據完整性的挑戰，證據提取和保全難度大；責任共擔模型便捷模糊導致權責不清晰。
如何解決以上提到的困難？透過上圖我們可以看到雲平臺的主要解決方案是透過雲平臺基礎設施和自動化運維體系構成。透過SOC中整合的雲產品日誌和全網蜜罐資料進行智慧化分析解決雲主機自身無日誌或日誌丟失問題、透過映象、快照和自動化工具突破網路複雜、應用場景複雜、責任邊界模糊、取證苦難和資料量大的困難。雲時代的原生自動化應急響應
業內通常使用的PDCERF方法學（最早由 1987 年美國賓夕法尼亞匹茲堡軟體工程研究所在關於應急響應的邀請工作會議上提出），將應急響應分成準備（Preparation）、檢測（Detection）、抑制（Containment）、根除（Eradication）、恢復（Recovery）、跟蹤（Follow-up）6個階段的工作。從上圖可以看到一次完整的應急響應需要做的事情很多。而業內的提到應急響應一般僅進行到第二個階段，比較好的運營商會進行到第四個階段。無論第二還是第四階段都是建立在解決問題的角度，無法進行持續性運營和方案進化。常規的應急響應對人力和能力的要求很高。且無法解決上邊提到的六個難點問題。為了更好的在雲上做好應急響應。騰訊安全雲鼎實驗室結合多年的雲上運營和實踐經驗設計出雲原生自動化應急方案。
此方案遵守三大原則：







• 整個系統執行環境和資源均在使用者vpc內
• 操作由使用者賬號發起/使用者授權
• 所有證據資料和分析結果均保留於使用者vpc空間
整個方案分為兩大部分：被動響應和主動發現。本方案採用CS架構，結合雲平臺多年運營經驗、SOC、全網蜜罐和威脅情報的資料進行自動化智慧分析。從而幫助應急響應人員在最短時間內定位入侵途徑、完成電子取證和輸出應急策略。被動溯源分為三個階段：
第一階段：當客戶發生入侵事件後，透過自助授權後會啟動溯源主機中的諦聽系統。諦聽系統會申請映象授權，當授權透過後，會建立臨時API KEY並根據要求進行快照或映象。當映象打包完畢會進行映象掛載或者載入快照進行常規溯源。常規溯源會覆蓋九大檢測場景。如果溯源結束會輸出報告和證據；
第二階段：如果溯源失敗。會自動拉取SOC的行為檢測資料、全網蜜罐的入侵還原資料以及威脅情報的IOCS資料進行智慧化資料分析。分析後會輸出報告和證據；
第三階段：如果溯源結束，將會輸出相關IOCS到log中，輸出未知檢測告警，透過人工進行最終溯源。
主動溯源由SOC、蜜罐、威脅情報構成：SOC的行為檢測資料會實時輸出異常告警，並提供告警溯源；全網蜜罐進行入侵資料採集，還原資料入侵路徑，並輸出IOCS進行特徵匹配，輸出溯源結果和報告；根據威脅情報的IOCS資料進行特徵匹配，輸出溯源結果和報告。
接下來我們透過被動關係和主動關係構建來看看整個資料是如何關聯和分析的。
上圖展示了整個溯源方案的被動關係構建圖譜:透過入侵時間將惡意命令、服務、登入日誌、服務日誌、程式網路等資料關聯起來，並透過演算法、邏輯和入侵特徵判定入侵途徑。
主動關係的構建透過SOC和蜜罐資料來完成：SOC流量日誌和程式日誌透過域名或者IP等進行關聯；服務指紋和檔案/木馬特徵透過基線和木馬行為進行特徵關聯；SOC和蜜罐資料透過聚類校驗和迴歸驗證判斷入侵行為。
對於被動檢測和主動檢測無法覆蓋的未知入侵方式、檔案和行為將會以日誌的方式列印出來。透過檢視日誌可以得知雲安全產品和溯源工具的檢測能力等。從而針對性的進行改進，持續進化自身，驅動和完善雲安全產品。運營案例分享接下來我們透過案例來看看整套方案的一個應用效果，這裡展示的是資料加密勒索的應急分析案例。
首先，溯源主機上的諦聽客戶端經過特徵分析成功匹配到入侵方式、入侵時間和相關檔案證據鏈；
接著，諦聽服務端經過資料聚合分析進行時間排序，從而成功輸出入侵鏈路和感染路徑；
最終生成整個證據鏈和分析結論。從上圖可以看到完整的分析流程。雲上運營效果展示
上圖充分展示了方案實施後的一個運營效果。
以上的就是本次要分享的雲原生自動化應急響應方案，此方案透過與雲平臺基礎設施相結合，利用大資料智慧化分析和自動化手段有效的解決了應急響應中的三大難題。希望本次分享可以幫助大家做好雲上的應急響應。
相關文章
- XCon安全焦點：雲原生自動化應急響應
- RSA 創新沙盒盤點| Vulcan Cyber：化被動為主動的雲端漏洞響應自動化平臺
- 【應急響應】Windows應急響應入門手冊Windows
- Reactive Spring實戰 -- 響應式MySql互動ReactSpringMySql
- Reactive Spring實戰 -- 響應式Kafka互動ReactSpringKafka
- Reactive Spring實戰 -- 響應式Redis互動ReactSpringRedis
- windows應急響應(二)Windows
- 應急響應命令（Linux）Linux
- Linux應急響應排查Linux
- 什麼是應急響應?網路安全應急響應體系的要素！
- Windows應急響應小結Windows
- Linux應急響應小結Linux
- 應急響應- Linux入侵排查Linux
- 應急響應-webshell查殺Webshell
- 應急響應靶機-3
- 應急響應靶機-4
- 應急響應:日誌分析
- 5.28應急響應思路流程
- 什麼是應急響應?網路安全應急響應的物件是什麼?物件
- 為什麼需要應急響應?網路安全應急響應需要做什麼?
- Fiddler如何自動修改請求和響應包
- OpenKruise v1.0：雲原生應用自動化達到新的高峰UI
- windows伺服器應急響應Windows伺服器
- 看雪應急響應服務
- Windows應急響應-個人整理Windows
- 應急響應知識彙總
- 網路安全事件應急響應事件
- Flutter:如何響應互動事件？Flutter事件
- 【網路安全】組織為什麼需要應急響應?應急響應需要做什麼?
- jmeter 介面自動化連載 (8)- JsonPath 表示式提取響應JMeterJSON
- 自動化響應要循序漸進 不能一蹴而就
- Django 從啟動到請求到響應全過程分析-入門版Django
- 『言善信』Fiddler工具 — 10、Fiddler自動響應器（AutoResponder）的應用
- Vue.set()實現資料動態響應Vue
- Linux應急響應（一）：SSH暴力破解Linux
- 記一次安全應急響應事件事件
- 玄機應急響應靶場集合WP
- 玄機應急響應-第二章