第一章 前言
我們可以從公開的統計資料看到，在2003年全球有80%的大型企業遭受了病毒感染而使得業務系統運作發生困難，即使這些大型企業已經具備了良好的邊界安全措施，也普遍部署了病毒防御機制。造成困境的原因，一方面當然是由于現有防御體系的缺陷，是由于現有的邊界防御、基于簽名的入侵檢測和防病毒系統從原理上就決定了其不擅長對付基于漏洞進行感染的病毒，單單具備這些措施，不足以遏制病毒的泛濫。另一方面，也恰好說明了企業需要一些應付這種情況的措施。在可能的措施中間，補丁管理這種措施得到了大家的特別關注，因為它的原理就是對軟件進行修補從而消滅漏洞，從根本上杜絕了病毒利用漏洞的可能。這個原理很簡單并且直截了當，容易為大家理解和接受。一些企業基于這樣的考慮，不但把補丁管理納入企業的安全體系而且還納入審計范圍，另一些企業更是把補丁管理的意義進行提升，使得補丁管理的意義已經超出了傳統的安全防御范圍，提升到企業信息系統正常操作必須具備的程度。
本文正是從這一點出發關注補丁管理。在這里我們不關心高深的補丁管理技術，也不研究漏洞的各種各樣的危害，而且對重要服務器的特別需求也不關心。我們關心的是如何為企業網絡上廣泛存在的客戶端有效地打上補丁，因為控制病毒的傳播和危害需要修補漏洞。近來補丁管理熱鬧起來不就是因為這個理由嗎？所以，在這里我們不討論別的，僅就這個情況闡述我們的觀點。
企業網絡的客戶端廣泛采用Windows系列的操作系統，利用操作系統的漏洞進行感染則是病毒常用的手段，打補丁是必須的。造成管理困境的是企業在廣大的范圍內有數量眾多的客戶端，都需要及時為之修補漏洞，而且隨著新的漏洞的發現還需要不斷的重復這個過程。明顯地，沒有指導思想，沒有管理框架，做好這樣一件復雜的管理工作是不可能的，即使有了框架，依靠有限的人力做這件工作也是非常耗費資源的事情，無法保證及時，也很難確認工作的有效性。為此，企業希望能夠找到一種補丁管理方法，及時有效的完成補丁管理工作是順理成章的事情。

第二章 漏洞和補丁
我們知道，從信息安全這個層面看，是先有漏洞和對漏洞的攻擊的可能性，才有補丁。漏洞是病毒攻擊的目標，而打補丁正是對漏洞的修補過程。
漏洞和補丁的關系既然如此密切，我們應該看看軟件廠商說法，并且考察一下在我們生活的現實環境中漏洞和補丁發布的順序，這對了解什么是我們能做的和不能做的，以及極限在那里是有用的。
軟件廠家通常將漏洞表述為軟件的小缺陷，這些小缺陷可以通過補丁、軟件升級或者更改配置予以糾正。這里我們留意到，在開發商的語境里這三個措施是并列的，打補丁并不是修補漏洞的唯一手段，替代不了軟件升級，也替代不了配置更改，盡管目前看來是最重要的手段。雖然我們只討論補丁管理，但是也應該牢牢記住它的限制。
在現實生活中，漏洞和補丁的發布已經形成了一個事實上的標準過程，稍微了解一下這個過程，可以使得我們知道補丁管理的切入點在那里，并且明白，在切入點之前，我們是做不了任何工作的。這個標準過程可以看作是一個依照時間先后串起來的若干個階段組成的順序過程，一般依照如下順序：
1． 某些人或者組織進行研究并發現了一個漏洞；
2． 這個漏洞被提交給安全組織和廠商，等待確認并為開發補丁爭取時間；
3． 漏洞確認并公布；
4． 補丁公布。
從這個順序可以清楚地看到，在漏洞公布前我們做不了任何工作。在漏洞公布后，我們才知道這個漏洞的存在并可以著手評估其可能帶來的威脅，而同一時間，攻擊者也在試圖利用這個漏洞和并開發惡意代碼。但是直到補丁發布前，企業沒有辦法直接面對漏洞的威脅，只能采取一些其他的規避措施，盡量避免危險或者縮減可能的危害面積。補丁發布后，我們還需要一系列的動作才能為企業的客戶端完成修補。
漏洞發布的時間、補丁發布的時間以及企業完成補丁部署的時間是有差異的。企業和攻擊者，誰贏得了時間差異之爭，誰就取得了對企業網絡的控制權。但是事情不像表面看起來這么簡單，漏洞公布后攻擊者就可以開始行動了，而漏洞修補工作者必須等到補丁公布后才能開始，企業在時間上不占優勢。從實際要完成的工作量說，攻擊者只需要寫出病毒就可以了，而企業在這段時間內，要完成包括漏洞影響評估，進行補丁測試、部署補丁以及對部署結果的確認等一系列的工作。這是一場非對稱的游戲，只有建立嚴謹有效的工作流程才能在這嚴酷的環境下為企業帶來一絲清涼。
時間差異有多重要？看一看xfocus.net的benjerry的這段話我們就明白了：“從一個漏洞發現到攻擊代碼實現，到蠕蟲病毒產生，幾年前可能是幾個月甚至半年多，而現在幾周甚至一天就可以完成。特別是近期，在微軟發布MS04－011公告時，NGS的David在看到公告的8分鐘后寫出了攻擊代碼，Xfocus成員也在6小時內寫出了通用的攻擊代碼。因此補丁管理也就需要有很強的及時性，如果補丁管理工作晚于攻擊程序，那么企業就有可能被攻擊，造成機密信息泄漏，比如去年9月份發生的Half Life2源代碼泄漏事件就是由于企業內部的客戶端沒有及時打補丁，而導致被IE漏洞攻擊，造成重大損失。”
第三章 補丁管理框架
很多企業對待補丁采取寧多勿缺的態度，其實心中沒底，于是又提出這樣的態度好不好的問題，事情大可不必如此，既然采取了這種態度，照著走下去就可以了，遇到困難可以找辦法克服，心中存著猶豫和懷疑是不能辦好事情的。
寧多勿缺的態度用在補丁管理上，通常會產生2個困難：一個是無謂的部署補丁會消耗大量的資源；一個是擔心部署補丁后發反而產生新問題。第一個困難很好解決，因為補丁管理最消耗資源的地方是部署補丁，對每一個需要部署的補丁都會重復一次消耗資源的部署行動，其實只要將這個機械的重復行動抽出來自動化，就可以使得消耗資源的多少與部署補丁的次數脫鉤，喜歡部署多少次補丁都可以，代價是需要一套自動化的補丁部署工具。
第二個困難沒有很好的辦法，只有老老實實的對每一個將要部署的補丁進行測試，確保其符合企業的生產環境，不會產生沖突或者至少找到避免的辦法。不過，這個困難準確地說，與采取寧多勿缺的態度無關，無論采取什么態度，這要這個態度是理性的，是為了企業的利益著想，必然都要求對補丁進行測試，那些純粹依靠廠商的想法，一廂情愿的以為廠商能夠保證補丁沒有問題的想法都是錯誤的，最終對企業負責的不是廠商，而是我們自己。
我們認為，有了部署補丁的動力（病毒威脅/審計要求），有了部署補丁的決心和態度還是不夠的，還要有方法以及指導思想。一來可以統一的組織和協調行動，二來可以規范補丁管理，三來還可以發展出對規范的約束標準和評價標準。這樣就可以使得補丁管理走上科學的管理道路。
我們認為，打補丁是一個基于時間順序組織起來的由若干階段組成的過程，在企業網絡這一特定的環境中，會對這一過程的管理有特殊的需求和限制，對要達到的效果也有明確的要求，這就需要有一套管理方法來支持這種管理，不依規矩不成方圓嘛，我們可以再進一步，將這套管理方法看作是有一種管理框架來支持，而具體的補丁管理工作看作是在這個框架指導下的實踐。補丁管理框架由3個層次的東西組成：
第一個層次是指導思想和操作模型，奠定了補丁管理的理論框架和操作方式；
第二個層次是一些公認的最佳實踐，這些成功經驗為理論框架和操作模型填充了血肉，使得補丁管理的整個架構具備可操作性，并且在某種程度上為打算采用它們的企業提供了有效性和可靠性保證；
第三個層次是企業自身的安全實踐，以及通過自身的實踐經驗對公認的模型和最佳實踐的剪裁和改造，這樣，就使得整個架構能夠更好的適應企業的補丁管理需求。良好的補丁管理其實也是一種依賴于經驗的成功實踐。
在這里我們不關心具體的實踐，不是提供機械的、不可變動的工作程序和規定，而是考慮為企業建立起一種管理框架，在這框架下，可以填充公認的經過檢驗證明有效的方法、工作流程和規定使得補丁管理框架變成具備可操作性的補丁管理，這種補丁管理最后還要根據企業具體境況和企業自身的安全實踐經驗剪裁，才能形成貼切的適合企業具體情況的補丁管理。需要注意的是，填充的東西隨著時間的推移可以不斷更新，管理框架因為理念的進步也可能過時。這里并沒有一貫正確的方法，能夠有的最多只能是被大家承認的最佳安全實踐而已。
一個企業要想制定并且成功的實施補丁管理，應該吸收一切有益的經驗，清楚地了解漏洞和補丁管理各個階段的問題，并在仔細分析企業的補丁管理需求的基礎上，依據這個框架，設計出適合企業管理架構的流程，走出自己的成功實踐。

普遍的看法是將補丁管理過程看成一種生命周期模型，一個封閉的循環。上面借用了微軟的圖形來說明這種生命模型。在這種模型中，一個循環的完成意味著新的循環的開始，新的循環繼承了前一個循環的成果并在這個基礎上有所提高。
循環的過程分成評估、識別、計劃和部署4個部分，對每一個新的漏洞以及相應的補丁都要放在這個循環里面進行考察。
1. 評估階段------收集漏洞、補丁信息，收集企業資產信息并確定其價值，然后，在這個基礎上，評估漏洞對企業的威脅，還要對前一次的執行結果進行評估，給出修補漏洞的要求以及其他防護措施建議。
2. 識別階段------這個階段的工作依賴于評估階段收集的信息作為基礎，主要工作有下列內容：
a) 尋找補丁，并確定其來源可靠；
b) 測試補丁，以確定其能與企業IT環境兼容；
3. 計劃階段------給出在企業網絡部署補丁的詳細計劃安排。
4. 部署階段------根據計劃，在企業網絡內部署補丁并進行確認。
上面這個劃分適合企業從宏觀的角度把握補丁管理。但及時的部署補丁還是需要依靠自動化的工具來完成才有可能。
人工部署補丁有幾個困難是不能克服的，一個是成本高昂，對每一個需要部署的補丁都人工在成千上萬臺客戶端上部署一次，成本顯然是不可能降下來的，一個是不能滿足及時性的要求，這一點是顯然的，無需多說，一個是部署效果得不到保證，人總是須向于犯錯誤的，誰能保證為10000臺客戶端部署補丁的時候沒有疏漏，一個是部署效果得不到確認，人工部署沒有一個有效的公正的方法確認部署的效果。
因此，必須設想一個自動化的程序，可以幫助我們完成這些工作，能夠及時、安全、可靠的完成補丁部署工作，而且還能提供可信的數據確認部署的效果，這就是補丁管理程序的初步設想。為了適應現在基于策略的企業安全管理------這種管理方式有著天然的集中管理特征，我們的補丁管理程序還需要添加一個要求，就是能夠集中管理，集中控制策略和補丁的分發，還要能夠集中的收集信息以確定客戶端的補丁狀態信息，為部署補丁和確認效果提供依據。對于補丁管理程序，企業還會要求具備靈活的軟件架構以方便部署，現在得到廣泛應用的成熟架構是三層的軟件架構，這個我們也要添加，另外，企業在意的日志和報告也必須有。通過這些添加后，我們對的補丁管理軟件的要求就初現倪端了。
補丁管理軟件的細節和軟件架構我們不打算多談，就此打住。我們在意的是補丁管理軟件只能按照我們的規定來執行機械的重復性的步驟，那么，我們將前面建立的補丁管理框架中適合自動化管理的部分抽取出來，交給補丁管理軟件完成，不但可以完好的符合我們的補丁管理模型，而且，還極大地提到了補丁部署效率，增加部署的可靠性和可確認性。
我們抽取出來的適合交給補丁管理產品完成的部分，通過我們的組合，也可以劃分為4個階段，并符合生命周期模型：
1． 信息收集和掃描------從可信的來源取得補丁信息，掃描客戶端取得企業客戶端的補丁情況信息，注意，這里軟件通常不關心漏洞信息以及完整的客戶端資產信息；
2． 人工確定需要安裝的補丁------由于在安全補丁前軟件無法確定補丁是否適合企業的IT環境，這個步驟通常需要人工干預；
3． 制定安裝計劃------需要人工制定補丁分發計劃，并在軟件中做好相應的設置；
4． 下發并確認------由軟件自動下發補丁并確認成功與否。
比較上面2種不同的劃分，我們會發現，大量的威脅和漏洞分析工作這種工作還是需要由人工完成，部署補丁的決心和計劃也需要人來作出。確實如此，軟件不可能對企業的威脅和安全狀況有一絲絲的理解，也不可能真正了解企業的需求，它們只適合做機械的信息收集工作和補丁分發工作。
 

從這里我們也可以看出，期望單單可靠產品和技術來彌補管理上的缺陷是不可能的，因為他們不是一個層次的東西。雖然，技術能夠在某種程度上掩蓋管理問題和延緩暴露的時間。
第四章 對框架的考察
補丁管理框架依據的思想是生命周期模型，這個模型有自己的限制，我們不能說由于這個模型有著自我改善的能力，每一個循環都能吸收上一個循環的成果并有所改進，就因此得出結論------我們可以從一個荒唐的起點開始通過不斷的改善達到較為安全的程度。
因此，應用這個模型要求一個合理的開始，以便在初始就將這個循環帶入大家公認的比較安全的狀態并有能力步入良性循環。所以，這個模型適合與安全產品配合使用，例如：微軟、IBM、patchlink等公司的補丁管理產品使用的就是這種模型。另外，這個模型也適合用于指導企業建立補丁管理架構，條件是尋找一些成功的案例（最佳實踐）作為參考和起點，通過這個添加，這個模型就能夠為需要不斷重復和改進這樣一種補丁管理機制提供合適的思想。
因為生命周期模型是一種修補模型，所以能夠產生一種對現有措施的不斷的改進和修補，但是不能指望它會產生一種全新措施來適應重大的變革，當安全威脅發生重大改變或者安全觀念發生重大更新后，整個安全局面就可能面臨大變動，這種模型不適合應付這種局面。
補丁管理框架的階段劃分不是一成不變的，因為，劃分的依據有著幾個要求：
1． 相似性------與現在的安全界的通常的看法相似，這樣才能保證溝通順暢，不會各說各話；
2． 實用性------使用這種劃分能夠很好的指導企業的補丁管理工作，清晰而不會造成混亂；
3． 應用豐富性------這種劃分能夠廣泛的使用而不會造成問題；
4． 簡單性------劃分必須盡量簡單，使人容易掌握和理解。
因此，從不同的層次和角度看待不定管理就會有不同的劃分方法，例如:前面我們就從宏觀和產品2個角度作了不同的劃分。
第五章 補丁管理軟件測試
補丁管理產品應該具備的幾個關鍵要素：
 及時------測試表明，在漏洞公布后1天內，就可以寫出利用這個漏洞的病毒。現在的實際情況是，在漏洞公布7天內，就可以出現在網上實際流行的病毒。因此，及時為企業的OS或者應用軟件打好補丁很關鍵，也正是補丁管理軟件的價值所在。
 簡單------補丁管理之所以成為企業安全管理的一個難題，很大一部分的原因是在于，在企業范圍內進行補丁管理需要牽扯很大的精力，還不一定能做好，這一方面與企業的IT部門力量有限有關，也在于企業為它所擁有的所有的機器的補丁狀態維持一個狀態表有很高的難度，所以，能夠提供簡單易行的補丁管理非常重要。
 正確-------由于補丁管理程序必須檢測客戶端的狀態，并判斷客戶端是否需要以及需要哪些補丁，這里我們既不希望漏打補丁，也不希望重復打補丁，因此，補丁管理程序給出正確的判斷十分重要。
 可靠------由于企業網絡環境的復雜性，我們不能想象軟件向客戶端分發補丁能夠有100%的成功率，那么，成功率越高，失敗后的補救措施越好，就越能夠提供可靠的補丁服務。
由于對補丁管理產品的需求主要基于這樣的事實：大量的Windows平臺需要及時、有效的貼上安全補丁。所以，我們對補丁管理產品的應用范圍主要鎖定在Windows平臺，在可能的情況下才兼顧UNIX系列平臺。當然，在Windows平臺上，我們希望產品能夠兼顧較為廣泛的范圍，在處理好OS安全補丁的前提下，兼顧OS非安全補丁、應用程序安全補丁、其他第三方程序補丁等。
產品結構
由于產品必須適應企業環境，那么，按照現有的成功經驗看，使用某種多層次的產品結構是恰當的選擇，按照成熟的做法，我們可以設想，至少應該分為3層：
 管理界面，管理員用于配置產品、查看日志、生成報表以及做其他日常操作的界面。管理界面應該具備分權管理的能力，使得企業可以為不同職責的管理員分配不同的管理權限，方便企業對軟件進行更精細的控制。
 服務器，是具體執行下載、存放和分發補丁程序，收集和存放日志，生成報表等功能的產品部件，接受管理員的配置并根據配置決定自身應該執行的功能。
 agent，用于收集客戶端信息并提交給服務器，也接受服務器分發的補丁并執行打補丁的動作以及向服務器匯報成功與否。也存在不使用agent的方式，通過遠程調用來實現信息收集和補丁分發。
測試限制
有一些重要的東西在我們的測試中不能完全體現出來，而這些東西可以影響產品在市場上的成敗：
 補丁分發的可靠性，由于產品自身的特性、網絡復雜性和客戶端情況的復雜性，不可能有100%的補丁分發成功率，但是成功度的高低和后續的補救處理方式等，對產品的可靠性影響非常大，而可靠性在很大程度上決定了一個產品的生命。例如：DLL版本的關聯、病毒或者蠕蟲對文件的改變等可能使得補丁管理程序不能正確判斷是否需要進行補丁升級，或者判斷正確但是進行補丁升級卻遭到失敗，在這個時候，就需要產品具備適當的補救措施或者至少給出日志并提供有益的建議。
 漏報和誤報問題，客戶端是否需要進行補丁升級，需要升級什么補丁，依賴于補丁管理軟件的檢測，由于客戶端OS軟件的版本眾多、補丁情況各異、操作環境的復雜以及DLL的依賴關系。檢測必然產生漏報和誤報問題，如果情況比較嚴重，特別是，如果在中文環境下情況比較嚴重，會影響客戶的補丁管理工作并且對軟件沒有信心。
 流量控制，這里主要關心的是如何避免在流量高峰期進行補丁升級，客戶端如何進行斷點續傳的問題。大型企業的網絡資源通常是緊張的，管理員非常關心如何對網絡帶寬進行合理的分配和利用，補丁管理產品作為一個輔助工具，理所應當能夠進行流量控制，為關鍵業務讓路。
 補丁升級執行故障，客戶端可能由于病毒或者蠕蟲感染等各種原因導致補丁升級失敗，失敗可能產生很多不良后果，特別是可能會產生僵死的進行，白白消耗客戶端資源，這些情況到底有多少，如何解決，應該有一個說法，否則，也會招致客戶端的抱怨。
 補丁管理程序自身的補丁問題，補丁管理軟件自身也是軟件，也有需要打補丁的可能，客戶不可能容許使用困難的方法來升級或者修補補丁管理程序，而會要求平滑的和自動化的升級和修補過程，并且會要求這個自動化的過程就是由補丁管理程序自身來完成。
 服務器與客戶端之間通信的安全性，補丁管理程序有2類通信，一類是與互聯網上存放補丁的服務器聯系，獲取補丁，這里關系到服務器安全和可靠的獲取補丁的問題，一類是服務器與客戶端通信，這里關系到客戶端能夠從服務器安全和可靠的獲取補丁的問題。
測試要素表
一個面對企業的補丁管理產品，除了關鍵功能外，必定需要適應企業網絡環境的補充功能，才能為企業提供合適的補丁服務和管理，因此，補丁管理產品測試要素表內容如下：

XXXX產品 XXXX產品
軟件版本
軟件安裝
在線幫助
產品架構
產品部署簡單性
產品部署伸縮性
分權管理
管理界面（MMC/WEB）
掃描方式
掃描定制
掃描精確性
定制客戶端組
失敗/回滾機制
中文的兼容性
是否需要域結合
基于agent
補丁管理
補丁下載
補丁存儲
補丁分發
支持OS補丁
支持應用軟件安全補丁
支持其他非安全補丁
支持軟件部署
支持定制的部署
支持系統重啟定制
支持補丁傳輸壓縮
支持補丁斷點續傳
補丁詳細的信息和分析
定制管理信息
支持中文平臺的補丁
其他
覆蓋面
支持Windows平臺
支持第三方軟件
支持UNIX
支持其他平臺
幫助支持
在線幫助
文檔、廠商支持
廠商自身實力
安全特性
服務器/客戶端加密連接
界面/服務器連接加密
對補丁的簽名/校驗
其它安全措施
數據庫種類
SQL server
Access
其他數據庫
可以使用中文數據庫
報告特性
提供的報告數量
報告是否可以圖形化
報告是否可以訂制
報告是否可以導出
是否提供中文報告