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 確保閉環

安全問題並不是發現後單方面推給業務側就不用管了，需要實時跟進，徹底修復，畢竟收斂安全風險、解決安全問題並且後續不要再次重複出現才是安全的最終目的。

對於不同等級的漏洞有不同的修復優先順序和時效性要求，如有高、中、低 分別對應3、7、14個自然日；覆蓋郵件、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 資料分析

精細化運營少不了對資料的分析解讀，對安全來說需要定期檢視資料、指標，是否在閾值範圍內，近期漏洞數量/型別變化情況，安全是否需要採取新的控制措施；各業務線漏洞的分佈情況，哪些業務目前安全風險較大，是否需要進一步瞭解等；

另一方針對業務方，可以定期給業務線安全介面人/負責人等管理角色推送安全資料以及風險評估報告。