减小字体
增大字体- ·上一篇文章：Hosts文件在系统中的作用
- ·下一篇文章：揭开单向“Ping”通的奥秘
补丁管理框架
改进，就因此得出结论------我们可以从一个荒唐的起点开始通过不断的改善达到较为安全的程度。
因此，应用这个模型要求一个合理的开始，以便在初始就将这个循环带入大家公认的比较安全的状态并有能力步入良性循环。所以，这个模型适合与安全产品配合使用，例如：微软、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类通信，一类是与互联网上存放补丁的服务器联系，获取补丁，这里关系到服务器安全和可靠的获取补丁的问题，一类是服务器与客户端通信，这里关系到客户端能够从服务器安全和可靠的获取补丁的问题。
测试要素表
一个面对企业的补丁管理产品，除了关键功能外，必定需要适应企业网络环境的补充功能，才能为企业提供合适的补丁服务和管理，因此，补
因此，应用这个模型要求一个合理的开始，以便在初始就将这个循环带入大家公认的比较安全的状态并有能力步入良性循环。所以，这个模型适合与安全产品配合使用，例如：微软、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类通信，一类是与互联网上存放补丁的服务器联系，获取补丁，这里关系到服务器安全和可靠的获取补丁的问题，一类是服务器与客户端通信，这里关系到客户端能够从服务器安全和可靠的获取补丁的问题。
测试要素表
一个面对企业的补丁管理产品，除了关键功能外，必定需要适应企业网络环境的补充功能，才能为企业提供合适的补丁服务和管理，因此，补