第一章 前言
我们可以从公开的统计资料看到，在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
其他数据库
可以使用中文数据库
报告特性
提供的报告数量
报告是否可以图形化
报告是否可以订制
报告是否可以导出
是否提供中文报告