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