本文目錄

第一部分楔子

第二部分道與認知

一、漏洞管理成熟度

二、漏洞管理痛點與難點

三、 漏洞認知

四、 漏洞管理目標(biāo)與方針

第三部分 術(shù)與節(jié)源

一、 制定漏洞管理規(guī)范

二、 制定安全檢查規(guī)范

三、 組織落實

四、 建立基線版本庫

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

六、漏洞修復(fù)知識庫

第四部分 術(shù)與開流

一、漏洞發(fā)現(xiàn)能力建設(shè)

（一） 漏洞來源分析

（二） 漏洞檢測左移

（三） 漏洞檢測常態(tài)化

二、 漏洞分類

三、漏洞分級

四、漏洞管理目標(biāo)

五、 平臺架構(gòu)設(shè)計

六、 資產(chǎn)管理設(shè)計

七、 管理流程設(shè)計

五、漏洞流程管理

（一）漏洞錄入

（二）資產(chǎn)定級

（三）漏洞定級

（四）漏洞跟進

（五）漏洞督辦

第五部分 展望

一、 全面的資產(chǎn)安全管理

二、 聯(lián)動的資產(chǎn)漏洞情報

三、 更精準(zhǔn)化的組件漏洞檢測

第一部分 楔子

近幾年，公司開展了多輪網(wǎng)絡(luò)攻防演習(xí)，攻防演習(xí)的開展促進了基礎(chǔ)安全架構(gòu)升級和完善，隨著WAF、IPS、蜜罐、全流量等安全設(shè)備和策略的逐步完善，網(wǎng)絡(luò)安全工作走入深水區(qū)。

如果說基礎(chǔ)安全架構(gòu)的完善是練外功，那么對資產(chǎn)漏洞的管理就是練內(nèi)功，外功易得，內(nèi)功難練。

攻防演習(xí)對抗的就是對漏洞的感知、利用和防護，發(fā)現(xiàn)的是資產(chǎn)漏洞，在攻防對抗愈演愈烈的當(dāng)下，管理漏洞就成了安全運營必須攻克的攔路虎。

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

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

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

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

漏洞是企業(yè)網(wǎng)絡(luò)安全保障體系的薄弱點，做好漏洞管理是堵住企業(yè)網(wǎng)絡(luò)安全保障體系缺口、健全金融網(wǎng)絡(luò)安全保證體系的關(guān)鍵舉措，也是保障金融網(wǎng)絡(luò)安全、HW行動和應(yīng)對未來挑戰(zhàn)的必由之路。

第二部分道與認知

一、漏洞管理成熟度

作為2B級的中小法人銀行，隨著滲透測試、攻防演習(xí)的常態(tài)化，網(wǎng)絡(luò)安全建設(shè)進入深水區(qū)，漏洞管理已成為我行亟需解決的管理問題。

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

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

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

二、漏洞管理痛點與難點

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

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

漏洞已成為國家級戰(zhàn)略武器，漏洞研究和利用已產(chǎn)業(yè)化，銀行需進一步提高漏洞響應(yīng)時效。

但漏洞數(shù)量龐雜，相同漏洞在不同資產(chǎn)上的修復(fù)優(yōu)先順序不一樣，哪些先改，哪些后改，是安全管理人員亟需定義和評判的。

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

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

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

三、漏洞認知

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

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

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

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

四、漏洞管理目標(biāo)與方針

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

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

管理，是通過實施計劃、組織、協(xié)調(diào)、控制等職能實現(xiàn)既定目標(biāo)的活動過程，漏洞管理，即是確立漏洞管理目標(biāo)、制定漏洞管理計劃、建立漏洞管理組織、協(xié)調(diào)內(nèi)外部資源、控制漏洞管理質(zhì)量的一個工程。

為做好漏洞管控指導(dǎo)工作，明確漏洞管理目標(biāo)和方針是第一步。

漏洞管理的目標(biāo)應(yīng)該是“從根源上減少漏洞的產(chǎn)生，并能全面、自動、高效、精準(zhǔn)地發(fā)現(xiàn)和處置關(guān)鍵漏洞，實現(xiàn)資產(chǎn)安全閉環(huán)管理：

1. 全面：通過多渠道、多場景全面發(fā)現(xiàn)資產(chǎn)和漏洞。
2. 自動：支持資產(chǎn)、漏洞數(shù)據(jù)的自動同步，任務(wù)的自動下發(fā)，數(shù)據(jù)的自動分析、入庫。
3. 高效：實現(xiàn)漏洞的高效應(yīng)急和高效整改。
4. 精準(zhǔn)：通過多工具交叉驗證資產(chǎn)及漏洞的狀態(tài)，輔以全面的漏洞知識庫，實現(xiàn)漏洞的精準(zhǔn)分類分級。
5. 關(guān)鍵漏洞：即對漏洞進行優(yōu)先級排序，結(jié)合資產(chǎn)重要程度、網(wǎng)絡(luò)邊界屬性、漏洞利用情報等因素進行優(yōu)先級算法排序，指導(dǎo)高效漏洞整改。

要實現(xiàn)漏洞管理的目標(biāo)，需要制定工作方針，漏洞管理方針是“全面保障，預(yù)防為主，綜合治理，分級管控”。

1. “全面保障”：漏洞管理應(yīng)確保全面發(fā)現(xiàn)資產(chǎn)漏洞
2. “預(yù)防為主”；漏洞管理主要工作是預(yù)防漏洞產(chǎn)生
3. “綜合治理”：漏洞管理應(yīng)該是多方參與協(xié)同治理
4. “分級管控”：漏洞處置應(yīng)做好分類分級科學(xué)處置。

通過對漏洞管理目標(biāo)和方針的分析，做好漏洞管理的道就是節(jié)源開流。節(jié)源，是減少漏洞的產(chǎn)生來源；開流，則是加大漏洞的整改力度。

預(yù)防漏洞是節(jié)源，是一場細雨，潤無聲，于無聲處見真章；

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

漏洞管理是企業(yè)網(wǎng)絡(luò)安全管理中最基礎(chǔ)的工作，重要性毋庸置疑。

但如何節(jié)源？又如何開流？

第三部分 術(shù)與節(jié)源

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

一、制定漏洞管理規(guī)范

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

制定漏洞管理規(guī)范能為漏洞管理提供指導(dǎo)性意見、方法和統(tǒng)一標(biāo)準(zhǔn)，規(guī)范應(yīng)明確漏洞管理原則、職責(zé)分工、等級評估、處置標(biāo)準(zhǔn)、修復(fù)風(fēng)險評估和修復(fù)過程控制等。

相同的漏洞在不同資產(chǎn)上的風(fēng)險是不同的，所以漏洞管理規(guī)范應(yīng)明確漏洞風(fēng)險等級評估標(biāo)準(zhǔn)，明確漏洞二次定級規(guī)則。

具體實踐可根據(jù)資產(chǎn)網(wǎng)絡(luò)屬性、重要級別以及漏洞原始等級進行。如：漏洞風(fēng)險等級積分（S）=漏洞初始風(fēng)險等級基礎(chǔ)因子（X）*系統(tǒng)級別權(quán)重因子（Y）*網(wǎng)絡(luò)邊界類別基礎(chǔ)因子（Z）

表2：漏洞風(fēng)險等級積分矩陣表

二、制定安全檢查規(guī)范

提高漏洞發(fā)現(xiàn)能力，擴寬漏洞發(fā)現(xiàn)來源，是做好漏洞管理的技術(shù)前提，漏洞發(fā)現(xiàn)能力低下的漏洞管理注定只是自我欣賞的表演。

建立安全檢查規(guī)范，明確各類系統(tǒng)變更或上線前的安全檢查要求，能提前發(fā)現(xiàn)和處置漏洞，也是預(yù)防漏洞產(chǎn)生的重要手段。

表3：系統(tǒng)變更前安全檢查矩陣表

對于新建外包開發(fā)系統(tǒng)，安全人員可在設(shè)計評審前收集SBOM，對使用的開源組件合規(guī)和漏洞情況進行評估審查，明確需要整改的組件，提前發(fā)現(xiàn)和預(yù)防組件風(fēng)險，做到安全左移。

安全檢查流程大體如下：

圖2：安全檢查流程圖

三、組織落實

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

可建立漏洞管理職責(zé)清單，明確各負責(zé)人在漏洞管理相關(guān)職責(zé)，除履行職責(zé)范圍內(nèi)的漏洞修復(fù)以外，還承擔(dān)如下具體職責(zé)：

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

表4：漏洞管理工作中職責(zé)表

四、建立基線版本庫

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

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

2、建立通用軟件庫，明確操作系統(tǒng)、數(shù)據(jù)庫、中間件、基礎(chǔ)軟件等通用軟件的類型、基線版本，并根據(jù)威脅情報，每年評估、更新和發(fā)布通用軟件庫的種類和版本。

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

4、對于必須使用低于基線版本軟件的系統(tǒng)，上線前應(yīng)發(fā)起OA簽報流程經(jīng)部門負責(zé)人審批后方可上線。

5、各類軟硬件產(chǎn)品基線版本庫責(zé)任劃分如下：

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

表5：基礎(chǔ)軟硬件版本管理責(zé)任表

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

1、建立應(yīng)用系統(tǒng)、開發(fā)組件、操作系統(tǒng)、數(shù)據(jù)庫、中間件、基礎(chǔ)軟件等安全配置指南，上線前指定專人按照指南配置，并經(jīng)他人確認、復(fù)核后方可上線。

2、實施運維標(biāo)準(zhǔn)化建設(shè)，實現(xiàn)日常流程標(biāo)準(zhǔn)化、操作系統(tǒng)標(biāo)準(zhǔn)化、中間件標(biāo)準(zhǔn)化、應(yīng)用部署標(biāo)準(zhǔn)化、集成發(fā)布標(biāo)準(zhǔn)化、監(jiān)控指標(biāo)標(biāo)準(zhǔn)化、日志規(guī)范標(biāo)準(zhǔn)化。

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

六、漏洞修復(fù)知識庫

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

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

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

4．漏洞修復(fù)知識庫的建立來源主要如下:參考漏洞掃描設(shè)備的標(biāo)準(zhǔn)解決方案作為基礎(chǔ)；利用多方威脅情報數(shù)據(jù)，錄入更多的解決方案作為參考；人工定期整理已驗證過的漏洞修復(fù)方案作為權(quán)威標(biāo)準(zhǔn)方案。

5．開發(fā)、測試、運維人員可以自助學(xué)習(xí)漏洞知識庫的內(nèi)容，了解漏洞原理及修復(fù)方法，當(dāng)開發(fā)在開發(fā)某功能時，可以查看會出現(xiàn)哪些漏洞。如：登錄、注冊、密碼找回等。

6．互聯(lián)網(wǎng)系統(tǒng)大版本升級前進行一次開發(fā)安全技術(shù)培訓(xùn)，并定期從漏洞知識庫中抽取內(nèi)容組織開展開發(fā)安全開發(fā)技術(shù)培訓(xùn)、安全測試培訓(xùn)。

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

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

第四部分 術(shù)與開流

節(jié)源是未雨綢繆，目的是預(yù)防和減少漏洞的產(chǎn)生，但不能避免新漏洞的威脅。當(dāng)存量資產(chǎn)命中新漏洞后，漏洞修復(fù)成了必然的選擇。

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

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

本部分的理念是以全面的資產(chǎn)發(fā)現(xiàn)為基礎(chǔ)，以數(shù)據(jù)存儲和治理為核心，以多源采集為提升，以漏洞優(yōu)先級為衡量基準(zhǔn)，以管理體系為抓手，實現(xiàn)全網(wǎng)資產(chǎn)、漏洞的全面、閉環(huán)管理。

一、漏洞發(fā)現(xiàn)能力建設(shè)

（一）漏洞來源分析

做好漏洞管理工作的前提是能發(fā)現(xiàn)風(fēng)險、檢測出漏洞，本部分不探討0day漏洞的發(fā)現(xiàn)和處置，僅分析常規(guī)漏洞。

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

而滲透測試、攻防演習(xí)等才是漏洞發(fā)現(xiàn)能力建設(shè)需要持續(xù)投入和保持技術(shù)迭代更新的。

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

圖3：漏洞來源圖

應(yīng)采取技術(shù)和管理手段逐步擴大漏洞發(fā)現(xiàn)力度和深度，擴大自主主動發(fā)現(xiàn)漏洞比例，深化定期檢測效果。

如滲透測試服務(wù)，可采取多家供應(yīng)商競爭比賽、交叉檢驗的方式，有條件、公司允許的的還可以采取SRC提高漏洞發(fā)現(xiàn)能力。

如攻防演習(xí)服務(wù)，可采取按發(fā)現(xiàn)漏洞的效果付費模式，或引入多家同時比拼，運動式的一年多次開展。

但這種運動式的演習(xí)并不能檢驗企業(yè)常態(tài)化網(wǎng)絡(luò)防守能力，故可以采取無人防守干預(yù)的分批演習(xí)模式，固定演習(xí)目標(biāo)，防守方無人值守，演習(xí)后攻防雙方面對面復(fù)盤攻擊和防守情況，檢驗企業(yè)日常安全防護的有效性。

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

（二）漏洞檢測左移

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

在項目設(shè)計階段，將安全需求納入需求管理，對系統(tǒng)的SBOM、安全需求對標(biāo)結(jié)果進行評審，提前發(fā)現(xiàn)組件漏洞，并確保安全需求的執(zhí)行；

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

在項目SIT階段，部署IAST插樁節(jié)點，進行交互式漏洞檢測，提前發(fā)現(xiàn)web和組件漏洞；

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

（三）漏洞檢測常態(tài)化

制定資產(chǎn)測繪和漏洞掃描方案，針對互聯(lián)網(wǎng)邊界等重點區(qū)域的加大掃描密度，如每周、每月，非重點區(qū)域的以滿足合規(guī)為目標(biāo)，可以每季度掃描一次。

檢測內(nèi)容	頻率	執(zhí)行方式
互聯(lián)網(wǎng)資產(chǎn)測繪	每周	定時任務(wù)
網(wǎng)銀區(qū)內(nèi)網(wǎng)資產(chǎn)測繪	每月	定時任務(wù)
內(nèi)網(wǎng)資產(chǎn)測繪（全覆蓋）	每季度	定時任務(wù)
內(nèi)網(wǎng)POC漏洞巡檢	每月	定時任務(wù)
漏洞掃描	每季度	手工執(zhí)行+現(xiàn)場值守

表6：漏洞檢測工作表

二、漏洞分類

漏洞管理的范圍包括通過手工或自動化工具發(fā)現(xiàn)的應(yīng)用軟件（web、app、SDK）、開發(fā)語言、開發(fā)組件、通用軟件（操作系統(tǒng)、數(shù)據(jù)庫、中間件、基礎(chǔ)軟件）等的漏洞。包括但不限于行內(nèi)、行外安全評估、檢測發(fā)現(xiàn)的漏洞以及第三方通報的漏洞。

基于目前行業(yè)態(tài)勢及管理需要，漏洞分為四類：IP類、web類、組件類、合規(guī)類。

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

表7：漏洞分類表

三、漏洞分級

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

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

表8：漏洞分級表

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

綜合分級為以技術(shù)分級為基礎(chǔ)，綜合影響范圍、被利用成本、修復(fù)難度等環(huán)境因素后得出的綜合風(fēng)險等級，更客觀地為漏洞修復(fù)提供了參考依據(jù)。

表9：漏洞綜合分級表

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

三、漏洞管理目標(biāo)

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

漏洞管理的目標(biāo)是建立一套流程化、規(guī)范化、數(shù)據(jù)化的漏洞管理機制，實現(xiàn)漏洞全生命周期閉環(huán)管理，對web漏洞、主機漏洞、組件漏洞、合規(guī)漏洞進行系統(tǒng)化、流程化管理。

圖4：漏洞管理目標(biāo)圖

基于以上工作目標(biāo)，總體實施設(shè)計如下：

圖5：漏洞管理設(shè)計方案圖

四、平臺架構(gòu)設(shè)計

漏洞管理平臺是資產(chǎn)、漏洞的統(tǒng)一管理平臺，也是漏洞檢測任務(wù)的統(tǒng)一掃描平臺，通過其建立掃描任務(wù)，自動執(zhí)行掃描，實現(xiàn)漏洞的集中化管理。

漏洞管理平臺架構(gòu)設(shè)計如下：

圖6：漏洞管理平臺架構(gòu)圖

架構(gòu)中重點需要運營的有3個資產(chǎn)庫和3個漏洞庫，資產(chǎn)庫包括IP庫、Web庫、組件庫，漏洞庫則包括主機漏洞庫、Web漏洞庫和組件漏洞庫。

IP庫應(yīng)包括IP資產(chǎn)的操作系統(tǒng)版本、IP、端口、網(wǎng)絡(luò)分區(qū)、所屬環(huán)境、網(wǎng)絡(luò)邊界類型、中間件及版本、服務(wù)信息、數(shù)據(jù)庫及版本等等。

Web庫應(yīng)包括該站點所有URL、API清單、Request、Response，API、URL可依賴API安全產(chǎn)品集成收集。

組件庫應(yīng)包括該應(yīng)用系統(tǒng)使用的所有開源組件名稱、版本、組件類型、開源協(xié)議類型、推薦版本、最新版本等等。

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

五、資產(chǎn)管理設(shè)計

資產(chǎn)管理架構(gòu)從上至下分別為組織架構(gòu)、應(yīng)用系統(tǒng)、資產(chǎn)、漏洞四個層次，漏洞依附于資產(chǎn)，資產(chǎn)屬于應(yīng)用系統(tǒng)組成，而應(yīng)用系統(tǒng)是歸屬不同組織下。

組織架構(gòu)：可設(shè)置為部門-中心-組架構(gòu)，或者集團-分公司-部門-組架構(gòu)。

圖7：漏洞管理組織架構(gòu)圖

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

圖8：應(yīng)用系統(tǒng)頁面展示圖

資產(chǎn)數(shù)量、漏洞數(shù)量則是應(yīng)用系統(tǒng)下不同類型的資產(chǎn)數(shù)量和對應(yīng)漏洞數(shù)量的整合展示，便于應(yīng)用系統(tǒng)負責(zé)人和安全人員快速了解應(yīng)用系統(tǒng)的整體安全態(tài)勢，也方便安全人員快速排查無資產(chǎn)的應(yīng)用系統(tǒng)。

資產(chǎn)：應(yīng)用系統(tǒng)下分IP類資產(chǎn)、web類資產(chǎn)、組件類資產(chǎn)，資產(chǎn)來源包括CMDB、HIDS等各類資產(chǎn)管理工具以及資產(chǎn)測繪、RSAS等各類漏洞檢測工具。

目前資產(chǎn)屬性包括：資產(chǎn)類型、應(yīng)用系統(tǒng)名稱、資產(chǎn)地址、資產(chǎn)名稱、資產(chǎn)負責(zé)人、資產(chǎn)來源、網(wǎng)絡(luò)環(huán)境、網(wǎng)絡(luò)邊界類型、資產(chǎn)狀態(tài)、漏洞優(yōu)先級以及其他自定義屬性及枚舉值。

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

圖9：資產(chǎn)管理頁面展示圖

漏洞優(yōu)先級為根據(jù)資產(chǎn)安全屬性、漏洞原始級別以及威脅情報經(jīng)過二次定級后的漏洞等級，展示的是該資產(chǎn)下現(xiàn)有漏洞情況。當(dāng)發(fā)現(xiàn)新漏洞需要錄入時可編輯該資產(chǎn)添加漏洞。

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

目前漏洞屬性包括：漏洞分類、應(yīng)用系統(tǒng)名稱（如有）、資產(chǎn)地址、漏洞名稱、漏洞級別（原始等級）、漏洞優(yōu)先級（二次定級）、漏洞來源、漏洞類型、漏洞描述、修復(fù)建議、修復(fù)期限、修復(fù)負責(zé)人、檢測詳情、發(fā)現(xiàn)狀態(tài)以及檢查名稱等其他自定義屬性及枚舉值。

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

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

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

六、管理流程設(shè)計

漏洞狀態(tài)共分為待派發(fā)、待確認、修復(fù)中、待復(fù)測、復(fù)測已通過、復(fù)測未通過、待審核、關(guān)閉。大致流程如下：

圖12：漏洞管理流程圖

待派發(fā)：同步、導(dǎo)入、錄入的漏洞初始狀態(tài)為待派發(fā)，需經(jīng)過安全人員驗證、審核后派發(fā)給整改責(zé)任人。

待確認：可將不是自己的漏洞轉(zhuǎn)辦給其他負責(zé)人，在此過程中需確認漏洞負責(zé)人是否準(zhǔn)確，漏洞是否誤報，是否修復(fù)，以及確認出修復(fù)方案。

圖13：漏洞確認圖

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

修復(fù)中：確認完成后即進入修復(fù)中，待修復(fù)后即可反饋已修復(fù)，之后進入安全人員的待復(fù)測環(huán)節(jié)。

待復(fù)測：復(fù)測結(jié)果如為復(fù)測通過的即進入上線環(huán)節(jié)或關(guān)閉，復(fù)測結(jié)果如為不通過則退回至修復(fù)中，直至復(fù)測通過。

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

關(guān)閉：經(jīng)確認為誤報、不修復(fù)、已修復(fù)的漏洞會處于關(guān)閉狀態(tài)。

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

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

2．整改責(zé)任人在漏洞整改完成后在漏洞管理平臺中標(biāo)注已整改，提請安全管理員進行復(fù)測，如果復(fù)測發(fā)現(xiàn)漏洞依然存在，則歸為修復(fù)失敗，對于修復(fù)失敗的漏洞重新轉(zhuǎn)換到漏洞發(fā)現(xiàn)狀態(tài)。

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

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

七、漏洞管理流程

發(fā)現(xiàn)漏洞是漏洞管理的基石，有效管理并快速響應(yīng)漏洞則是挑戰(zhàn)。

（一）資產(chǎn)/漏洞入庫

自動入庫：漏洞管理平臺對接了CMDB 、IAST、HIDS、RSAS等資產(chǎn)管理工具或漏洞發(fā)現(xiàn)工具，實現(xiàn)資產(chǎn)、漏洞的自動入庫，提高漏洞管理自動化水平；

手工導(dǎo)入：針對內(nèi)外部檢查檢查發(fā)現(xiàn)的非標(biāo)準(zhǔn)化問題，安全人員應(yīng)先對漏洞內(nèi)容進行初步確認，明確漏洞修復(fù)優(yōu)先級，并進行分工，再導(dǎo)入漏洞管理平臺。

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

（二）資產(chǎn)定級

在進行漏洞掃描或者資產(chǎn)同步時，可根據(jù)入庫IP自動賦值網(wǎng)絡(luò)分區(qū)、網(wǎng)絡(luò)邊界類型、主機環(huán)境等資產(chǎn)網(wǎng)絡(luò)屬性，同時繼承應(yīng)用系統(tǒng)的保護等級和重要程度。

 

圖14：資產(chǎn)屬性配置頁面圖

根據(jù)內(nèi)外網(wǎng)關(guān)聯(lián)清單，可快速查找互聯(lián)網(wǎng)邊界資產(chǎn)對應(yīng)內(nèi)網(wǎng)資產(chǎn)。

圖15：內(nèi)外網(wǎng)IP關(guān)聯(lián)頁面圖

（三）漏洞優(yōu)先級

權(quán)威報告顯示傳統(tǒng)的漏洞整改可能做了76%的無用功，僅有3%的漏洞應(yīng)優(yōu)先關(guān)注。

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

3%優(yōu)先漏洞：Tenable通過對20萬億漏洞情報等數(shù)據(jù)進行人工分析和機器學(xué)習(xí)后認為安全團隊?wèi)?yīng)該優(yōu)先關(guān)注的漏洞占所有漏洞的3%左右

圍繞漏洞可利用性和關(guān)鍵性對漏洞進行優(yōu)先級排序是開展漏洞管理的首要目標(biāo)。

主機漏洞的發(fā)現(xiàn)能力容易建立，攢漏洞掃描設(shè)備即可，但主機掃描產(chǎn)品、SCA工具掃描出的漏洞都是海量的，但從海量漏洞里如何確定漏洞的整改優(yōu)先級，這才是漏洞管理的核心，漏洞的優(yōu)先級技術(shù)至關(guān)重要。

漏洞的優(yōu)先級不僅僅只考慮資產(chǎn)安全屬性和漏洞本身屬性，還應(yīng)該考慮漏洞生命周期、漏洞情報以及漏洞標(biāo)簽等。

本方案中漏洞優(yōu)先級根據(jù)配置的風(fēng)險值自動自動賦值風(fēng)險優(yōu)先級，風(fēng)險值范圍和修復(fù)期限均可自定義，平臺會根據(jù)漏洞優(yōu)先級自動賦值修復(fù)期限。

圖16：優(yōu)先級設(shè)置頁面圖

風(fēng)險值的計算根據(jù)資產(chǎn)安全屬性、漏洞屬性、漏洞生命周期、漏洞情報屬性等綜合計算而來：

圖17：優(yōu)先級權(quán)重配置頁面圖

資產(chǎn)安全屬性可考慮的有：等級保護、重要等級、設(shè)備類型、資產(chǎn)狀態(tài)、網(wǎng)絡(luò)環(huán)境、網(wǎng)絡(luò)邊界類型等等。

 

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

圖19：漏洞屬性權(quán)重配置頁面圖

生命周期屬性包括漏洞發(fā)現(xiàn)方式、發(fā)現(xiàn)狀態(tài)、修復(fù)是否超期等，情報則包括是否有POC/EXP、網(wǎng)關(guān)防御規(guī)則是否有效等。

圖20：漏洞生命周期權(quán)重配置頁面圖

設(shè)置好各類安全屬性的數(shù)值，再使用平臺的風(fēng)險計量工具校驗和微調(diào)，直到不同類型的組合計算能滿足預(yù)期結(jié)果。如：

1、在線預(yù)發(fā)布、直接接入互聯(lián)網(wǎng)的資產(chǎn)命中超危漏洞，漏洞優(yōu)先級為高危。

圖21：漏洞風(fēng)險計算頁面圖

2、在線、預(yù)發(fā)布、非直接接入互聯(lián)網(wǎng)的資產(chǎn)命中超危漏洞，漏洞優(yōu)先級為中危

圖22：漏洞風(fēng)險計算頁面圖

（四）漏洞派發(fā)

漏洞優(yōu)先級確定好后，可根據(jù)漏洞標(biāo)簽、漏洞優(yōu)先級綜合考慮后將漏洞派發(fā)出去或者直接置為不修復(fù)。

對應(yīng)不同優(yōu)先級的漏洞可設(shè)置不同的修復(fù)期限、漏洞通知，根據(jù)漏洞優(yōu)先級設(shè)定的整改時限，設(shè)置修復(fù)計劃時間，修復(fù)計劃時間到期，自動發(fā)送郵件至系統(tǒng)負責(zé)人郵箱提醒，參考如下：

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

表10：漏洞修復(fù)規(guī)則表

漏洞派發(fā)前的關(guān)鍵工作包括：

1．如何實現(xiàn)漏洞管理自動化，如可以根據(jù)url/app名稱/ip/機器名自動匹配整改責(zé)任人。

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

3．如何實現(xiàn)漏洞分派的智能化，自動根據(jù)資產(chǎn)責(zé)任人、漏洞情況分發(fā)漏洞。

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

（五）漏洞督辦

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

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

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

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

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

圖23：漏洞通知頁面圖

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

在做漏洞督辦管理時的關(guān)鍵點包括：

1．漏洞修復(fù)數(shù)量化，需對修復(fù)漏洞數(shù)、修復(fù)漏洞耗時、修復(fù)漏洞成功率等漏洞修復(fù)成果進行統(tǒng)計和展示。

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

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

1、企業(yè)對漏洞治理工程的財務(wù)支持，以及相關(guān)單位對漏洞運營的技術(shù)支撐；

2、漏洞運營人員需要對企業(yè)網(wǎng)絡(luò)資產(chǎn)有清晰的認識；

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

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

第五部分 展望

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

如何快速響應(yīng)漏洞情報，快速定位受影響資產(chǎn)是亟需處理的技術(shù)問題，而這個問題的根源便是是否實現(xiàn)全面、深入的資產(chǎn)安全管理。

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

一、全面的資產(chǎn)安全管理

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

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

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

二、聯(lián)動的資產(chǎn)漏洞情報

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

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

基于漏洞庫數(shù)量較大，漏洞標(biāo)簽運營維護成本較高，各家仍存在標(biāo)簽體系混亂、標(biāo)簽內(nèi)容不準(zhǔn)的問題，希望未來能有更體系化、更具象化的漏洞標(biāo)簽，能夠?qū)崿F(xiàn)漏洞標(biāo)簽與優(yōu)先級自動化關(guān)聯(lián)定級。

三、更精準(zhǔn)化的組件漏洞檢測

截至目前，漏洞管理平臺僅接入了IAST檢測發(fā)現(xiàn)并經(jīng)確認需要修復(fù)的組件漏洞，暫未進行更深入的組件漏洞管理和運營。

組件漏洞的數(shù)量比IP類的會更多，海量組件漏洞里哪些需要先修復(fù)，做好VPT是關(guān)鍵。

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

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

1、資產(chǎn)安全屬性：是否互聯(lián)網(wǎng)系統(tǒng)、重要等級等；

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

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

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

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

來源：Pensecife