轉(zhuǎn)載自微信公眾號“數(shù)世咨詢”（dwconcn）。

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

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

[[386257]]

▶ 數(shù)據(jù)而生的問題

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

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

▶ 真正需要的數(shù)據(jù)

安全團(tuán)隊不僅需要數(shù)據(jù)幫助他們基于業(yè)務(wù)風(fēng)險對修復(fù)工作進(jìn)行優(yōu)化，還需要信息引導(dǎo)和推進(jìn)流程的改善。真正需要的數(shù)據(jù)應(yīng)該能幫助他們識別脆弱點，并且將修復(fù)的精力重新集中在最能影響自己最關(guān)鍵的業(yè)務(wù)的技術(shù)上。

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

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

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

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

▶ 困境為何難以突破

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

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

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

▶ 我們能怎么做

要解決這個問題，需要創(chuàng)建改善修復(fù)成果所需的工作流和流程制度。這不是個簡單的事情。首先，漏洞修復(fù)團(tuán)隊必須讓業(yè)務(wù)單元的擁有者參與其中，讓他們協(xié)助識別關(guān)鍵的業(yè)務(wù)功能點，以及資產(chǎn)之間的關(guān)系。將業(yè)務(wù)功能和相關(guān)的技術(shù)產(chǎn)品進(jìn)行關(guān)聯(lián)，然后評估每個自查案的關(guān)鍵性，并且和漏洞管理項目結(jié)合。

下一步，安全團(tuán)隊需要和DevOps團(tuán)隊以及IT運(yùn)營團(tuán)隊合作，一起協(xié)同進(jìn)行修復(fù)工作。這種關(guān)系會隨著時間的推移，成為安全團(tuán)隊改善修復(fù)流程的關(guān)鍵。

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

最后，高效的收集、分析和處理數(shù)據(jù)，是使漏洞修復(fù)進(jìn)程更成熟的關(guān)鍵。無論是使用表格還是商業(yè)智能工具，修復(fù)團(tuán)隊都需要決定哪些數(shù)據(jù)矩陣是需要追蹤的，并且設(shè)定合理的KPI。基于數(shù)據(jù)設(shè)定目標(biāo)，能確保事情走在正軌上。

這一轉(zhuǎn)變是相當(dāng)艱巨的。不過，對于安全團(tuán)隊而言，艱苦可能是一種驅(qū)動，沒有什么比沒有防住一個補(bǔ)丁就能解決的攻擊更讓人痛苦的了。