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

如今，漏洞管理團(tuán)隊(duì)有海量的數(shù)據(jù)可以進(jìn)行處理，而分析這些數(shù)據(jù)卻要花費(fèi)和修復(fù)一樣長(zhǎng)的時(shí)間。究其原因，是因?yàn)椴煌墓ぞ咧粫?huì)提供解決隱患的一小部分?jǐn)?shù)據(jù)。

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

[[386257]]

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

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

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

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

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

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

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

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

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

▶ 困境為何難以突破

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

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

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

▶ 我們能怎么做

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

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

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

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

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