0x00 概述
如今年（2021）七月Gartner 發布《Hype Cycle for Security Operations, 2021》（2021安全運營技術成熟度曲線），漏洞管理已經成為安全運營中較為成熟的子領域，可以說一切安全運營活動的開始幾乎都是從漏洞管理開始的，是安全工作中的基礎也是重要組成部分。
從合規方面，今年工業和信息化部、國家互聯網信息辦公室、公安部發布的《網絡產品安全漏洞管理規定》也對網絡產品提供者和網絡運營者提出了明確的要求，企業需要擴充原有合規清單來滿足監管要求。（附：官方解讀）
0x01 漏洞管理的三層架構
1、底層安全基建
工欲善其事必先利其器，漏洞管理也不例外，一個好用的安全管理平台，能減少不少重復人力勞動，提高安全運營效率；另一方面，要想將發現的安全問題及時給到業務側修復滿足安全SLA，資產管理也必不可少。以上兩個主要部分就像是漏洞管理的基座。
1.1 安全管理平台
為什么不稱漏洞管理平台而是安全管理平台，因為漏洞管理是安全運營工作的一部分，一個整合了安全運營各工作環節的集中處置平台更利於提高工作效率。
安全管理平台通常具備如下功能模塊：
-
全量報警管理
來自外部報告（例如SRC、CNNVD等其他外部平台報送）、內部安全能力發現，如掃描器、HIDS、流量監測、蜜罐等產生的報警。每個報警源模塊低耦合、可插拔，易於擴展。 -
支持漏洞全生命周期管理
來自眾多渠道的安全報警在經過自動/人工研判分析后，需要對真正需要關注的漏洞進行管理，通常是以工單等自動化流程形式，將安全問題分發至業務線，包含了漏洞分發、業務側修復、修復后安全側確認、直至關閉/打回工單等一系列操作。
-
漏洞知識庫
包含常規漏洞的漏洞描述、風險/危害描述、修復方案等，一方面是減少安全側重復填寫這些信息、另一方面是賦能業務側。 -
權限管理
安全管理平台通常具有諸多功能模塊，因此做好權限的分類分級是十分必要的，可以是基於功能模塊的、或是基於角色的，可以參考RBAC模型。 -
和其他平台/流程的打通
主要用於安全卡位和數據同步需求的場景，例如研發需求管理、域名/服務上線、上線前提測等。 -
支持開放API
基於提高安全效率考慮，可以開放第三方API給安全內部甚至業務側，例如批量處理場景、以及和其他（安全）平台聯動場景等。 -
數據分析和展示功能
不管是安全側還是業務側都有數據分析的訴求。
對於安全側，定期的數據分析和統計是必要的，常見的例如dashbord頁面，實時展示不同統計維度、多種漏洞數據情況，同時漏洞運營的監控指標也可以在這個頁面實時顯示，便於運營同學及時發現問題。
為什么在業務側也需要做數據分析，一方面是業務真的有這種訴求（這是安全意識較高的業務），他們希望了解每季度甚至每月對體系內部的安全風險情況；另一方面從安全的角度，讓業務側能看見這些“觸目驚心”的漏洞數據，也是警示和提醒。
1.2 資產管理
安全問題的處理自然離不開業務部門的參與，安全漏洞更需要細粒度到資產屬主、定位到人，因此需要具備公司各類資產的全量接口，如：域名、IP、主機名、容器名、實例名等，以及各類資產之間的映射關系查詢，以確保安全問題定位的准確性和實效性。除了上述提到的常見類型資產，指紋庫、第三方組件庫的建立也是很必要的，尤其是當fastjson、struts 2這類安全漏洞爆發時，如何在快速應急也是對安全的考驗。
由於資產的動態性，內部梳理是一部分，也需要外部視角的資產探測來做補充，也正是由於資產動態變化這個特性，這往往也是實際工作中的難點和痛點。
2、流程&機制
在平台建設的基礎上，如何讓整個系統良好的運轉起來，是第二個部分——安全流程與協同機制需要關注的。
2.1 確保閉環
發現問題不是目的，如何解決問題降低安全風險才是最終目的。忽略漏洞修復結果的追蹤，缺少標准化的流程來對漏洞的修復狀態進行持續的追蹤管理，將導致修復周期長、無法進行閉環跟蹤。
對於高、中、低不同等級的漏洞有不同的修復優先級和時效性要求，安全平台以工單形式自動化將問題下發至業務，通過郵件、IM、短信等通知渠道將工單狀態的變更實時同步至業務和安全，若在規定時間內未修復還會將安全問題逐級上升至業務側管理角色，督促整改，確保安全問題處置的時效性保證閉環率。此外，定期的數據統計和分析也是必不可少的，可以發現流程和機制上的gap點，及時改進。
2.2 協同機制
由於雙方視角和安全認知不同，如何讓業務方重視安全問題、配合安全及時修復也是一個難題，“從上至下”的推進思路一般來講會比“至下而上”更加事半功倍。
首先是安全制度層面，明確各類資產、虛擬資源的安全職責，出了安全問題誰來擔責（安全制度一定要經過高層review確認和背書，具備權威性）。
明確接口人機制，在每個業務體系設立安全負責人、安全接口人角色（也需要在制度層面達成一致），有職責和義務配合安全，牽頭推進該業務體系安全問題的處理。
OKR協同機制，將安全任務拆解至業務的OKR里（前提也是需要溝通達成一致），形成“契約”后讓業務能主動推進。
對於頻繁出現問題的業務線，可以建立安全協作專項，專注於某類風險集中治理和收斂。
3、精細化運營
3.1 安全review
針對外部報告的各種漏洞、情報，甚至是一次突發的應急事件、紅藍對抗等，安全需要對內部各能力線進行審視，內部安全能力是否有覆蓋、是否該覆蓋、是否能覆蓋、資產是否有遺漏、安全能力是否存在gap點、安全流程是否存在改進空間等，需要不斷優化迭代內部的安全能力，不斷提高縱深防御水平。
3.2 風險分析
漏洞管理起源於漏洞，但絕不止於漏洞。從一個安全漏洞可以深挖的東西很多，如：業務邏輯業務形態是怎樣的，他們為什么會出現這類問題，在現有安全需求下出現這類問題是否合理，安全能力還能做什么，發生這個問題的根因是什么、以及背后潛在的可能風險面等等，可以更加發散的來看。
基於以上兩點，舉個簡單的例子：
比如業務側被發現存在一個fastjson某個版本的RCE漏洞並且被getsehll了，從這個問題知道業務側代碼大概率是使用JAVA的，那么現在安全能力是否有定期的在進行掃描，是否有被掃描到，如果有被提前掃描到，那么業務側為什么當時沒有修復，是漏洞信息未觸達業務還是業務不會修、不能修；
如果內部沒有提前掃描出來，那么安全就需要反思排查了，是組件庫/指紋庫/POC 沒覆蓋、不准確還是壓根這台機器就不在我們的資產庫里；
除了掃描的問題，被反彈shell了，websehll檢測、HIDS是否有報警，如果沒報警是為什么，機器不覆蓋還是規則不覆蓋還是什么其他原因，若是有報警，為什么安全側未提前發現，報警功能是否還正常、報警處理流程是否不夠高效導致處理滯后....
從業務側來說，是測試機還是開發機，測試機嚴格講是不允許部署在外網的，這說明業務側開發部署上線流程不規范，至少是存在安全隱患的；
從發現的這一台機器來看，業務側是否還有別的部署了該版本fastjson的機器，除了fastjson其他JAVA類的組件是否還應該排查；
從整個公司范圍來說，單個業務出現這類case，其他業務是否也會有，是否需要進行針對性的排查.........
3.3 數據分析
精細化運營少不了對數據的分析解讀，對安全來說需要定期查看數據、指標，是否在閾值范圍內，近期漏洞數量/類型變化情況，安全是否需要采取新的控制措施；各業務線漏洞的分布情況，哪些業務目前安全風險較大，是否需要進一步了解等；
另一方針對業務方，可以定期給業務線安全接口人/負責人等管理角色推送安全數據以及風險評估報告。