第一章    前言
我们可以从公开的统计资料看到，在2003年全球有80%的大型企业遭受了病毒感染而使得业务系统运作发生困难，即使这些大型企业已经具备了良好的边界安全措施，也普遍部署了病毒防御机制。造成困境的原因，一方面当然是由于现有防御体系的缺陷，是由于现有的边界防御、基于签名的入侵检测和防病毒系统从原理上就决定了其不擅长对付基于漏洞进行感染的病毒，单单具备这些措施，不足以遏制病毒的泛滥。另一方面，也恰好说明了企业需要一些应付这种情况的措施。在可能的措施中间，补丁管理这种措施得到了大家的特别关注，因为它的原理就是对软件进行修补从而消灭漏洞，从根本上杜绝了病毒利用漏洞的可能。这个原理很简单并且直截了当，容易为大家理解和接受。一些企业基于这样的考虑，不但把补丁管理纳入企业的安全体系而且还纳入审计范围，另一些企业更是把补丁管理的意义进行提升，使得补丁管理的意义已经超出了传统的安全防御范围，提升到企业信息系统正常操作必须具备的程度。
本文正是从这一点出发关注补丁管理。在这里我们不关心高深的补丁管理技术，也不研究漏洞的各种各样的危害，而且对重要服务器的特别需求也不关心。我们关心的是如何为企业网络上广泛存在的客户端有效地打上补丁，因为控制病毒的传播和危害需要修补漏洞。近来补丁管理热闹起来不就是因为这个理由吗？所以，在这里我们不讨论别的，仅就这个情况阐述我们的观点。
企业网络的客户端广泛采用Windows系列的操作系统，利用操作系统的漏洞进行感染则是病毒常用的手段，打补丁是必须的。造成管理困境的是企业在广大的范围内有数量众多的客户端，都需要及时为之修补漏洞，而且随着新的漏洞的发现还需要不断的重复这个过程。明显地，没有指导思想，没有管理框架，做好这样一件复杂的管理工作是不可能的，即使有了框架，依靠有限的人力做这件工作也是非常耗费资源的事情，无法保证及时，也很难确认工作的有效性。为此，企业希望能够找到一种补丁管理方法，及时有效的完成补丁管理工作是顺理成章的事情。

第二章    漏洞和补丁
我们知道，从信息安全这个层面看，是先有漏洞和对漏洞的攻击的可能性，才有补丁。漏洞是病毒攻击的目标，而打补丁正是对漏洞的修补过程。
漏洞和补丁的关系既然如此密切，我们应该看看软件厂商说法，并且考察一下在我们生活的现实环境中漏洞和补丁发布的顺序，这对了解什么是我们能做的和不能做的，以及极限在那里是有用的。
软件厂家通常将漏洞表述为软件的小缺陷，这些小缺陷可以通过补丁、软件升级或者更改配置予以纠正。这里我们留意到，在开发商的语境里这三个措施是并列的，打补丁并不是修补漏洞的唯一手段，替代不了软件升级，也替代不了配置更改，尽管目前看来是最重要的手段。虽然我们只讨论补丁管理，但是也应该牢牢记住它的限制。
在现实生活中，漏洞和补丁的发布已经形成了一个事实上的标准过程，稍微了解一下这个过程，可以使得我们知道补丁管理的切入点在那里，并且明白，在切入点之前，我们是做不了任何工作的。这个标准过程可以看作是一个依照时间先后串起来的若干个阶段组成的顺序过程，一般依照如下顺序：
1．    某些人或者组织进行研究并发现了一个漏洞；
2．    这个漏洞被提交给安全组织和厂商，等待确认并为开发补丁争取时间；
3．    漏洞确认并公布；
4．    补丁公布。
从这个顺序可以清楚地看到，在漏洞公布前我们做不了任何工作。在漏洞公布后，我们才知道这个漏洞的存在并可以着手评估其可能带来的威胁，而同一时间，攻击者也在试图利用这个漏洞和并开发恶意代码。但是直到补丁发布前，企业没有办法直接面对漏洞的威胁，只能采取一些其他的规避措施，尽量避免危险或者缩减可能的危害面积。补丁发布后，我们还需要一系列的动作才能为企业的客户端完成修补。
漏洞发布的时间、补丁发布的时间以及企业完成补丁部署的时间是有差异的。企业和攻击者，谁赢得了时间差异之争，谁就取得了对企业网络的控制权。但是事情不像表面看起来这么简单，漏洞公布后攻击者就可以开始行动了，而漏洞修补工作者必须等到补丁公布后才能开始，企业在时间上不占优势。从实际要完成的工作量说，攻击者只需要写出病毒就可以了，而企业在这段时间内，要完成包括漏洞影响评估，进行补丁测试、部署补丁以及对部署结果的确认等一系列的工作。这是一场非对称的游戏，只有建立严谨有效的工作流程才能在这严酷的环境下为企业带来一丝清凉。
时间差异有多重要？看一看xfocus.net的benjerry的这段话我们就明白了：“从一个漏洞发现到攻击代码实现，到蠕虫病毒产生，几年前可能是几个月甚至半年多，而现在几周甚至一天就可以完成。特别是近期，在微软发布MS04－011公告时，NGS的David在看到公告的8分钟后写出了攻击代码，Xfocus成员也在6小时内写出了通用的攻击代码。因此补丁管理也就需要有很强的及时性，如果补丁管理工作晚于攻击程序，那么企业就有可能被攻击，造成机密信息泄漏，比如去年9月份发生的Half Life2源代码泄漏事件就是由于企业内部的客户端没有及时打补丁，而导致被IE漏洞攻击，造成重大损失。”
第三章    补丁管理框架
很多企业对待补丁采取宁多勿缺的态度，其实心中没底，于是又提出这样的态度好不好的问题，事情大可不必如此，既然采取了这种态度，照着走下去就可以了，遇到困难可以找办法克服，心中存着犹豫和怀疑是不能办好事情的。
宁多勿缺的态度用在补丁管理上，通常会产生2个困难：一个是无谓的部署补丁会消耗大量的资源；一个是担心部署补丁后发反而产生新问题。第一个困难很好解决，因为补丁管理最消耗资源的地方是部署补丁，对每一个需要部署的补丁都会重复一次消耗资源的部署行动，其实只要将这个机械的重复行动抽出来自动化，就可以使得消耗资源的多少与部署补丁的次数脱钩，喜欢部署多少次补丁都可以，代价是需要一套自动化的补丁部署工具。
第二个困难没有很好的办法，只有老老实实的对每一个将要部署的补丁进行测试，确保其符合企业的生产环境，不会产生冲突或者至少找到避免的办法。不过，这个困难准确地说，与采取宁多勿缺的态度无关，无论采取什么态度，这要这个态度是理性的，是为了企业的利益着想，必然都要求对补丁进行测试，那些纯粹依靠厂商的想法，一厢情愿的以为厂商能够保证补丁没有问题