本文目錄

第一部分楔子

第二部分道與認知

一、漏洞管理成熟度

二、漏洞管理痛點與難點

三、 漏洞認知

四、 漏洞管理目標與方針

第三部分 術與節源

一、 制定漏洞管理規范

二、 制定安全檢查規范

三、 組織落實

四、 建立基線版本庫

五、 建立安全配置上線指南

六、漏洞修復知識庫

第四部分 術與開流

一、漏洞發現能力建設

（一） 漏洞來源分析

（二） 漏洞檢測左移

（三） 漏洞檢測常態化

二、 漏洞分類

三、漏洞分級

四、漏洞管理目標

五、 平臺架構設計

六、 資產管理設計

七、 管理流程設計

五、漏洞流程管理

（一）漏洞錄入

（二）資產定級

（三）漏洞定級

（四）漏洞跟進

（五）漏洞督辦

第五部分 展望

一、 全面的資產安全管理

二、 聯動的資產漏洞情報

三、 更精準化的組件漏洞檢測

第一部分 楔子

近幾年，公司開展了多輪網絡攻防演習，攻防演習的開展促進了基礎安全架構升級和完善，隨著WAF、IPS、蜜罐、全流量等安全設備和策略的逐步完善，網絡安全工作走入深水區。

如果說基礎安全架構的完善是練外功，那么對資產漏洞的管理就是練內功，外功易得，內功難練。

攻防演習對抗的就是對漏洞的感知、利用和防護，發現的是資產漏洞，在攻防對抗愈演愈烈的當下，管理漏洞就成了安全運營必須攻克的攔路虎。

如何避免被打穿，從資產角度，最快速有效的防御方法就是干掉資產，系統下線就屬于此類，但是，干掉所有資產是不現實的。

于是，隱藏資產就成了緩解措施，但總有對外的業務沒法隱藏，且并不是隱藏了就是安全的，隱藏資產只是對漏洞的掩耳盜鈴，漏洞的存在和利用都是客觀存在的。

從漏洞角度，漏洞管理不是愚公移山的有無恒心問題，而是一個管子進水、一個管子出水的數學題，只有減少進水、加大出水，才能避免水溢出。

漏洞，就像房貸一樣，一直在那，是安全人員的債。是債，遲早要還。漏洞處置，是亡羊補牢，為時不晚。

漏洞是企業網絡安全保障體系的薄弱點，做好漏洞管理是堵住企業網絡安全保障體系缺口、健全金融網絡安全保證體系的關鍵舉措，也是保障金融網絡安全、HW行動和應對未來挑戰的必由之路。

第二部分道與認知

一、漏洞管理成熟度

作為2B級的中小法人銀行，隨著滲透測試、攻防演習的常態化，網絡安全建設進入深水區，漏洞管理已成為我行亟需解決的管理問題。

美國系統管理和網絡安全審計委員會參照CMMI的做法，制定了漏洞管理成熟度模型，來衡量企業組織目前的漏洞管理水平。漏洞管理成熟度模型主要包括如下5個階段：

級別	階段	定義	自評
1	初始階段	處在這一階段的公司企業要么沒有任何漏洞管理措施，要么只做臨時性的測試。	時間：2012-2015 管理范圍：監管、二三道防線、內部檢查發現的合規問題由100余條增加至300余條。 形態：合規層面的督辦整改，基本不涉及技術漏洞。
2	已管理階段	處于這個階段的企業可以自發在內部開展漏洞掃描工作，每周或者每月固定開展，但是往往是為了應對外部監管。	時間：2015-2018 管理范圍：監管、二三道防線、內部檢查發現的問題+滲透問題，增至800余條。 形態：制定漏洞管理指引，收集漏洞的渠道增多，形成常態化督辦、通報機制。
3	已定義階段	該階段的漏洞管理工作為公司所理解，也受到公司管理層的一定支持，漏洞掃描更為頻繁，但是專業工具應用還比較有限。	時間：2019-至今 管理范圍：監管、二三道防線、內部檢查發現的問題+滲透+演習+檢測+掃描問題，增至2000余條。 形態：制定漏洞管理、上線前安全檢查制度，漏洞掃描常態化，安全檢測手段進一步增多，收集漏洞的渠道進一步擴寬，進行人工漏洞優先級定級，形成每周督辦、每月通報機制。
4	量化管理階段	處在這一階段的公司企業有可量化、可度量的指標，定義可接受的風險水平。	時間：*-2025年 管理范圍：內外部檢查合規問題、資產測繪+漏洞掃描漏洞、滲透+攻防漏洞、組件漏洞。 形態：漏洞管理制度進一步完善和落實，使用多樣的漏洞檢測工具，實現漏洞交叉校驗，全面覆蓋合規、主機、web、組件漏洞，實現漏洞發現渠道多樣化、漏洞發現自動化、漏洞定級自動化、漏洞處置指標化、漏洞跟進可量化。
5	優化管理階段	在這一階段，使用第四階段定義的度量指標用實現管理提升和優化，所有的優化指標都用于減少組織的受攻擊面。	時間：未來 形態：漏洞情報聯動化、漏洞處置自動化

表1：漏洞管理成熟度評估表

二、漏洞管理痛點與難點

隨著信息化和數字化的建設，資產數量暴增的同時，外部漏洞披露逐年增多，安全檢測深度也逐漸加大，漏洞數量隨之暴增。

而目前漏洞修復時間效率嚴重偏低、修復成本嚴重偏高，導致漏洞逐年積壓，漏洞積弊長年累月，蘊含極大風險隱患。

漏洞已成為國家級戰略武器，漏洞研究和利用已產業化，銀行需進一步提高漏洞響應時效。

但漏洞數量龐雜，相同漏洞在不同資產上的修復優先順序不一樣，哪些先改，哪些后改，是安全管理人員亟需定義和評判的。

這些，通通都是漏洞管理的痛點和難點。

圖1：漏洞管理痛點與難點

既然漏洞是安全管理繞不開的結，那就嘗試管住它吧。

三、漏洞認知

外部或二三道防線對于漏洞的認知就是“哇哦，系統有漏洞，好危險，肯定要改”。

為了應對這種情況，安全人員只能“掩耳盜鈴”，在漏洞掃描器前加一堆安全策略或設備，然后掃出沒有漏洞的掃描結果，你好我好大家好，只留下漏洞默默的潛伏，直至某天突然地爆發。

所以改變對漏洞的認知，很重要，而漏洞管理的認知誤區又有不少：

1. 漏洞管理就是應急打補丁：漏洞管理應該包括事前預防、事中控制和事后處理，漏洞管理也不止打補丁一種方式，打補丁只是一種成本最高的事后補救措施；
2. 漏洞管理就是建流程：建漏洞整改流程，只是為了更高效地跟進漏洞的整改，形成整改閉環，它只是漏洞管理的一個抓手。
3. 漏洞管理只是安全的事：漏洞管理缺少了開發、運維的深度參與，漏洞管理只是救火運動，漏洞管理應該是開發、運維、安全全流程的管控。
4. 漏洞管理最重要的是漏洞掃描：漏洞掃描只是一個發現漏洞的工具，而漏洞發現只是資產發現后的下一步，發現不是目的，整改才是。
5. 只需要修復POC/EXP漏洞：POC漏洞只是市面上已知存在工具的漏洞，市面上沒有POC，不代表沒有利用工具。
6. 是漏洞就需要修復：在漏洞整改時，眉毛胡子一把抓是大忌，大部分漏洞影響有限，漏洞修復也是要計算投入產出的，而且也不可能修復所有的漏洞，所以并不是所有的漏洞都需要修復。

四、漏洞管理目標與方針

漏洞管理，首先是漏洞，其次是管理。

漏洞，是依附資產上的，是資產的一個安全屬性，所以做好漏洞管理就應該先做好資產安全的管理，所以脫離資產的漏洞評級都是耍流氓。

管理，是通過實施計劃、組織、協調、控制等職能實現既定目標的活動過程，漏洞管理，即是確立漏洞管理目標、制定漏洞管理計劃、建立漏洞管理組織、協調內外部資源、控制漏洞管理質量的一個工程。

為做好漏洞管控指導工作，明確漏洞管理目標和方針是第一步。

漏洞管理的目標應該是“從根源上減少漏洞的產生，并能全面、自動、高效、精準地發現和處置關鍵漏洞，實現資產安全閉環管理：

1. 全面：通過多渠道、多場景全面發現資產和漏洞。
2. 自動：支持資產、漏洞數據的自動同步，任務的自動下發，數據的自動分析、入庫。
3. 高效：實現漏洞的高效應急和高效整改。
4. 精準：通過多工具交叉驗證資產及漏洞的狀態，輔以全面的漏洞知識庫，實現漏洞的精準分類分級。
5. 關鍵漏洞：即對漏洞進行優先級排序，結合資產重要程度、網絡邊界屬性、漏洞利用情報等因素進行優先級算法排序，指導高效漏洞整改。

要實現漏洞管理的目標，需要制定工作方針，漏洞管理方針是“全面保障，預防為主，綜合治理，分級管控”。

1. “全面保障”：漏洞管理應確保全面發現資產漏洞
2. “預防為主”；漏洞管理主要工作是預防漏洞產生
3. “綜合治理”：漏洞管理應該是多方參與協同治理
4. “分級管控”：漏洞處置應做好分類分級科學處置。

通過對漏洞管理目標和方針的分析，做好漏洞管理的道就是節源開流。節源，是減少漏洞的產生來源；開流，則是加大漏洞的整改力度。

預防漏洞是節源，是一場細雨，潤無聲，于無聲處見真章；

整改漏洞是開流，是一次排雷，動天地，于驚險中解風險。

漏洞管理是企業網絡安全管理中最基礎的工作，重要性毋庸置疑。

但如何節源？又如何開流？

第三部分 術與節源

打補丁能解決的只是一個或一批漏洞，不能解決所有漏洞，企業需要補的也不只是漏洞本身，而是安全管理存在的漏洞，包括組織職責分工、工作流程、工作規范等存在的不足都可能導致漏洞的產生。

一、制定漏洞管理規范

規范管理，制度先行，制度是一切管理的基石和保障。

制定漏洞管理規范能為漏洞管理提供指導性意見、方法和統一標準，規范應明確漏洞管理原則、職責分工、等級評估、處置標準、修復風險評估和修復過程控制等。

相同的漏洞在不同資產上的風險是不同的，所以漏洞管理規范應明確漏洞風險等級評估標準，明確漏洞二次定級規則。

具體實踐可根據資產網絡屬性、重要級別以及漏洞原始等級進行。如：漏洞風險等級積分（S）=漏洞初始風險等級基礎因子（X）*系統級別權重因子（Y）*網絡邊界類別基礎因子（Z）

表2：漏洞風險等級積分矩陣表

二、制定安全檢查規范

提高漏洞發現能力，擴寬漏洞發現來源，是做好漏洞管理的技術前提，漏洞發現能力低下的漏洞管理注定只是自我欣賞的表演。

建立安全檢查規范，明確各類系統變更或上線前的安全檢查要求，能提前發現和處置漏洞，也是預防漏洞產生的重要手段。

表3：系統變更前安全檢查矩陣表

對于新建外包開發系統，安全人員可在設計評審前收集SBOM，對使用的開源組件合規和漏洞情況進行評估審查，明確需要整改的組件，提前發現和預防組件風險，做到安全左移。

安全檢查流程大體如下：

圖2：安全檢查流程圖

三、組織落實

漏洞管理工程涉及人員較多，明確工作責任，確保工作落實是做好漏洞管理的管理前提。

可建立漏洞管理職責清單，明確各負責人在漏洞管理相關職責，除履行職責范圍內的漏洞修復以外，還承擔如下具體職責：

成員	漏洞管理工作職責
總經理	監督漏洞管理各項工作落實。
運維組	1、建立windows、linux等操作系統，tomcat、各類中間件，各類數據庫，openssh等基礎軟件的基線版本庫，每年迭代更新，并確保新系統不得使用低于基線版本的軟件。 2、建立操作系統、數據庫、中間件、基礎軟件等安全配置指南，并確保新設備、系統按要求配置。
網絡組	建立網絡設備及網絡管理相關系統的基線版本，每年迭代更新，新系統不得使用低于基線版本的硬件和軟件。
開發組	協同建立開發語言、互聯網開發組件基線版本庫，每年迭代更新，新系統不得使用低于基線版本的軟件。
安全組	1、建立漏洞管理規范、安全檢查規范，組織開展各類安全檢查，進行漏洞管理工作。 2、組織、協助和督促基線版本庫的建設和迭代更新，檢查基線版本庫建設情況，提供安全技術支持。 3、初始化搭建漏洞修復知識庫，協助后續漏洞修復知識庫的管理和維護。

表4：漏洞管理工作中職責表

四、建立基線版本庫

基線版本庫是預防漏洞產生的重要防線，是隔絕歷史漏洞的防火墻，基線版本庫包括開發語言、通用軟件、開源組件等。產品基線庫以外，還應該有技術基線庫，包括開發安全知識庫、開發安全最佳實踐、編碼安全規范等開發知識庫，作為安全開發的過程指引。

1、明確開發語言基線版本，建立開發組件基線庫，明確行內使用開發語言版本、開發組件的類型、基線版本，嚴禁使用低于基線版本的組件，并根據威脅情報，每年評估、更新和發布開發組件庫的種類和版本。

2、建立通用軟件庫，明確操作系統、數據庫、中間件、基礎軟件等通用軟件的類型、基線版本，并根據威脅情報，每年評估、更新和發布通用軟件庫的種類和版本。

3、每年1月底前OA郵件發布下一年年度基線版本庫，并將基線版本納入設計評審，將基線落實情況納入上線評審，嚴禁新上線系統使用低于基線版本的通用軟件，減少新上線系統使用低于基線版本的通用軟件。

4、對于必須使用低于基線版本軟件的系統，上線前應發起OA簽報流程經部門負責人審批后方可上線。

5、各類軟硬件產品基線版本庫責任劃分如下：

序號	大類	產品名稱	責任人
1	應用軟件	web、app	開發組***
2	應用軟件	SDK	開發組***
3	開發語言	php	開發組***
4	開發語言	java	開發組***
5	開發語言	C++	開發組***
6	開發語言	C	開發組***
7	開發語言	.net	開發組***
8	開發語言	python	開發組***
9	開發組件	dom4j	開發組***
10	開發組件	fastjson	開發組***
11	開發組件	mybatis	開發組***
12	開發組件	Spring系列	開發組***
13	開發組件	poi	開發組***
14	開發組件	hibernate	開發組***
15	開發組件	netty	開發組***
16	開發組件	log4j、slf4j	開發組***
17	開發組件	quartz	開發組***
18	開發組件	log4j2	開發組***
19	開發組件	c3p0	開發組***
20	開發組件	Jackson	開發組***
21	開發組件	httpclient	開發組***
22	開發組件	vue	開發組***
23	開發組件	JDK	開發組***
24	開發組件	ibatis	開發組***
25	開發組件	FastFDS	開發組***
26	開發組件	rxjava	開發組***
27	開發組件	RocketMQ	開發組***
28	開發組件	quartz	開發組***
29	開發組件	PhotoView	開發組***
30	開發組件	greendao	開發組***
31	開發組件	Glide	開發組***
32	開發組件	EventBus	開發組***
33	操作系統	AIX	運維組***
34	操作系統	Windows	運維組***
35	操作系統	Linux	運維組***
36	數據庫	ORACLE	運維組***
37	數據庫	MYSQL	運維組***
38	中間件	APACHE	運維組***
39	中間件	IBM MQ	運維組***
40	中間件	kafka	運維組***
41	中間件	redis	運維組***
42	中間件	tomcat	運維組***
43	中間件	zookeeper	運維組***
44	中間件	weblogic	運維組***
45	中間件	nginx	運維組***
46	基礎軟件	Vmware	運維組***
47	基礎軟件	openssh	運維組***
48	基礎軟件	NTP	運維組***
49	基礎軟件	FTP	運維組***
50	基礎軟件	samba	運維組***
51	基礎軟件	smb	運維組***
52	基礎軟件	WebSphere	運維組***
53	基礎軟件	Allegro RomPager	運維組***
54	基礎軟件	MS SQL SERVER	運維組***
55	基礎軟件	Serv-U	運維組***
56	基礎軟件	Windows RDP	運維組***
57	基礎硬件	網絡設備	網絡組***
58	基礎硬件	安全設備	網絡組***

表5：基礎軟硬件版本管理責任表

五、建立安全配置上線指南

1、建立應用系統、開發組件、操作系統、數據庫、中間件、基礎軟件等安全配置指南，上線前指定專人按照指南配置，并經他人確認、復核后方可上線。

2、實施運維標準化建設，實現日常流程標準化、操作系統標準化、中間件標準化、應用部署標準化、集成發布標準化、監控指標標準化、日志規范標準化。

3、新系統正式上線前應對軟硬件基線版本、安全配置情況進行檢查，檢查結果作為上線評審依據，確認無誤后方可上線。

六、漏洞修復知識庫

1．建立漏洞知識庫，提供一個全面、權威和有效的漏洞修復指導方案庫，能保證漏洞修復工作能更有效進行，減少漏洞修復的失敗率。

2．漏洞知識庫內容包括：Web漏洞修復知識庫、APP漏洞修復知識庫、主機漏洞修復知識庫、中間件漏洞修復知識庫、其他通用軟件漏洞修復知識庫。

3．漏洞知識庫的組成部分應包括：漏洞類型、漏洞名稱、產生原因、危害、修復建議、利用方式、案例、真實案例。其中“真實案例”由錄入的漏洞修復后脫敏提取。

4．漏洞修復知識庫的建立來源主要如下:參考漏洞掃描設備的標準解決方案作為基礎；利用多方威脅情報數據，錄入更多的解決方案作為參考；人工定期整理已驗證過的漏洞修復方案作為權威標準方案。

5．開發、測試、運維人員可以自助學習漏洞知識庫的內容，了解漏洞原理及修復方法，當開發在開發某功能時，可以查看會出現哪些漏洞。如：登錄、注冊、密碼找回等。

6．互聯網系統大版本升級前進行一次開發安全技術培訓，并定期從漏洞知識庫中抽取內容組織開展開發安全開發技術培訓、安全測試培訓。

漏洞管理的理念應該是“管理前置，迭代更新；預防為主，修復為輔”。故本部分內容主要介紹為預防漏洞采取的一些舉措，不同企業網絡安全水平參差不齊，對網絡安全投入不一樣，可以適當裁剪或深化。

如有其他更行之有效的漏洞預防措施，歡迎交流和分享。

第四部分 術與開流

節源是未雨綢繆，目的是預防和減少漏洞的產生，但不能避免新漏洞的威脅。當存量資產命中新漏洞后，漏洞修復成了必然的選擇。

開流是亡羊補牢，目的是及時發現和處置漏洞，避免造成更大的隱患。

為提升漏洞修復效率，抓住漏洞修復的重點工作，防患于未然，降低整體安全風險，公司啟動了漏洞治理實踐活動。本部分主要介紹漏洞管理平臺建設的實踐經驗。

本部分的理念是以全面的資產發現為基礎，以數據存儲和治理為核心，以多源采集為提升，以漏洞優先級為衡量基準，以管理體系為抓手，實現全網資產、漏洞的全面、閉環管理。

一、漏洞發現能力建設

（一）漏洞來源分析

做好漏洞管理工作的前提是能發現風險、檢測出漏洞，本部分不探討0day漏洞的發現和處置，僅分析常規漏洞。

目前行業上常規的web掃描器、漏洞掃描器、開源組件分析工具、代碼審計工具等均已較為成熟，開箱即用，使用技術門檻較低。

而滲透測試、攻防演習等才是漏洞發現能力建設需要持續投入和保持技術迭代更新的。

漏洞來源主要包括上線前檢測、常規檢測、外部威脅,具體如下：

圖3：漏洞來源圖

應采取技術和管理手段逐步擴大漏洞發現力度和深度，擴大自主主動發現漏洞比例，深化定期檢測效果。

如滲透測試服務，可采取多家供應商競爭比賽、交叉檢驗的方式，有條件、公司允許的的還可以采取SRC提高漏洞發現能力。

如攻防演習服務，可采取按發現漏洞的效果付費模式，或引入多家同時比拼，運動式的一年多次開展。

但這種運動式的演習并不能檢驗企業常態化網絡防守能力，故可以采取無人防守干預的分批演習模式，固定演習目標，防守方無人值守，演習后攻防雙方面對面復盤攻擊和防守情況，檢驗企業日常安全防護的有效性。

在建設漏洞發現能力時，如何做好漏洞發現自動化也是需要考慮的問題，包括：自動化掃描、自動化入庫、自動化定級。

（二）漏洞檢測左移

漏洞檢測左移不同于預防漏洞，而是提前發現和處置漏洞，都知道漏洞修復成本在生產階段的成本最大，那么與漏洞賽跑，提前發現并處置漏洞就尤為重要了。

在項目設計階段，將安全需求納入需求管理，對系統的SBOM、安全需求對標結果進行評審，提前發現組件漏洞，并確保安全需求的執行；

在項目開發階段，對開發人員進行培訓，使其學會使用源代碼掃描工具，實時掃描代碼漏洞，及時處置代碼問題；

在項目SIT階段，部署IAST插樁節點，進行交互式漏洞檢測，提前發現web和組件漏洞；

在項目UAT階段，進行上線前的漏洞掃描和滲透測試，經整改確認后，方可通過上線評審。

（三）漏洞檢測常態化

制定資產測繪和漏洞掃描方案，針對互聯網邊界等重點區域的加大掃描密度，如每周、每月，非重點區域的以滿足合規為目標，可以每季度掃描一次。

檢測內容	頻率	執行方式
互聯網資產測繪	每周	定時任務
網銀區內網資產測繪	每月	定時任務
內網資產測繪（全覆蓋）	每季度	定時任務
內網POC漏洞巡檢	每月	定時任務
漏洞掃描	每季度	手工執行+現場值守

表6：漏洞檢測工作表

二、漏洞分類

漏洞管理的范圍包括通過手工或自動化工具發現的應用軟件（web、app、SDK）、開發語言、開發組件、通用軟件（操作系統、數據庫、中間件、基礎軟件）等的漏洞。包括但不限于行內、行外安全評估、檢測發現的漏洞以及第三方通報的漏洞。

基于目前行業態勢及管理需要，漏洞分為四類：IP類、web類、組件類、合規類。

漏洞分類	支撐庫	漏洞來源	關鍵工作
IP類	IP資產庫	資產測繪、各類主機掃描產品	1、資產覆蓋 2、漏洞精確度 3、優先級技術 4、交叉驗證
Web類	Web資產庫	資產測繪、攻防演習、滲透測試、web掃描、IAST等	1、實施頻率 2、實施深度 3、覆蓋范圍
組件類	組件庫	SBOM評審、SCA分析、IAST	1、優先級技術
合規類	/	監管、三道防線檢查發現的管理問題。	/

表7：漏洞分類表

三、漏洞分級

根據《網絡安全漏洞分類分級指南》（GB/T 30279-2020），漏洞分技術分級和綜合分級兩個等級，均分為超危、高危、中危、低危。

漏洞級別	定義
超危	漏洞可以非常容易地對目標對象造成特別嚴重后果。
高危	漏洞可以容易地對目標對象造成嚴重后果。
中危	漏洞可以對目標對象造成一般后果,或者比較困難地對目標造成嚴重后果。
低危	漏洞可以對目標對象造成輕微后果,或者比較困難地對目標對象造成一般嚴重后果.或者非常困難地對目標對象造成嚴重后果。

表8：漏洞分級表

技術分級為漏洞原始等級，由漏洞本身被利用性（訪問路徑、觸發要求、權限要求、交互條件）和影響程度（保密性、完整性、可用性）兩個指標類決定。

綜合分級為以技術分級為基礎，綜合影響范圍、被利用成本、修復難度等環境因素后得出的綜合風險等級，更客觀地為漏洞修復提供了參考依據。

表9：漏洞綜合分級表

但綜合分級仍舊僅僅能表明漏洞本身的安全屬性，不能直觀、明了的給出相同漏洞在不同網絡環境、不同資產的整改排期。故開展漏洞治理工作勢在必行。

三、漏洞管理目標

如果沒有基于風險的漏洞管理方法，企業將無法面對不斷增長的漏洞威脅。

漏洞管理的目標是建立一套流程化、規范化、數據化的漏洞管理機制，實現漏洞全生命周期閉環管理，對web漏洞、主機漏洞、組件漏洞、合規漏洞進行系統化、流程化管理。

圖4：漏洞管理目標圖

基于以上工作目標，總體實施設計如下：

圖5：漏洞管理設計方案圖

四、平臺架構設計

漏洞管理平臺是資產、漏洞的統一管理平臺，也是漏洞檢測任務的統一掃描平臺，通過其建立掃描任務，自動執行掃描，實現漏洞的集中化管理。

漏洞管理平臺架構設計如下：

圖6：漏洞管理平臺架構圖

架構中重點需要運營的有3個資產庫和3個漏洞庫，資產庫包括IP庫、Web庫、組件庫，漏洞庫則包括主機漏洞庫、Web漏洞庫和組件漏洞庫。

IP庫應包括IP資產的操作系統版本、IP、端口、網絡分區、所屬環境、網絡邊界類型、中間件及版本、服務信息、數據庫及版本等等。

Web庫應包括該站點所有URL、API清單、Request、Response，API、URL可依賴API安全產品集成收集。

組件庫應包括該應用系統使用的所有開源組件名稱、版本、組件類型、開源協議類型、推薦版本、最新版本等等。

資產來源越廣、資產屬性越全，越能提高資產和漏洞管理效率。

五、資產管理設計

資產管理架構從上至下分別為組織架構、應用系統、資產、漏洞四個層次，漏洞依附于資產，資產屬于應用系統組成，而應用系統是歸屬不同組織下。

組織架構：可設置為部門-中心-組架構，或者集團-分公司-部門-組架構。

圖7：漏洞管理組織架構圖

應用系統：不同分組負責不同的應用系統，應用系統可以從公司CMDB或者管理平臺同步，同步的要素包括但不限于：系統名稱、系統分類、業務分類、系統狀態、等級保護、重要程度、開發公司、技術團隊、開發負責人、運維A角以及其他自定義屬性及枚舉值。

圖8：應用系統頁面展示圖

資產數量、漏洞數量則是應用系統下不同類型的資產數量和對應漏洞數量的整合展示，便于應用系統負責人和安全人員快速了解應用系統的整體安全態勢，也方便安全人員快速排查無資產的應用系統。

資產：應用系統下分IP類資產、web類資產、組件類資產，資產來源包括CMDB、HIDS等各類資產管理工具以及資產測繪、RSAS等各類漏洞檢測工具。

目前資產屬性包括：資產類型、應用系統名稱、資產地址、資產名稱、資產負責人、資產來源、網絡環境、網絡邊界類型、資產狀態、漏洞優先級以及其他自定義屬性及枚舉值。

除此之外，平臺還存儲了同步來的其他資產屬性，包括服務、端口、協議等開放的服務端口，軟件名稱、版本、廠商等使用的軟件信息（由于本期重點為漏洞管理，故資產部分未進行精細化設計和整合處理）。

圖9：資產管理頁面展示圖

漏洞優先級為根據資產安全屬性、漏洞原始級別以及威脅情報經過二次定級后的漏洞等級，展示的是該資產下現有漏洞情況。當發現新漏洞需要錄入時可編輯該資產添加漏洞。

漏洞：經過梳理，不同類型漏洞的字段大體相同，故漏洞頁面整合了IP類、web類、組件類、合規類四大類漏洞，可根據需要篩選各類型漏洞。

目前漏洞屬性包括：漏洞分類、應用系統名稱（如有）、資產地址、漏洞名稱、漏洞級別（原始等級）、漏洞優先級（二次定級）、漏洞來源、漏洞類型、漏洞描述、修復建議、修復期限、修復負責人、檢測詳情、發現狀態以及檢查名稱等其他自定義屬性及枚舉值。

圖10：漏洞管理頁面展示圖

點擊流程按鈕，可以看到漏洞時間線：

圖11：漏洞流程頁面展示圖

六、管理流程設計

漏洞狀態共分為待派發、待確認、修復中、待復測、復測已通過、復測未通過、待審核、關閉。大致流程如下：

圖12：漏洞管理流程圖

待派發：同步、導入、錄入的漏洞初始狀態為待派發，需經過安全人員驗證、審核后派發給整改責任人。

待確認：可將不是自己的漏洞轉辦給其他負責人，在此過程中需確認漏洞負責人是否準確，漏洞是否誤報，是否修復，以及確認出修復方案。

圖13：漏洞確認圖

待審核：由所屬主管對確認環節提交的申請不修復、申請誤報、申請延期等的進行審核，審核后提交安全人員確認。

修復中：確認完成后即進入修復中，待修復后即可反饋已修復，之后進入安全人員的待復測環節。

待復測：復測結果如為復測通過的即進入上線環節或關閉，復測結果如為不通過則退回至修復中，直至復測通過。

上線：漏洞洞負責人需點擊上線，方可完成漏洞閉環（主要針對web漏洞和組件漏洞，因為該類型漏洞一般在測試環境修復后復測，需正式投產到生產環境才算漏洞修復，故需在上線階段登記何時上線，確保漏洞整改已完成生產變更）。

關閉：經確認為誤報、不修復、已修復的漏洞會處于關閉狀態。

在漏洞流程管理上明確了以下要求：

1．漏洞整改責任人收到漏洞信息后，應立即分析漏洞的情況，對漏洞進行接收和確認，做出漏洞修復方案和計劃，對于計劃整改的根據漏洞等級立即整改，對于無法整改或接受風險的漏洞反饋不整改的原因。

2．整改責任人在漏洞整改完成后在漏洞管理平臺中標注已整改，提請安全管理員進行復測，如果復測發現漏洞依然存在，則歸為修復失敗，對于修復失敗的漏洞重新轉換到漏洞發現狀態。

3．安全管理員復測確認已整改后，在漏洞管理平臺中登記確認已整改，完成漏洞的整改閉環流程。

4．對于存在風險但修復成本過高或無法整改的漏洞，漏洞整改責任人應在接收到漏洞后，反饋不整改的意見，經安全管理員確認，安全管理員確認后必須整改的則進入整改流程。

七、漏洞管理流程

發現漏洞是漏洞管理的基石，有效管理并快速響應漏洞則是挑戰。

（一）資產/漏洞入庫

自動入庫：漏洞管理平臺對接了CMDB 、IAST、HIDS、RSAS等資產管理工具或漏洞發現工具，實現資產、漏洞的自動入庫，提高漏洞管理自動化水平；

手工導入：針對內外部檢查檢查發現的非標準化問題，安全人員應先對漏洞內容進行初步確認，明確漏洞修復優先級，并進行分工，再導入漏洞管理平臺。

下發掃描任務：定期的漏洞掃描可通過漏洞管理平臺進行任務下發，掃描完成后漏洞自動解析入庫。

（二）資產定級

在進行漏洞掃描或者資產同步時，可根據入庫IP自動賦值網絡分區、網絡邊界類型、主機環境等資產網絡屬性，同時繼承應用系統的保護等級和重要程度。

 

圖14：資產屬性配置頁面圖

根據內外網關聯清單，可快速查找互聯網邊界資產對應內網資產。

圖15：內外網IP關聯頁面圖

（三）漏洞優先級

權威報告顯示傳統的漏洞整改可能做了76%的無用功，僅有3%的漏洞應優先關注。

76%的無用功：在每年新發現的漏洞中，即使安全團隊修補了所有高危和嚴重漏洞，也不過修復了24%的可利用漏洞，有76%的時間消耗在短期內幾乎無風險的漏洞上，有44%的短期可被利用的漏洞被評為中低風險，很可能被忽略掉。

3%優先漏洞：Tenable通過對20萬億漏洞情報等數據進行人工分析和機器學習后認為安全團隊應該優先關注的漏洞占所有漏洞的3%左右

圍繞漏洞可利用性和關鍵性對漏洞進行優先級排序是開展漏洞管理的首要目標。

主機漏洞的發現能力容易建立，攢漏洞掃描設備即可，但主機掃描產品、SCA工具掃描出的漏洞都是海量的，但從海量漏洞里如何確定漏洞的整改優先級，這才是漏洞管理的核心，漏洞的優先級技術至關重要。

漏洞的優先級不僅僅只考慮資產安全屬性和漏洞本身屬性，還應該考慮漏洞生命周期、漏洞情報以及漏洞標簽等。

本方案中漏洞優先級根據配置的風險值自動自動賦值風險優先級，風險值范圍和修復期限均可自定義，平臺會根據漏洞優先級自動賦值修復期限。

圖16：優先級設置頁面圖

風險值的計算根據資產安全屬性、漏洞屬性、漏洞生命周期、漏洞情報屬性等綜合計算而來：

圖17：優先級權重配置頁面圖

資產安全屬性可考慮的有：等級保護、重要等級、設備類型、資產狀態、網絡環境、網絡邊界類型等等。

 

漏洞安全屬性包括：漏洞的原始CVSS分值、錄入時漏洞的原始等級、漏洞類型、公布時間長短、敏感端口服務等。

圖19：漏洞屬性權重配置頁面圖

生命周期屬性包括漏洞發現方式、發現狀態、修復是否超期等，情報則包括是否有POC/EXP、網關防御規則是否有效等。

圖20：漏洞生命周期權重配置頁面圖

設置好各類安全屬性的數值，再使用平臺的風險計量工具校驗和微調，直到不同類型的組合計算能滿足預期結果。如：

1、在線預發布、直接接入互聯網的資產命中超危漏洞，漏洞優先級為高危。

圖21：漏洞風險計算頁面圖

2、在線、預發布、非直接接入互聯網的資產命中超危漏洞，漏洞優先級為中危

圖22：漏洞風險計算頁面圖

（四）漏洞派發

漏洞優先級確定好后，可根據漏洞標簽、漏洞優先級綜合考慮后將漏洞派發出去或者直接置為不修復。

對應不同優先級的漏洞可設置不同的修復期限、漏洞通知，根據漏洞優先級設定的整改時限，設置修復計劃時間，修復計劃時間到期，自動發送郵件至系統負責人郵箱提醒，參考如下：

漏洞優先級	漏洞修復期限	漏洞即將到期通知	漏洞響應期限	整改要求
超危	10	<5天	≤0.5天，人工通知	必改，緊急處置。
高危	30	<10天	≤1天，人工通知	必改，盡快處置。
中危	90	<20天	≤5天，郵件督辦	必改，及時處置。
低危	360	<30天	≤5天，郵件督辦	部分漏洞經評估后可接受風險，排期處置。

表10：漏洞修復規則表

漏洞派發前的關鍵工作包括：

1．如何實現漏洞管理自動化，如可以根據url/app名稱/ip/機器名自動匹配整改責任人。

2．如何漏洞整改智能化，如在錄入選定某一類安全漏洞的時候，可以自動彈出該類漏洞的的修復方案和風險。

3．如何實現漏洞分派的智能化，自動根據資產責任人、漏洞情況分發漏洞。

做好這些，漏洞派發效率也能大大提升。

（五）漏洞督辦

漏洞整改不是目的，應以漏洞整改督辦促進開發、運維重視漏洞管理工作，指引做好漏洞的預防工作。

分發后的漏洞需要及時通知漏洞修復負責人跟進，并及時通報超期未處理的流程和即將到期的漏洞，故可設置以下幾類通知：

(1)新增待辦通知：每日早上自動郵件告知責任人有新增的漏洞，督促其處理漏洞流程。

(2)漏洞確認超期通知：每周一早上統計超期未修復漏洞和超5天未確認漏洞，郵件通知責任人處理。

(3)漏洞即將到期通知：每周二早上統計即將到期的漏洞，郵件通知修復負責人及時跟進。

圖23：漏洞通知頁面圖

針對郵件通知仍不處理的，可每月統計和通報至領導群。同時，可將漏洞通知推送至IT運維平臺或科技管理平臺展示，提高漏洞通知的觸達率。

在做漏洞督辦管理時的關鍵點包括：

1．漏洞修復數量化，需對修復漏洞數、修復漏洞耗時、修復漏洞成功率等漏洞修復成果進行統計和展示。

2．漏洞督辦自動化，對于超期未確認、臨期的漏洞，漏洞管理平臺可以有節奏的提醒責任人修復漏洞。

漏洞管理是一項精細化的運營工作，也是一項需要長期投入但又默默無名的工程。漏洞管理的成功運營離不開以下三點：

1、企業對漏洞治理工程的財務支持，以及相關單位對漏洞運營的技術支撐；

2、漏洞運營人員需要對企業網絡資產有清晰的認識；

3、漏洞運營人員需要了解各類漏洞的原理和防范，對漏洞有一定的技術功底。

經過半年的功能完善和漏洞運營，完成了2萬余個漏洞的閉環管理，但仍有大量漏洞未能完成分析和閉環，漏洞管理工作任重而道遠。

第五部分 展望

近兩年，監管通報漏洞和漏洞情報日益增多，存在漏洞的軟件是否有使用？版本是否命中，命中的資產是否需要立即處理？

如何快速響應漏洞情報，快速定位受影響資產是亟需處理的技術問題，而這個問題的根源便是是否實現全面、深入的資產安全管理。

只有全面的資產管理，才能在排查漏洞時快速定位漏洞影響的資產，開展漏洞的應急處理，只有有機整合了資產、漏洞和情報的平臺才能發揮資產安全管理的價值。

一、全面的資產安全管理

截至目前，漏洞管理平臺已接入大多數資產管理工具，但目前用的比較多的漏洞管理，未進行更深入的資產安全管理工作，未來，全面、深入的實現資產安全管理是下一階段的重點。

資產的全面管理就得考慮資產的覆蓋面，包括：CMDB主機資產覆蓋率、HIDS資產覆蓋率、EDR資產覆蓋率、漏掃覆蓋率、重要資產堡壘機納管率。

資產的深入管理就得考慮資產屬性的全面性，包括：端口、服務、版本······以及更多可豐富資產安全屬性的內容。

二、聯動的資產漏洞情報

HW期間，漏洞的應急處置離不開情報，而漏洞情報又是以標簽化形式展示的，所以提供一套科學、合理的漏洞標簽，能大大提高漏洞派發效率。

基于目前行業對于漏洞標簽暫未有更好的實踐和分類，各家漏洞標簽的做法各式各樣，漏洞分類、關鍵漏洞目錄、漏洞類型、POC/EXP、勒索、APT、重保、是否重啟······都是漏洞標簽。

基于漏洞庫數量較大，漏洞標簽運營維護成本較高，各家仍存在標簽體系混亂、標簽內容不準的問題，希望未來能有更體系化、更具象化的漏洞標簽，能夠實現漏洞標簽與優先級自動化關聯定級。

三、更精準化的組件漏洞檢測

截至目前，漏洞管理平臺僅接入了IAST檢測發現并經確認需要修復的組件漏洞，暫未進行更深入的組件漏洞管理和運營。

組件漏洞的數量比IP類的會更多，海量組件漏洞里哪些需要先修復，做好VPT是關鍵。

SCA產品有用，但掃出來的漏洞太多，基于目前的人力物力，依靠自身基本沒法用起來，期望未來能有更完善的解決方案，不只是把漏洞掃出來，而是能漏洞整理出來，建議用戶先處理哪些。

關于組件漏洞的二次定級個人認為可以綜合考慮這些方面：

1、資產安全屬性：是否互聯網系統、重要等級等；

2、組件安全屬性：web前端類、后臺類、數據庫類等，直接依賴、間接依賴等；

3、漏洞安全屬性：利用難易、遠程/本地、漏洞危害等；

4、漏洞修復屬性：底層代碼更新、組件升級、影響范圍大小、修復難度（杠精：難道漏洞難修就排后面不修了么？非也！需要修的漏洞很多，考慮此屬性，更多的是希望把錢和精力花到刀刃上，達到更高的投入產出比）；

5、漏洞情報屬性：POC、EXP、利用可達性。

來源：Pensecife