轉(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ì)開始考慮云安全的時(shí)候，漏洞管理團(tuán)隊(duì)卻依然想方設(shè)法流水化加速修復(fù)流程——但如果他們依然得手動(dòng)將幾十個(gè)工具中的數(shù)據(jù)進(jìn)行整理，顯然是無法實(shí)現(xiàn)的。另一方面，修復(fù)團(tuán)隊(duì)需要的是優(yōu)質(zhì)的數(shù)據(jù)，而不是大量的數(shù)據(jù)。
?數(shù)據(jù)而生的問題
如今的漏洞管理工具會(huì)收集一些基礎(chǔ)的數(shù)據(jù)，比如檢測(cè)到的漏洞數(shù)量、受影響資產(chǎn)、嚴(yán)重性等。這些只能讓安全團(tuán)隊(duì)監(jiān)測(cè)到最需要修復(fù)的東西，但是這些工具無法提供能夠提升修復(fù)成果的關(guān)聯(lián)信息。比較成熟的團(tuán)隊(duì)會(huì)使用電子表格或者商業(yè)智能工具追蹤一些數(shù)據(jù)矩陣，比如之前修復(fù)過的漏洞數(shù)量、依然存在的漏洞數(shù)量、以及最近一次掃描中發(fā)現(xiàn)的新漏洞數(shù)量。
雖然說這些數(shù)據(jù)也挺有用的，但是依然缺乏關(guān)聯(lián)性，因此很少能為修復(fù)工作提供一個(gè)整體的視角。舉例而言，它無法將一個(gè)漏洞的位置和受影響的業(yè)務(wù)單位關(guān)聯(lián)、無法報(bào)告修復(fù)一個(gè)漏洞所需要的真正時(shí)長(zhǎng)、也無法對(duì)漏洞修復(fù)優(yōu)先級(jí)提出意見。這種類型的信息，恰恰是改善漏洞修復(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ǔ)丁的RedHat盒子，這些信息并沒有告知受影響的具體產(chǎn)品、擁有者、或者對(duì)組織的重要性。這些漏洞是否有某些漏洞比其他漏洞會(huì)帶來更多風(fēng)險(xiǎn)?如果無法同時(shí)修復(fù)，哪個(gè)漏洞應(yīng)該得到更多關(guān)注?
另一個(gè)需要考慮的問題，在于因業(yè)務(wù)周期本身，產(chǎn)生的對(duì)受漏洞影響技術(shù)的依賴程度。舉例說明，許多零售商管會(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ù)決策。
接下來，修復(fù)團(tuán)隊(duì)需要理解某個(gè)修復(fù)會(huì)如何影響到業(yè)務(wù)運(yùn)營(yíng)。盡管說漏洞管理工具能夠給出修復(fù)的平均時(shí)長(zhǎng)，但是這個(gè)數(shù)據(jù)是基于每周的掃描得到的，依然缺乏關(guān)聯(lián)性。上周報(bào)告的哪些漏洞已經(jīng)被修復(fù)了?每個(gè)都花了多久修復(fù)?一天?五分鐘過?還是五天?
這些數(shù)據(jù)對(duì)于CISO們也是無價(jià)的。歷史數(shù)據(jù)可以顯示哪些平臺(tái)的修復(fù)時(shí)間更長(zhǎng)，以及相關(guān)原因。這些信息能幫助CISO們發(fā)現(xiàn)流程中的效率問題、產(chǎn)品脆弱性，甚至人員相關(guā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)人員等等，都使用不同的工具。
把這些問題聚集到一起，就是許多數(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ì)完全無視未儲(chǔ)存的數(shù)據(jù)點(diǎn)。比如，如果CISO詢問過去六個(gè)月修復(fù)了多少漏洞，大部分漏洞管理工具可能都沒有相關(guān)數(shù)據(jù)。
?我們能怎么做
要解決這個(gè)問題，需要?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é)人必須想辦法讓這些跨部門的人一起合作、訓(xùn)練。他們需要討論哪些數(shù)據(jù)是之后需要的，然后計(jì)劃如何收集和使用這些信息，從而提升修復(fù)效率，做到主動(dòng)漏洞修復(fù)。
最后，高效的收集、分析和處理數(shù)據(jù)，是使漏洞修復(fù)進(jìn)程更成熟的關(guān)鍵。無論是使用表格還是商業(yè)智能工具，修復(fù)團(tuán)隊(duì)都需要決定哪些數(shù)據(jù)矩陣是需要追蹤的，并且設(shè)定合理的KPI?；跀?shù)據(jù)設(shè)定目標(biāo)，能確保事情走在正軌上。
這一轉(zhuǎn)變是相當(dāng)艱巨的。不過，對(duì)于安全團(tuán)隊(duì)而言，艱苦可能是一種驅(qū)動(dòng)，沒有什么比沒有防住一個(gè)補(bǔ)丁就能解決的攻擊更讓人痛苦的了。
