解析漏洞管理的五個階段
很多人應該都記得2003年“蠕蟲的一年”，在那年的1月25日，我們看到了SQL Slammer蠕蟲攻下了整個美國的自動提款機，同時感染了全球范圍內數百萬臺個人電腦和服務器，該蠕蟲病毒利用了微軟SQL服務器中的漏洞，事實上，微軟早在攻擊發生前的六個月就已經發布了這個修復程序。
當年晚些時候，Blaster蠕蟲病毒則利用了一個月前剛剛修復的漏洞。這種趨勢越來越明顯：發現漏洞和利用漏洞的惡意軟件出現之間的時間越來越短。隨著而來的是，漏洞管理新時代的誕生，企業們瘋狂地掃描他們的網絡查找有漏洞的設備。
在信息安全領域經常就是這樣的情況，只有在真正發生嚴重事故后，才會采取行動。隨著Slammer和Blaster的出現，IT安全部門就能夠拿出令人信服的案例來說服管理層部署企業級別的網絡掃描技術，從而發現和報告漏洞風險的狀態。所以我們部署來自Foundstone、nCircle、Qualys和Rapid7等供應商的工具。
這些漏洞管理工具能夠向我們提供關于連接網絡的端點以及資產資源狀況的情報信息。事實上，存在太多數據，需要花一些時間來整理優先事項以及考慮如何向企業內的負責方報告。不過現在我們就能夠對這些情報信息和數據作出反應了。
不過，擁有漏洞數據還只是解決了一半問題。另一半問題是進行修復，為此，我們需要獲得IT部門其他團隊的幫助。面臨的挑戰：我們如何讓支持團隊認識到問題的存在，并且需要讓他們明白，他們必須在漏洞被利用前迅速修復漏洞。
在本文中，我們將分析漏洞管理的五個階段，并提供一些建議來如何到達最后一個階段：即接受漏洞管理。
1. 拒絕。 “掃描結果是不準確的，在你的掃描結果中存在誤報(沒有漏洞卻說有漏洞)”
拒絕通常只是個人(或者支持團隊)的暫時抵抗。為了度過這個階段，你必須讓支持團隊將注意力放在積極行動上。換句話說，將他們認為是錯誤的項目暫停，讓他們將重點放在他們贊同的項目上。這將能夠讓工作繼續進行下去，而不是讓他們懷疑漏洞結果。
2. 憤怒。 “這是誰的錯?是你提出進行這些掃描的更高請求嗎?”
很多支持部門會對于結果所有權的偏離表示憤怒，質疑掃描他們網絡中設備的權利。要度過這個階段，你最好獲取足夠的和可證明的預先授權，再對這些網絡進行掃描。這可以通過更改控制過程進行確認，但這通常涉及對掃描次數的協商，可以通過獲取高層的授權來進行掃描。
3. 爭吵。 “真正的風險是什么?你可以將掃描工作延遲到下一個季度嗎?因為我們太忙了。我不明白!”
第三階段涉及某些個人(或者支持團隊)希望能夠以某種方式推遲或者拖延不可避免的掃描。風險所有者和修復職責是這個階段的主題。要度過這個階段，你必須確定掃描對業務的影響以及考慮自上而下地進行掃描。確認依存關系和定義移除障礙的責任是關鍵的成功因素。
4. 沮喪。 “我一直都保持及時修復補丁，但新的漏洞總是讓我們舉手無錯，我似乎無法取得任何進展!”
在第四階段，支持團隊開始明白可能出現新漏洞的必然性，以及問題的嚴重性。在這個階段，支持團隊將會需要你的支持。他們將會想知道他們的努力確實取得了成果。一個有用的策略就是確保你的掃描和報告過程采取了風險規避和降低風險評分作為關鍵指標。換句話說，如果你可以量化這些良好修復工作，那么支持團隊將可以開始接受這樣的事實，即成功只需要一次努力，但是不斷進行修復才能獲得長期的成功。
5. 接受。 “一切都會好起來，雖然我可能不能打敗它，但是我可以全面做好準備。”
在這個最后階段，終于獲得了支持團隊的理解，并且對于漏洞管理，他們將更好的集中在風險問題上。一旦支持團隊意識到這是一個長期持續的工作，并且掃描結果實際上是幫助識別風險區域，他們通常都愿意部署更有意義的程序更改，而且更能夠幫助保護在其控制下的資產。
最后請注意：在這些階段中出現倒退是很正常的現象，但只要你充分地理解了這些行動背后的動機，你將能夠幫助支持團隊最終接受漏洞管理。如果可能的話，在評估過程的初期階段讓責任方參與以幫助接好在所有這些階段中的負面影響。
原文出處：http://safe.it168.com/a2011/0119/1151/000001151959.shtml
【編輯推薦】
