网络安全 频道

企业客户端补丁管理框架

创建时间: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的方式,通过远程调用来实现信息收集和补丁分发。
0
相关文章