轉載自微信公眾號“數世咨詢”（dwconcn）。

如今，漏洞管理團隊有海量的數據可以進行處理，而分析這些數據卻要花費和修復一樣長的時間。究其原因，是因為不同的工具只會提供解決隱患的一小部分數據。

在安全團隊開始考慮云安全的時候，漏洞管理團隊卻依然想方設法流水化加速修復流程——但如果他們依然得手動將幾十個工具中的數據進行整理，顯然是無法實現的。另一方面，修復團隊需要的是優質的數據，而不是大量的數據。

[[386257]]

▶ 數據而生的問題

如今的漏洞管理工具會收集一些基礎的數據，比如檢測到的漏洞數量、受影響資產、嚴重性等。這些只能讓安全團隊監測到最需要修復的東西，但是這些工具無法提供能夠提升修復成果的關聯信息。比較成熟的團隊會使用電子表格或者商業智能工具追蹤一些數據矩陣，比如之前修復過的漏洞數量、依然存在的漏洞數量、以及最近一次掃描中發現的新漏洞數量。

雖然說這些數據也挺有用的，但是依然缺乏關聯性，因此很少能為修復工作提供一個整體的視角。舉例而言，它無法將一個漏洞的位置和受影響的業務單位關聯、無法報告修復一個漏洞所需要的真正時長、也無法對漏洞修復優先級提出意見。這種類型的信息，恰恰是改善漏洞修復成果的基礎。

▶ 真正需要的數據

安全團隊不僅需要數據幫助他們基于業務風險對修復工作進行優化，還需要信息引導和推進流程的改善。真正需要的數據應該能幫助他們識別脆弱點，并且將修復的精力重新集中在最能影響自己最關鍵的業務的技術上。

舉個例子，如果掃描器在第七行代碼中發現了一個SQL注入漏洞，或者發現了一個需要進行補丁的Red Hat盒子，這些信息并沒有告知受影響的具體產品、擁有者、或者對組織的重要性。這些漏洞是否有某些漏洞比其他漏洞會帶來更多風險?如果無法同時修復，哪個漏洞應該得到更多關注?

另一個需要考慮的問題，在于因業務周期本身，產生的對受漏洞影響技術的依賴程度。舉例說明，許多零售商管會在購物季面臨更多的風險;而食品雜貨店由于每個月都會有新的產品，因此會在不同的IT和業務單元中改變優先級。在這些情況下，漏洞管理團隊需要更優質的數據，基于實時的業務需求進行修復決策。

接下來，修復團隊需要理解某個修復會如何影響到業務運營。盡管說漏洞管理工具能夠給出修復的平均時長，但是這個數據是基于每周的掃描得到的，依然缺乏關聯性。上周報告的哪些漏洞已經被修復了?每個都花了多久修復?一天?五分鐘過?還是 五天?

這些數據對于CISO們也是無價的。歷史數據可以顯示哪些平臺的修復時間更長，以及相關原因。這些信息能幫助CISO們發現流程中的效率問題、產品脆弱性，甚至人員相關問題，從而著手考慮如何解決。

▶ 困境為何難以突破

改善漏洞修復流程的最大困難，在于相關的數據都被分散在許多不同系統中：掃描器中的漏洞數據、配置管理數據庫或者資產庫中的業務數據，甚至某些數據只在一些特定的人員手中。另一方面，安全團隊可能在不同團隊部署了多個漏洞管理工具——比如掃描漏洞的、威脅情報團隊、IT運營人員等等，都使用不同的工具。

把這些問題聚集到一起，就是許多數據并不是由現有的工具所儲存的：比如，很少有組織會追蹤他們DevOps團隊發現漏洞、安裝補丁、檢查補丁是否生效所花的時間長度。即使他們對這些時間長度進行了記錄，也極少會將這個信息反饋給漏洞管理團隊。

還有，一些漏洞管理工具會完全無視未儲存的數據點。比如，如果CISO詢問過去六個月修復了多少漏洞，大部分漏洞管理工具可能都沒有相關數據。

▶ 我們能怎么做

要解決這個問題，需要創建改善修復成果所需的工作流和流程制度。這不是個簡單的事情。首先，漏洞修復團隊必須讓業務單元的擁有者參與其中，讓他們協助識別關鍵的業務功能點，以及資產之間的關系。將業務功能和相關的技術產品進行關聯，然后評估每個自查案的關鍵性，并且和漏洞管理項目結合。

下一步，安全團隊需要和DevOps團隊以及IT運營團隊合作，一起協同進行修復工作。這種關系會隨著時間的推移，成為安全團隊改善修復流程的關鍵。

然而，這樣的協作并不簡單。因此，安全團隊的負責人必須想辦法讓這些跨部門的人一起合作、訓練。他們需要討論哪些數據是之后需要的，然后計劃如何收集和使用這些信息，從而提升修復效率，做到主動漏洞修復。

最后，高效的收集、分析和處理數據，是使漏洞修復進程更成熟的關鍵。無論是使用表格還是商業智能工具，修復團隊都需要決定哪些數據矩陣是需要追蹤的，并且設定合理的KPI?；跀祿O定目標，能確保事情走在正軌上。

這一轉變是相當艱巨的。不過，對于安全團隊而言，艱苦可能是一種驅動，沒有什么比沒有防住一個補丁就能解決的攻擊更讓人痛苦的了。