补丁管理框架

第一章    前言
我们可以从公开的统计资料看到，在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种不同的划分，我们会发现，大量的威胁和漏洞分析工作这种工作还是需要由人工完成，部署补丁的决心和计划也需要人来作出。确实如此，软件不可能对企业的威胁和安全状况有一丝丝的理解，也不可能真正了解企业的需求，它们只适合做机械的信息收集工作和补丁分发工作。

[1] [2] [3]  下一页