漏洞管理的定義與最佳實踐
漏洞管理(VM)是每個全面資訊保安專案的必備基礎，不是什麼可選項。事實上，很多資訊保安合規、審計及風險管理框架都要求公司企業擁有並維護好漏洞管理專案。
如果你還未購置漏洞管理工具，或者你的漏洞管理專案只是臨時設定的，那麼馬上專設一個漏洞管理專案應該成為你的首要任務。實際上，網際網路安全中心(CIS)的第三號關鍵安全控制就倡議將持續漏洞評估與緩解作為風險與治理專案的組成部分。
如果你仍認為漏洞管理策略不過是戰術性運營工具，或許你可以重新考慮一下。漏洞管理應該成為你安全專案的重要基石。
一、漏洞管理定義
無規矩不成方圓，沒定義雞同鴨講，要確保大家討論的是同一件事，就得先明確討論主題的定義。漏洞管理過程一項持續的資訊保安風險事業，需要多方面的管理督導。漏洞管理主要由4個高階過程組成：發現、報告、優先化及響應。強漏洞管理框架中，每個過程和子過程都是著重改善安全和減少網路資產風險的持續週期的一部分。
二、漏洞管理最佳實踐
- 以發現和再發現管理漏洞
發現過程是要找出網路資產，並加以分類和評估。關於資產的資訊應按資料型別分類，比如漏洞、配置、補丁狀態、合規狀態或者僅僅是資產庫存。
發現過程應找出網路上的每個計算資產(沒錯，就是每一個)，並建立起其他漏洞管理過程可使用的知識庫。由於網路不停在變，資產資訊也需持續更新。
- 報告，報告，報告
發現過程中找出的資料通常以各種不同的形式報告給相應的受眾。報告過程應建立饋送至漏洞管理過程的優先順序矩陣。畢竟，每個漏洞的原始資料未必都那麼有用。理想狀態下，這些報告應能為戰術性運營任務所用，而在較高層級可為高層管理提供可見性及面向業務的風險指標。
三、優先順序最重要
優先化是根據預定義特徵集排序已知風險的關鍵漏洞管理過程。舉個例子，優先化應引發這樣的思考過程：面對來自發現過程的當前資產狀態、該特定資產的價值及已知威脅，風險到底有沒有重要到我們應花費資源去緩解？或者，該特定資產當下的已知風險是不是公司可接受的？
優先化的目標是要用漏洞管理工具建立一張自定義的事件處理順序表。理想狀態下，該經過優先排序的動作列表被饋送到標籤系統共IT運營使用，讓系統管理員據此執行特定任務。
四、風險響應
風險響應是漏洞優先化過程的下半場。基本上，風險響應是企業選擇來解決已知風險的方法(注意：無視風險並非響應方式之一)。
解決風險的方法分為3類：修復、緩解，或是接受。修復可以理解為修正已經發現的錯漏。比如說，因為忘了打補丁而導致的漏洞，就可以通過安裝補丁程式來加以修復。
另一方面，緩解是通過採取一些基本不在受影響系統直接管轄範圍之內的其他動作來減輕風險。比如說，針對系統上發現的Web應用漏洞，不是去修復漏洞，而是去安裝一個Web應用防火牆。漏洞依然存在，但有了Web應用防火牆，風險也就消弭了。
接受風險則是選擇既不修復也不緩解，單純承認並接受風險的存在。舉個例子，安全運營團隊可能會建議實驗室裝置執行防毒軟體。但公司利益相關者卻會因殺軟可能影響工程測試用例而選擇不採用殺軟。這種情況下，公司選擇接受已知風險。
五、範圍之內，範圍之外
取得對漏洞管理包含內容及其重要性的共識後，就可以接著討論有什麼東西不屬於漏洞管理轄下的了，因為似乎很多人對此不甚清楚。
- 滲透測試不在漏洞管理範圍內
漏洞管理不是滲透測試。有產品掃描公司系統並不意味著公司就有了滲透測試工具。事實上，情況正好相反。漏洞管理掃描器往往檢查的是某個補丁是否安裝之類的特定情況存不存在。
而滲透測試工具實際是要嘗試使用預定義的漏洞利用程式突破公司系統。雖然兩種型別的測試最終交出的結果可能都是同樣的建議，但達成這些結論的途徑卻有很大不同。如果想要進行良好的滲透測試，你需要的可能不僅僅是一個工具。滲透測試詳盡繁複，包括物理測試和麵對面的交談以及其他很多東西。
- 配置漏洞管理
雖然很多漏洞管理系統能與配置管理系統協作，但兩者之間還是存在很大不同。事實上，CIS對此有很多論述。漏洞管理覆蓋與系統配置和風險標記相關的問題，而系統配置的運營與管理則是配置管理程式的特殊部分。
六、定義持續漏洞管理
漏洞管理資料的狀態取決於最後一次更新的時候。與審計類似，報告的資料僅與最近一次評估相關。建立最相關資料集的關鍵在於定期執行漏洞管理程式。對某些公司而言，這個頻率是每天或每週。一個季度一次更新是談不上什麼持續不持續的，一年一次評估更是與持續搭不上邊，因為我們都知道，網路變化的速率會讓年度資料在一年中的11個月裡都是無用的。
七、應該做的和不應該做的
漏洞管理只是安全專案的其中一部分，解決不了整個風險管理問題。漏洞管理是安全專案的基礎，只有全面瞭解自家網路上都有些什麼，才能有的放矢。如果連網路上有些什麼都不知道，又何談保護？你還得理解網路上每個資產各自的面臨的風險，才可以有效確定優先順序並加以修復。