创建时间：2004-09-10
文章属性：原创
文章提交：edwin1111 (e.chen_at_rmgasia.com)

企业客户端补丁管理框架

版本1.10 （文章前3章润色修改）
作者：陈延 叶展均

目        录
第一章    前言    1
第二章    漏洞和补丁    2
第三章    补丁管理框架    4
第四章    对框架的考察    9
第五章    补丁管理软件测试    10
第六章    补丁管理产品简介    15
IBM Tivoli    15
LANDesk    17
SMS    19
SUS    20


第一章    前言
我们从公开的统计资料可以看到，在2003年全球有80%的大型企业遭受病毒感染而使得业务系统运作受到干扰，即使这些大型企业已经具备了良好的边界安全措施，也普遍部署了病毒防御机制。造成困境的原因，一方面当然是由于现有防御体系的缺陷，是由于现有的边界防御、基于签名的入侵检测和防病毒系统从原理上就决定了其不擅长对付基于漏洞进行感染的病毒，单单具备这些措施，不足以遏制病毒的泛滥。另一方面，也是由于基于漏洞进行感染的病毒传播速度极快，以至来不及采取措施，病毒就已经大规模爆发了。这恰好说明企业需要一些应付这种情况的措施，最好在病毒前面就消灭漏洞隐患，杜绝病毒传播的可能，补丁管理就是这一思想的产物，因为它的原理就是对软件进行修补从而根本上消灭漏洞，杜绝了病毒利用漏洞的可能。这个原理很简单并且直截了当，容易为大家理解和接受，因而得到了普遍的关注。一些企业基于这样的考虑，不但把补丁管理纳入企业的安全体系，而且还纳入审计范围；另外一些企业甚至认为，补丁管理的意义已经超出了传统的安全领域，成为维护企业信息系统正常操作所必须具备的措施。
本文正是从这一点出发关注补丁管理，在这里我们感兴趣的是，企业网络面对利用漏洞进行感染的病毒这样一种重大威胁，如何对感染的主要对象------企业网络上广泛存在的客户端有效地打上补丁，如何建立合适的补丁管理框架；在这里我们不关心高深的补丁技术，也不研究漏洞的各种各样的危害，而且对重要服务器补丁管理的特别需求也不关心。
企业网络的客户端广泛采用Windows系列的操作系统，利用操作系统的漏洞进行感染则是病毒常用的手段。对漏洞进行修补的困难主要有2个：
1．    及时为企业分布广泛数量众多的客户端修补漏洞；
2．    随着新的漏洞不断发现，对每一个可能造成重大安全隐患的漏洞，都有必要重复一次这种修补过程。
明显地，没有好的指导思想和管理框架，做好这样一件复杂的工作是不可能的；单纯依靠人力资源来做不但耗费资源而且枯燥无味，无法保证及时性，也很难确认工作的有效性。为此，采用好的管理思想，建立合适的补丁管理框架，引进合用的补丁管理产品就是必须的。
第二章    漏洞和补丁
我们知道，从信息安全这个层面看，漏洞和补丁的关系是先有漏洞才有补丁，如果不是有了漏洞以及可能的攻击，补丁是不会出现的。所以，从这个意义上说，漏洞是在先的，而补丁是在后的，补丁依赖于漏洞而存在。
漏洞和补丁的关系既然如此密切，我们应该看看软件厂商说法，并且考察一下在我们生活的现实环境中漏洞和补丁发布的顺序，这对了解什么是我们能做的和不能做的，以及极限在那里是有用的。
软件厂家通常将漏洞表述为软件的小缺陷，这些小缺陷可以通过补丁、软件升级或者更改配置予以纠正。这里我们留意到，在开发商的语境里这三个措施是并列的，打补丁并不是修补漏洞的唯一手段，替代不了软件升级，也替代不了配置更改，尽管补丁管理目前看来是最重要的手段。所以，我们明白了补丁管理的第1个限制，它替代不了软件升级和配置更改。
在现实生活中，漏洞和补丁的发布已经形成了一个事实上的标准过程，稍微了解一下这个过程，可以使得我们知道补丁管理的切入点在那里，并且明白，在切入点之前，我们是做不了任何工作的。这个标准过程可以看作是一个依照时间先后顺序串起来的若干阶段组成的过程：
1．    某些人或者组织进行研究并发现了一个漏洞；
2．    这个漏洞被提交给安全组织和厂商，等待确认并为开发补丁争取时间；
3．    漏洞确认并公布；
4．    补丁公布。
从这个顺序可以清楚地看到，在漏洞公布前我们做不了任何工作，这是补丁管理的第2个限制。在漏洞公布后，我们才知道这个漏洞的存在并可以着手评估其可能带来的威胁，而同一时间，攻击者也在试图利用这个漏洞和并开发恶意代码。但是直到补丁发布前，企业没有办法直接面对漏洞的威胁，只能采取一些其他的规避措施，尽量避免危险或者缩减可能的危害面积，这是补丁管理的第3个限制。补丁发布后，我们还需要一系列的动作才能为企业的客户端完成修补。
漏洞发布的时间、补丁发布的时间以及企业完成补丁部署的时间是有差异的。企业和攻击者，谁赢得了时间竞争，谁就取得了对企业网络的控制权。但是事情不像表面看起来这么简单，首先，漏洞公布后攻击者就可以开始行动了，而企业必须等到补丁公布后才能真正开始部署补丁，企业在时间上不占优势。其次，从实际要完成的工作量说，攻击者只需要写出病毒就可以了，而企业在这段时间内，则要完成包括漏洞评估，补丁测试、部署补丁以及对部署结果的确认等一系列的工作；依照目前的情况看，病毒发布的时间还是比补丁发布的时间迟一些，但是留给企业的实践已经不多了，只有2个星期左右。这是一场非对称的游戏，只有建立严谨有效的工作流程才能在这严酷的环境下为企业带来一丝清凉。
时间竞争的残酷看一看xfocus.net的benjerry的这段话我们就明白了：“从一个漏洞发现到攻击代码实现，到蠕虫病毒产生，几年前可能是几个月甚至半年多，而现在几周甚至一天就可以完成。特别是近期，在微软发布MS04－011公告时，NGS的David在看到公告的8分钟后写出了攻击代码，Xfocus成员也在6小时内写出了通用的攻击代码。因此补丁管理也就需要有很强的及时性，如果补丁管理工作晚于攻击程序，那么企业就有可能被攻击，造成机密信息泄漏，比如去年9月份发生的Half Life2源代码泄漏事件就是由于企业内部的客户端没有及时打补丁，而导致被IE漏洞攻击，造成重大损失。”
第三章    补丁管理框架
企业安全的外在动力来自于现实的威胁，不过，当企业不得不寻求某种管理机制来认真对待这一威胁的时候，就有了将安全管理纳入企业管理机制的要求，这外部的动力就转换成了企业内部的安全动力，安全真正成为管理上的要求；这种需求与头疼医头、脚疼医脚的安全需求是完全不同的，因为已经与企业的业务和管理体系相融合。
当企业决定推行补丁管理的时候，我们说，企业有了决心，只是这种决心必须来自高层；下层管理人员的决心是不能够成为企业的决心的；每个企业对IT的依赖程度不同，病毒能够造成的影响也不相同，这样，企业对待补丁管理的态度应该也不相同，但是，现实中的多数企业采取宁多无缺的态度。
很有意思的是，很多企业采取了宁多勿缺的补丁管理态度，但其实心中是没底的，于是又提出这态度到底是否正确的问题，其实事情大可不必如此，既然采取了这种态度，那么就不要犹疑，当作绝对正确，照着走下去就可以了，遇到困难可以找办法克服，自然能够走出一条道路，到了山穷水尽的时候，总是能够找到柳暗花明的；心中存着犹豫和怀疑是不能办好事情的。
宁多勿缺的态度用在补丁管理上，通常会产生4个困难：一个是无谓的部署补丁会消耗大量的资源；一个是担心部署补丁后发反而产生新问题，甚至导致企业某些应用软件失效；一个是难以确认补丁部署的效果，如果有疏漏，难免造成隐患；一个是部署完补丁后如果发现问题，如何处理，如果回到当初。其实我们将补丁管理的过程按照时间顺序划分为若干个阶段，仔细厘定各个阶段需要完成的工作，并且对各项工作仔细加以考察，就可以很容易地解决问题。
第一个困难产生的原因是部署补丁非常消耗资源，每一次部署都要对整个企业的全部客户端重复一次部署行动；但是，这个部署过程很清楚是重复性的，而且是可以标准化的工作，只要将这个机械的重复行动抽出来自动化，就可以使得补丁部署的次数与消耗资源的多少脱钩，喜欢部署多少次补丁都可以，代价是需要一套自动化的补丁部署工具。
第二个困难是担心部署补丁后发反而产生新问题，甚至导致企业某些应用软件失效。对这个困难没有很好的办法，只有老老实实的对每一个将要部署的补丁进行测试，确保其符合企业的生产环境，不会产生冲突或者至少找到避免的办法。不过，准确地说，这个困难是任何一种补丁管理都无法避免的，与采取宁多勿缺的态度无关；这个困难更多的来源于那些纯粹依靠厂商的想法，一厢情愿的以为厂商的补丁都没有问题，以为厂商能够提供足够的保证，这种想法都是错误的，最终对企业负责的不是厂商，而是企业自己。因此，企业无论对待补丁管理采取什么态度，只要这个态度是理性的，是为了企业的利益着想，必然都要求对补丁进行测试。
第三个困难是难以确认补丁部署的效果，如果有疏漏，难免造成隐患。如果企业依照科学的规律办事情，必然要求在部署完补丁后确认补丁部署的效果。如果是用人工来完成这个工作，不但工作量巨大，而且由于人总是趋向于犯错误，收集数据的可靠性和可信性都得不到保证，但是使用自动化的部署工具就能够很好地解决这个问题，自动化的部署工具能够在部署完成后自动的收集数据用于确认。
第四个困难是部署完补丁后如果发现问题，如何处理，如果回到当初。这个困难等于提出部署完成后的回滚问题，如果由人工来完成，几乎是不可能的，但是使用自动化工具就可以做到。
企业有了决心和态度还是不够的，还要有方法以及指导思想。一来可以统一的组织和协调行动，二来可以规范补丁管理，三来还可以发展出对规范的约束标准和评价标准。这样就可以使得补丁管理走上科学的管理道路。
我们认为，补丁管理是一个基于时间顺序组织起来的由若干阶段组成的过程。在企业环境下，会对其所要完成的目标，达成目标的手段等都有所要求和限制。这就需要有一套管理方法来支持这种管理，不依规矩不成方圆。
如果我们深入考察一下补丁管理过程，补丁管理可以看作是以某种思想作为指导的，在一个管理框架的支持下的安全实践。补丁管理框架由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        
其他数据库        
可以使用中文数据库        
报告特性        
提供的报告数量        
报告是否可以图形化        
报告是否可以订制        
报告是否可以导出        
是否提供中文报告        




第六章    补丁管理产品简介
作为专业的安全公司，加安公司早在2002就开始关注补丁管理领域的解决方案。我们测试了在该领域中几乎所有具有代表性的产品，其中包括IBM的Tivoli，LANDesk的Management Suite，微软的SMS2003，SUS，PatchLink的Patchlink Update以及St.Bemard Software的UpdateExpert等等。经测试的产品虽然不是全部的补丁管理的产品，却很好的覆盖了该领域，遗憾的是对于Patchlink Update以及UpdateExpert这两个国外专业的补丁管理产品，虽然在功能非常强大也十分专著，但是由于中文支持问题。暂时无法在中文平台中正常使用。下面我们将对几个最有代表性的产品进行简单介绍。

IBM Tivoli
Tivoli配置管理器的软件分配功能允许您为您的企业部署软件以及系统补丁，对那些需要快速、集中地进行补丁部署的客户而言，它是一款关键的解决方案。软件部署生命周期包括很多步骤，而Tivoli配置管理器通过其阶段管理模式可以帮助您管理这些步骤。从打包、规划、管理到交付、安装、生成报告，Tivoli配置管理器在每个阶段都能为您提供所需的工具。
Tivoli Configuration Manager能让您对企业软件和硬件进行全面控制。它的软件分配模式能让您在中心点快速有效地为多个位置部署复杂的关键任务应用程序。系统部署完成之后，它的清单模式能自动扫描并收集企业中计算机系统的硬件和软件的配置信息。
Tivoli Configuration Manager使用的是由客户端，服务器，后台数据库，控制台组成的统一多层次的管理架构。架构图如下：

Tivoli软件分发采用策略(profile)的方式，在管理策略中制订需要完成的工作：当制订完策略后(Profile)，管理人员可以拖、放到相应对象的图标上，对象可以是一个管理节点、一群Windows2000的PC、一个部门的所有被管理节点等等，Tivoli Framework会根据策略被分发对象的不同属性来实施执行操作。Tivoli的补丁分发使用广域网优化技术，交易机制分发技术，多路分发技术三种核心技术。 分发流程图如下：

1.    对各个客户端安装补丁的情况进行资产收集，将未安装补丁的客户端作为分发的对象。
2.    创建相应的客户端组，对部署进行初步规划。
3.    自动创建微软安全补丁的软件包：Tivoli Configuration Manager自动对微软安全补丁进行打包
4.    自动分发微软安全补丁包：Tivoli Configuration Manager自动向未安装补丁的客户端分发安全补丁包。

Tivoli Configuration Manager主要功能包括：
1.    补丁管理
2.    软件分发
3.    资产管理
4.    操作系统“无接触”安装
5.    带宽优化，多点广播
6.    支持广泛的硬件类型
7.    扩展性强，能与企业目录结合。
8.    支持异构环境的管理



LANDesk
LANDesk成立于1985年，起源于LAN Systems公司，后被INTEL收购，成为英特尔的软件部门，2002年9月，由于软件业务的不断增长，INTEL联合风险投资商共同投资，LANDesk成为独立软件供应商。
LANDesk SOFTWARE作为IT桌面设备管理行业的领导厂商,开发和提供领先的桌面设备、服务器和移动设备管理的软件与服务。LANDesk管理套件作为一个完全集成的模块化软件，拥有IT资产管理、软件分发及修复、OS分发及配置迁移，软件许可监控、远程帮助以及补丁管理器、服务器管理器等多个模块和插件。这些模块能实现企业IT设备全生命周期管理并且在企业信息资源管理系统发生意外损失时，能将损失减少到最低点，同时最大程度的提高IT的投资回报。
LANDesk管理套件是“服务器-代理-控制台”三层架构软件， 代理分布在所有需要管理的终端桌面上，服务器和控制台可以安装在同一台服务器上，也可以分处于不同的物理位置。


补丁管理器能够依据业界标准的信息源主动的扫描所有联网资产：硬件、软件、网络地址、结构以及连接的PDA、打印机等外围设备，并对联网资产进行评估，安全漏洞能够直接在控制台上查看评估结果,并且按漏洞、平台、应用程序或者单独计算机来进行划分并帮助您自定义的应用程序、策略以及安全需要设计您的修补计划。LANDesk全球补丁服务中心提供所有补丁程序，一旦用户设定补丁修补计划，客户端从它那里得到与每个漏洞相关的补丁。LANDesk 管理套件已定义近100种各类型报表，能够随时以报表的方式展示所有资产信息，并与Crystal report紧密集成，由用户自定义报表类型。同时，LANDesk支持以WEB方式展示报表内容。
LANDesk产品主要功能
    保持最新的安全补丁和病毒更新
    高效的安装和维护桌面软件
    减少软件许可证的费用以及响应审计的要求
    降低支持中心费用
    自动的发现和管理软硬件资产
    向新操作系统迁移用户和配置信息




SMS
SMS是微软提供的面向企业的网络管理软件，它是基于Windows 2000动态目录管理，适用于大型企业。它能够协助系统管理员轻松收集企业内部计算机硬件配置和所安装的软件清单，准确判断哪些机器需要更新，哪些机器可以运行新的软件。SMS提供了远程故障处理工具，很大程度上减少企业维护成本。SMS提供160种报告模板，管理员可以根据需要生成所需的报告，协助管理员的系统文档管理。
  Systems Management Server 2003使用扩展的分布式、层级化体系结构。主要包括：主控站点服务器，辅助站点服务器，管理点，客户端访问点以及分配点。
主控站点服务器:负责对SQL Server数据库中的信息存储实施管理。
辅助站点服务器:主要充当所需维护水平较低的受控系统远程代理。
管理点:为高级客户端提供站点服务器接口。所有客户端策略都将通过管理点被传递给高级客户端。
客户端访问点:使用标准客户端的计算机将通过客户端访问点与它们的站点服务器进行通信。
分配点:任何Windows服务器均可充当分配点，因为这个角色仅负责基于Windows共享或通过前述BITS协议提交分配软件包。

使用SMS进行补丁管理主要四个步骤组成，评估，确认，计划，部署。
评估：通过SMS2003，管理员可以发现和盘点现有的资产，包括详细软硬件的版本和类型。检测资产的安全威胁和漏洞，确定软件更新非常好的的信息源，评估现有的软件分发基础结构，评估其操作效力。
确认：SMS2000使用Microsoft 基线安全分析器 (MBSA) 扫描漏洞。MBSA也可以扫描指定域中的所有计算机，以查找缺少的和已安装的软件更新。这些扫描结果可以用来确定和发现您环境中缺少的软件更新。您还可以使用 SMS 2003 中软件更新功能组件扫描并报告您的环境中缺少的和已安装的软件更新。SMS 2003的报告会显示一个列表，它列出了所有已经安装的或可以安装的软件更新以及它们的相关信息。它还列出了缺少软件更新的计算机数量，以及已经安装了软件更新的目标计算机数量方便管理员确认。
计划：规划补丁的分类以及优先级，使用分发软件更新向导程序，创建分发和安装软件更新所需的 SMS 程序包和并制定自动更新安装计划。
部署：使用 SMS 2003 的向导把生成程序包部署到相应的客户端，并使用报告确定计算机或目标组的更新部署是否成功。

SMS2003的主要功能：
    计算机资产管理
    自动软件及补丁分发
    集成及扩充了Active Directory
    移动支持与带宽管理
    远程管理
    强大的WEB报告功能


SUS
微软的Software Update Services (SUS) 是微软为客户提供的，致力于帮助用户对基于 WIN2000/XP/2003 等机器快速部署最新的重要更新和安全更新的免费软件。SUS由服务器组件和客户端组成。 服务器组件负责软件更新服务，称为 SUS 服务器，用于安装在公司内网的Windows 2000或Windows2003的服务器上。服务器提供通过基于 Web 的工具管理和分发更新的管理功能。而客户端组件就是微软的自动更新服务（Automatic Updates），负责接收从服务器中产品更新的计算机上运行。
使用SUS进行补丁管理也有四个步骤组成，评估，识别，计划，部署。
评估：SUS提供标准合并报告，管理员可以在报告的基础上进行评估。这些报告提供与 SUS 服务器联系的计算机列表，然后是这些计算机的操作系统、语言和服务包级的列表。报告还将识别计算机安装或丢失了哪些更新并确定服务器的正常运行。
确认：通过SUS管理工具允许管理员创建订阅。管理员使用订阅可以确定按照产品和分类哪些更新与 Windows Update服务器同步，可以设置自动同步 SUS 服务器的计划，创建计算机目标组以及确定要下载和安装到这些组的更新，运行预先部署检查和安排自动更新安装计划。
计划：设置自动同步 SUS 服务器的计划，创建计算机目标组以及确定要下载和安装到这些组的更新，运行预先部署检查和安排自动更新安装计划。
部署：通过 SUS 管理工具，管理员可以指定计算机的目标组并确定要部署到这些组的更新并要建立更新应用至产品的顺序。管理员最后使用报告确定计算机或目标组的更新部署是否成功。

SUS主要功能
1.    自动检测、下载和安装适用更新
2.    用户可用的计划和通知选项
3.    使用Microsoft 签名的特定内容
4.    扩展对包括 Office、SQL Server、Exchange 和硬件驱动程序在内的 Microsoft 产品的支持
5.    自动排列优先级和下载重要更新
6.    通过后台智能传输服务 (BITS) 技术提高带宽效率
7.    改进了报告能力，使管理员能够监视更新部署状态和服务器的正常运转
8.    SQL Server 引擎用作 SUS 2.0 数据知识库 http://netadmin.77169.com/HTML/20040923011500.html