2.5 漏洞管理程序故障
在继续讨论之前，必须要向初次接触漏洞管理的读者澄清一些漏洞管理中经常遇到的问题。漏洞管理不等同于渗透测试。漏洞管理仅是渗透测试的一个部分，它用来发现可能导致侵入内部计算机系统的漏洞。例如，一个漏洞扫描程序能够发现一台电子邮件服务器的某个漏洞，攻击者可以利用该漏洞将这台服务器当做跳板，以安全方式访问组织机构中的其他更关键的目标机器。渗透是利用漏洞获取其他系统访问权以及利用相关漏洞获取更高级别的未经授权的访问权的行为。
漏洞管理是一门学科。它需要有一致性、专业性，并需要不断地重新评估。虽然能够通过技术提高执行效率，但却无法回避下述事实：必须不断地对系统打补丁和调整系统配置来满足复杂而多变的商业需求。当公司启动一个准备不足的漏洞管理程序时，失败将如影随形。单纯的购买技术、运行软件，然后期待程序自身能完成一切是不可行的。下面，让我们来看看Acme公司的例子。
2.5.1 案例研究1：获得组织的支持
Acme公司在世界范围内拥有8个办公地点，总计15 000台工作站，130台服务器。其管理架构并不太复杂，从CEO开始，最多不超过3级。制造工厂位于中国，部分关键组件生产企业位于北美。公司增长稳健，大多数生产和销售人员都在不断增加。工程团队则是一个总部设在北美的封闭式机构。
该公司的IT运营高度分散，由各地的行政经理聘用IT经理进行管理。虽然各地行政经理（office manager）需要向全球运营总监（global operations director）汇报，但地方IT管理人员并不直接同全球IT运营总监联系。全球的IT预算虽不富裕但还算充足，一般都不包括员工培训费用，因为员工能力较强，能通过自学掌握大部分相关技术和处理流程。地方的IT预算是由当地行政经理结合本地IT经理的建议制定的。全球IT对网络基础设施，如WAN和LAN的配置等，负有总的责任。各地的PC机和服务器则由当地IT团队管理，但也需要遵循全球统一的标准。这种架构，使得全球IT处于为各地办公室提供网络服务和安全保障的地位，本地IT只需为本地商务需求（主要是销售和结算功能）提供支撑。
去年，一位IT员工由于没有获得年终奖（而他的同事却获得了），一气之下决定实施报复。他知道公司的大部分机器都没有打补丁，而他的计算机也连接在同样的网络中，他于是想通过修改震荡波蠕虫病毒（Sasser worm）的载荷，对特定的主机发起攻击，并将自己不喜欢却还获得了年终奖的同事的工作站作为攻击的目标。
不幸的是，震荡波病毒危害巨大且持久，导致好几个系统陷入瘫痪，并渗入到几台关键的服务器上。后来，法庭调查人员找到了攻击的来源。Acme公司花费了几个星期的时间来给这些机器打补丁以恢复服务。这场攻击严重影响了公司的生产，给公司造成了巨大的收入损失。这个员工因而被解雇了。
Acme公司安装了一套复杂的网络监视系统。同时，还购买并安装了一套补丁管理系统。一名日常负责电子邮件管理的IT职员自愿管理该系统。
首先，让我们来看看图2-1中的Acme公司的组织结构。这个结构看上去与常规不太一样但多年来一直提供着良好的服务。随着新技术的应用和基于互联网的日益密切的商业联系，技术战略总监和独立的IT运营总监的重要性逐渐凸显出来。随着安全问题逐渐成为企业关注的焦点，Acme成立了一个专门小组负责解决该问题。Ward是安全风险经理（security and risk manager），负责管理商业风险，他还是一个技术发烧友。他把这视为横向的职业发展，并在总部建立了一套入侵检测系统（IPS），每天都沉浸其中。
Harold是一个长期以来一直受到信赖的员工，他领导实施一个风险管理项目来避免发生上述的安全问题。Harold的直属主管是Ward。Harold彻底研究了市面上所有风险管理工具，通过与PC机管理员和服务器管理员进行讨论，最终选择了一个工具。Acme的8个办公地点都部署了相关设备，用于扫描漏洞。扫描从5月3日开始，下面是自5月3日起发生的事件的日志。
- 事件
5月3日：Harold主持了首次漏洞扫描，地点是旧金山办公室。令Harold感到意外的是，当地只有300名员工，但扫描程序却报告了4094台漏洞宿主机。拨打供应商的技术支持电话后，供应商检查了扫描程序的配置文件，运行了一些诊断程序，并试验性地扫描了几台机器，结果发现一切正常。供应商建议Harold核查一下网络配置，称也许是路由器将扫描包发送到了其他办公区域。
5月4日：Harold怀疑San Francisco的扫描器有问题，但没有同支撑团队争辩。也许扫描器设置了不正确的路由配置。但这里的网络配置同其他地方的配置一样。该问题在产品评估时并没有出现过。
全球信息经理（global messaging manager）通知Harold，如果不能保证不影响公司业务前，就不要扫描电子邮件服务器。因为电子邮件服务器需要按服务等级协议（SLA）进行维护。Harold有些不满，因为有几台关键服务器都是邮件服务器，其中还有几台接到互联网上，面临着更高等级的威胁。他将情况汇报给他的直属上级领导Ward，Ward告诉他不要在这个问题上引发争议，因为Harold在这一职位中是位新人，还需要取得其他技术经理的信任。
5月7日：对其他办公室的扫描结果看上去正常。当地的IT经理收到了初始的漏洞报告。
5月12日：第一周扫描结束后，总的宿主机数量有些高，但这种情况也能解释。Harold和所有的经理进行了后期电话沟通。
5月15日：旧金山办公室的扫描问题持续存在，仍然报告检测到4094台宿主机。芝加哥也显示同样多的宿主机数量。对扫描结果进行长时间仔细地检查后发现每一个被扫描到的IP地址都对应一台宿主机。
5月16日：总的来说，宿主机的平均漏洞个数急剧下降，这是个好消息，但是单个主机的最高漏洞个数依然不变，而有些主机的漏洞情况甚至变得更加糟糕。Harold发电子邮件给纽约地区的IT经理以寻求漏洞补救方面的帮助。
5月20日：进一步的研究表明，在每个地区，扫描器都发现了更多的宿主机，这导致了宿主机平均漏洞个数的减少。每个地区分公司都有4094台主机，已经超过了扫描器的扫描能力。此外，纽约的IT经理还没有回复Harold的电子邮件，于是Harold决定给他打个电话。这位经理解释说他正在对纽约的网络架构进行一项大的部署，有可能会对其初始的架构设计进行一些小的改动。他承诺一旦完成部署，就立刻看邮件。
5月31日：在技术支持下，Harold发现网络中有一些数据持续地发送到实际上并无主机对应的IP地址。解决该问题的应急方案就是手动输入所有活动的主机地址，但这是不切实际的，因为许多地址都是动态分配的。Harold需要找到到底是什么东西在响应设备发现探测器。
6月5日：所有报告的漏洞都未修复。Harold咨询了他的主管Ward，Ward建议召开一个本地IT经理参加的电话会议，但至少要再等一周Ward才能挤出一个小时的时间。
6月12日：应有8个地区的IT经理参加电话会议，但只有5个参加了。IT经理们说他们没有资源用于修复漏洞，但如果工作负荷允许，他们将每周尽力处理一次最高优先级的主机。电话会议上，一个IT经理向Ward提出，应该一次只部署一项新技术，而不是并行部署，这样IT经理们能够在下一次部署前评估该技术对整个公司带来的影响。IT经理们还抱怨没有通知他们要部署该漏洞扫描系统，并担心扫描程序会影响他们的网络工作性能。Ward同意扫描只在晚上进行。亚太产品经理在电话会议中也抱怨扫描导致他的一台关键服务器结点失效。由于亚洲的白天是美国的晚上，他表示不希望进行扫描除非Harold能够保证扫描不会影响系统。
6月16日：两个办公区中一些情况最糟糕的机器已被修复。剩下的IT部门员工花了一个周末来清除由于某个用户插入被感染的U盘而引入的一个新病毒。即便大多数台式电脑都处于关机状态，扫描仍然显示许多网络存在4094台主机。
6月23日：Harold忙于跟踪扫描程序的问题并继续补救行动。他发现新部署在防火墙内的一个入侵检测系统（IPS）导致了扫描器在每个IP地址上都显示有主机。他还做了个测试，关闭防护功能后进行扫描，这一次结果尽善尽美。Ward知道Harold关闭了某个办公点新部署的IPS后，口头训诫了Harold，告诉Harold应该先跟自己商量一下。他让Harold重新开启IPS，并将扫描集中到有固定IP地址且系统拥有者允许扫描的服务器上。Harold成功的向亚太区产品经理展示了扫描对服务器没有任何害处。于是亚太区产品经理同意扫描该区主机并同意一周内进行关键漏洞修复。
6月25日：漏洞扫描报告的结果并不乐观。由于IPS系统导致的IP对应的主机是实际存在的，因此漏洞评分情况并没有改善多少。走势图显示漏洞的数量仍呈上升趋势但并没有发现新的漏洞。Harold对此结果感到困惑，于是联系了产品线技术支持部门，报告了一个可能的缺陷，但技术人员说这是正常的行为表现。
6月30日：新的漏洞扫描系统扫描了公司范围内的25台活动主机。平均每台主机花费了400美元，大大超过了他的预期。大约17台主机得到了修复。
7月18日：公司的表现让Harold感到非常沮丧，他辞了职，决定去一个能“严肃对待安全问题”的公司找一份新工作。
那么，对Harold和Acme公司来说，到底发生了什么呢？Acme公司需要更多的人手吗？好像不是。Harold选择了错误的产品吗？好像也不是。他起初是一个乐观主义者，打算周密细致地完成好工作，但是问题很快地出现，并带来了更多的工作量，而只有极少数问题得到了修复。在缺少内部支持的情况下，系统的有效性和Harold都受到了质疑。
9月5日：致命一击。公司远程分部的一位员工被解雇了，他决定临走之时做出一些轰动的事情来。他知道公司的核心服务器系统是基于有缺陷的标准开发的，于是写了一个能够利用内部雇员常用的管理员密码的perl脚本发起攻击，最终对许多系统造成了损害。全球各地内的IT经理们都不知所措、尴尬无比。他们这才记起来应该有人负责实施漏洞管理才对，但为时已晚。
- 分析
那么，成功的漏洞管理程序到底需要些什么？本案例从一开始就充满了错误。让我们来看看是哪里出现了问题。
过程失败：过程中有两个问题。首先，缺乏正式完整的项目计划以及上级管理层的支持。首先Harold应先努力调研技术产品。第二，Harold缺乏对过程的重视。风险管理是一个过程，而不是一个技术解决方案。
准备：技术处理无疑是一个相当大的问题，好几件事都没有做好。Harold居然不知道防火墙内部署了一个IPS系统。漏洞扫描系统出来的分析报告也难于理解。而发送给IT经理的那些报告显然被忽视了，Harold很可能认为他们根本不关心，或是不理解这些报告。
相关人员：IT经理们显然没有参与项目的很多策划活动，并且对项目投入甚少。查看Acme公司的组织结构图（图2-1）会发现IT经理们只向全球IT运营总监汇报，不需要向同一级的组织（如Harold等）汇报，除非汇报到CIO的级别再向下下达。他们凭借对各自网络的理解，防护着自己的网络。当面对一项他们一无所知的新型网络防护技术时，他们感到对这些技术工具完全无法控制，于是他们对自己网络的保护就是将这些工具拒之门外。
责任人：Harold和Ward召开的与IT经理们交流的电话会议效果如何呢？在Harold看来，IT经理们的低出席率反映出了他们感兴趣的程度。但是，对一个忙于部署新技术（在本例中是IPS）并正在进行一项重要的网络设计变更的人来说，自然的反应是先把精力放在他所负责的事情上，回避那些会导致更多事情的工作。IPS是防火墙软件的一部分，因此被当做是一项已有技术的配置变化。此外，漏洞扫描器生成的报告也需要管理员承担更多的工作，因而搁置该报告能暂时延缓对计算机环境造成的影响。
如果Harold采取如下不同的做事方法，可能会有一个更好的结果：
责任人：初期就取得高层管理者的直接支持。确保管理者理解漏洞修复和监控的需求。如果没有迈出这重要的第一步，就没有明确的预期、对运营系统的影响也不可知。Harold就没有得到领导的大力支持，无法引起各地IT经理的重视。在计划、设计和选择技术过程中，IT经理们都没有参与，他们没有机会在自己的环境中去测试、验证该技术。同时，补救工作没有及时完成时，Harold也没有其他渠道将问题上报。此外，高层管理者能够促进团队中关键参与者之间的沟通。理想的情况是，由级别类似总部CIO、CSO（或CISO）的高级管理者一起讨论初次进行漏洞管理的重要性。
在高级管理层的承诺中，明确指出：成功的修复是一项关键的工作成果指标。在前面的例子中，Harold没能引起各地IT经理们的重视，他们几乎没有修复任何漏洞，因为这些提交的漏洞报告在他们看来就像是Harold在抱怨他们的系统多么不堪一击，而这将增加他们不认可的工作量。因此IT经理们根本就没有动力去修复漏洞。他们从未把Harold当做严峻的IT挑战的解决方案的提供者。而如果告知IT经理们将以修复漏洞的表现对他们进行考评，则他们将更愿意遵从。事实上，他们很可能会表现得更加积极主动。为了在大棒之外再加一根胡萝卜，设置最低平均漏洞分值的竞争可以让这一过程更加追求卓越。可以对取得最低平均漏洞分数或最大改进的IT经理实施额外的奖励。
准备：测试！测试！测试！任何联网的、能被任意访问的，并有可能被入侵的网络系统，其全部组件都应该在实际环境中进行充分测试。最终，形成一份可接受扫描的系统标准。扫描给系统带来的不良影响，以及被鉴定为不需接受扫描的系统，都应当清楚地记录并存档。
过程：任何管理上的变更都应该是深思熟虑后再实施的。在Harold的公司里，扫描检测开始前，内置了IPS的新防火墙系统已经进入实施阶段，当扫描检测开始时，旧金山办公室已经完成了该防火墙的部署。该防火墙为分配到该区域内的所有IP地址的探测扫描提供应答（本书后面将对该现象做更多介绍）。当Harold持续进行扫描检测时，该防火墙持续应答。如果Harold参与了变更管理过程，他就会知道公司正在部署防火墙，那么他就能够提前测试扫描效果，并将防火墙部署前后的扫描结果进行对比，找出差别。
2.5.2 案例研究2：技术集成的挑战
Abacus公司是一家跨国的电子计算器制造商和经销商。他们使用了液晶显示技术和一种特殊的手势识别技术，使得他们的电子计算器较传统计算器执行得更快。总的来说，Abacus公司就是一个拥有几项核心专利的快速发展的小型电子公司。
Abacus的制造厂位于内布拉斯加州和阿拉巴马州。Syllog是其在德国的一个商业伙伴，负责采购国外设备并进行配送。Syllog是多种独特电子设备的分销商，主要面向亚洲消费者以及美国和英国的小型零售商。大多数设备都只由三个制造商提供，Syllog公司在业务和基础设施上同这三家制造商保持着密切联系。Syllog公司约40%的基础设施由Abacus公司与它联合建设，并直接为Abacus公司服务。
在Abacus公司，IT基础设施建设非常成熟，拥有基于信息技术基础构架库（ITIL）的变更管理（change management）和事件管理（incident management）工具。其所有的商业伙伴都要遵守Abacus公司的政策和标准，或者采用更为严格的政策和标准。他们已经用ITIL框架中的基本模块实现了一个“服务台”（service desk）模型。该服务器是接收和管理事件、逐步升级处理的中心点。由于Abacus公司是一个制造企业，订单量难以预测，因此其生产都采用适时反应（just-in-time）策略。换句话说，他们只在接到订单后，根据订单的要求设计和生产产品。此外，公司承诺在接到订单的10个工作日内发货，因此决不允许任何原因导致的停工。
Abacus公司中与销售相关的IT操作都由当地专门的市场定制应用软件进行控制。每个市场都有不同的语言、不同的文化和独特的商业关系，因此相应地也需要不同的硬件、软件和应用程序。通用操作系统和基本的工具软件由全球IT运营部门提供和管理。但是，各种应用软件和特殊软件均由当地IT运营部门负责。为了保持这种运营模式，Abacus公司建立了专门的介于全球、地区IT运营团队之间的服务系统。
管理层决定下一步在整个公司实施一个全盘的漏洞管理试点计划。该计划涉及公司所有站点，还包括有意愿参加的商业伙伴们。Abacus公司内，PC主要使用微软操作系统，而服务器则使用Linux操作系统，只有部分办公地点使用Solaris操作系统。
除了清除漏洞之外，Abacus公司还希望通过这次的漏洞管理计划尽可能全面细致地对公司的应用软件进行合规性验证、补丁状态验证。他们拥有成熟的漏洞管理的内部流程，但其执行系统却没有什么技术支撑资源。技术支持工程师与员工比例为1∶300。对Abacus公司而言，自动化是一项关键因素。例如，在Linux系统上，每周就有20个标准系统维护和数据采集Shell脚本在运行，因此采用自动化的漏洞扫描而非依赖于内部流程是非常重要的。自动检测的实施，由系统工程部负责人Carl负责。
- 事件
11月2日：在高层领导的全力支持下，Carl组建了一个由系统支持组、PC工程师和网络总监组成的小团队来共同挑选工具软件、修订已有的流程。该项目获得了350 000美元的预算。
11月23日：在项目时限和预算范围内，该小组选择了两种工具，从运行结果上看，它们与各种系统配合得很好，包括PC和服务器代理上的网络漏洞扫描设备。最初的想法是让代理软件在所有系统中运行，但普通PC上已经安装了很多办公用的应用软件，再继续在其上安装代理软件并加以维护对PC的日常操作影响太大。考虑到代理软件对服务器操作影响较小，且服务器生成的报表还能提供集中的补丁修复信息列表等特殊信息，因此自动打补丁将能够减少工作量。合规性报告有助于管理者将精力集中在实现预期目标上。两种工具总计花费：330 000美元。
11月30日：工具软件采购完成，安装在了一台服务器上，硬件设备也已部署到所有需要部署的办公室。得到商业伙伴的许可后，在一些扫描广域网（WAN）连接时曾出现过问题的区域也安装了扫描器，但是当地的管理者抱怨说就为了几台漏洞宿主机，这个花费太高。针对这一情况，公司做出了一些调整，让一些服务器代理专门扫描没有安装代理的本地PC。
12月6日：由于假期来临，许多关键员工都将休假，于是暂停了所有非关键项目的变更控制。暂停时间为30天。休假前还没有完成所有网络扫描器的安装。
1月15日：所有人休假结束，Carl制定了一项交流计划，保持与所有漏洞扫描环节中的关键管理人员的沟通。他为6个关键办公地点的IT总监创建了初始用户名、密码和权限。他们将是漏洞管理系统的主要用户。流程中有一项一致同意的变更是，IT总监将能够登录到系统中查看他们所在区域公司的漏洞状态。是否能访问漏洞信息主要是通过判断访问者的IP地址是否在允许的IP地址段内实现的。
2月2日：初次扫描完成，系统自动给IT总监们通报了扫描结果。他们对报告的质量、内容以及准确度都很满意。这似乎是Abacus公司又一项技术和流程的成功。Carl把这套系统交给生产系统支撑团队，他们也是漏洞管理开发小组中的成员。有些IT经理抱怨他们不得不进入两套不同的系统中去查看主机状况。运行代理的系统给他们提交了几个服务器漏洞信息，网络扫描系统则提供了PC的漏洞信息。Carl开始同供应商讨论解决这一问题的最佳方案。
2月10日：内布拉斯加州的IT总监要求给予他的PC支持团队全部9名成员系统访问权限以便获取漏洞报告、执行漏洞修复。系统管理员于是提供了一份需要完整填写的信息表，用于创建用户。创建上述两套漏洞扫描系统的系统访问用户，需要经过新用户填表、表格返回、数据录入、密码校验/重置等操作，完成这些大约花费了两天时间。
2月12日：商业伙伴Syllog公司抱怨得到了一份奇怪的扫描结果。该报告中，Syllog公司网络中的PC名称不正确，显示的是Abacus公司的服务器群。总部IT管理人员经过核查后，发现Syllog的管理人员实际上拿到的是这两个网络共同的扫描结果。原因是他们使用了相同的IP地址。漏洞扫描器发送给该服务器的报告是正确的，只是因为两个网络的IP地址重复。
2月14日：另一个办公区的IT管理人员也提出了同样的要求，他的PC支持团队成员共有6人。该IT管理员称他们也必须通过访问才能执行修补工作。用户增加后，必须制定详细的流程来支持两个分开运行又协同工作的系统。
2月18日：针对IP重复的问题开发出了一套新的技术解决方案，该方案在报告中通过计算机名称而不是IP地址来区分主机。为适应这一方案，所有的网络定义和权限都需要升级。与此同时，开始将两个漏洞系统集成到一个报告系统中。这项工作由一位具有丰富Perl编程经验的系统工程师完成。
2月23日：其他6个地区的IT总监也都要求赋予他们的支撑团队成员漏洞管理系统的访问权限。其中有两个总监希望将系统按照服务器和PC分类，并交由两个不同的支撑团队分别负责，因为这两种设备上的漏洞修复技术有所不同。上述变化导致系统用户总数增加到32位。
2月25日：经过一位员工3天的工作，网络定义和权限许可的修改完成了。目前系统有47位用户。一些服务器管理员抱怨安装的补丁未经充分测试，并需要制定更加精确的运行时刻表，以免对生产作业产生影响。
3月1日：漏洞管理小组接到通知，内布拉斯加州的一位用户两周前离职，应该撤销其访问权限。用户离职手续办妥后，该用户的访问权限就被撤销了。还没有找到接替的人选，因此，内布拉斯加州当前只有IT总监能接触这些报告。
3月4日：最初的报告显示，漏洞从记录到最终修复，周期较长。经过一天的调查，漏洞管理团队的领导成员发现，问题主要发生在阅读报告发现漏洞和将漏洞录入事件及变更管理系统两个操作之间。该流程是在实施之初就确定的，一直工作正常，但需要3周的时间才能实施修复。Carl会见了合规管理总监和信息安全总监，讨论新系统的当前性能以及补救缓慢的问题。合规管理总监指出修复关键漏洞能允许的最长时间为7天。但根据系统的报告，目前需要花费2到3周时间。
3月5日：基于微软的系统都配置了活动目录证书，通过它来进行深入的扫描。实际运行中，证书允许扫描器登录到系统中，检查关键补丁并配置项目。管理报告已经按照需求，通过Web接口从两个系统中合并到一份报告中。系统工程师开始按照详细修复报告进行工作。但是，两个系统中的许多数据因类型不同无法进行对照、匹配，因为一个使用CVE（常见漏洞和错误）编码来检测漏洞，而另一个使用Bugtraq来检测。
3月10日：Carl上周全部时间都在努力完善当前的报告和修复流程，但从运行结果来看仅仅将平均处理时间缩短了一天。看起来关键问题出在负责录入信息到事件和变更管理系统的工作人员还有其他的工作职责，例如要进行实际的修复工作。通过补丁管理系统发布补丁能够解决一些问题，但如果问题不能在一到两天之内得到解决，那么很快就需要发布新的补丁。然而，约有30%的漏洞需要人工修复，这意味着会很慢。另外，基于代理的漏洞管理系统设计为了使用自己独有的变更管理系统，不具备自动输出变更和导入变更发布状态的功能。
3月11日：尚未扫描基于UNIX的系统。为了使用新系统进行深入的扫描，需要手动为每个UNIX系统配置合适的证书。这一过程相当耗时，因为需要创建大量变更管理事件。系统中有些变更出于节省时间高效工作的考虑而被绑定到了一起，但只有具备相同配置的系统，换句话说，就是完全相同的系统，才能将这些事件绑定在一起，例如负载均衡配置（load-balanced configuration）下的一些系统。
3月12日：经过深思熟虑并同老板讨论，Carl决定最佳方案是让专人开发一个补丁－变更－事件管理系统和基于代理的漏洞管理系统之间的接口。但是，曾用Perl编写报告的系统工程师给Carl展示了他的时间表，表示没有时间进一步开发这个系统，并将系统整个的源代码交给了Carl。
3月20日：开发人员和供应商的技术支撑小组对经费支出的初步评估结果大约为152 000美元。这主要考虑了三个方面：首先，系统最初的设计只是在发现漏洞时产生SNMP陷阱。没有一个变更管理系统或事件管理系统与该协议兼容，除非在漏洞管理系统或内部系统中编写一个自定义接口。其次，事件管理和变更管理工作流仅当手工输入事件时，才会自动生成变更事件。需要开发自动化接口，该接口能接入两套系统，并通过事件管理数据库中的信息将两者联系起来。此外，漏洞的处理过程同其他事件的处理流程也有所不同，在变更结束之前必须进行一次验证扫描。最后，漏洞管理系统使用CVE和BugTraq编号来判断系统中应当使用哪些补丁。而补丁管理系统使用专有编码集，这种编码更详细地表明了需要哪个补丁。还需要生成一些额外的数据，以便正确匹配这些编码，并识别不一致的地方。
3月23日：功能全面的系统总预算造价目前为482 000美元（比初始预算多了152 000美元152K）。高级管理层担心这会是个无底洞，于是将总造价限定在初始水平（350 000美元），多出来的20 000美元可用于开发人员发送需要的XML格式的消息到事件管理系统，以便节省数据录入的时间。这样，Carl的预算就花光了。
后记：剩下的一年里，漏洞管理系统的用户一方面对系统运行效果感到很满意，但另一方面又对不完善的修复流程感到困惑。大量的工作仍然放在漏洞修复和事件处理上。用户还得建立变更请求、手工运行验证扫描，然后结束变更。Carl一直认为高级管理层小事聪明，大事糊涂。有人就奇怪为何公司不干脆使用一套系统，这样就能够避免所有的混乱了。
- 分析
事情起初看上去开展得很顺利。很明显，该公司IT运营部门非常成熟，过程管理和支撑系统能力很强。项目管理看上去也很有条理。行动之初有良好的行政支撑，制定了预算并得到批准。项目管理者Carl联系到了所有相关的业务伙伴，并建立了互助性所有权的关系，以使得系统虽然出现明显缺陷但还能保持运行状态。
首先，让我们看看漏洞管理的流程，这有助于更好地理解漏洞管理是如何在Abacus公司生效的。虽然Abcaus的员工训练有素且高效，但仍然在这一流程中经常感到棘手。
在ITIL框架中，意外事件的定义是，一些打乱事件约定的服务级别或干扰基本商业活动的事件。服务级别是按照漏洞和修复的时间框架确定的，一个新发现的漏洞如果不能被及时纠正，则很有可能不符合SLA（服务等级协议）规范。当Abacus的新漏洞管理系统发现一个漏洞时，将立刻在事件管理系统中产生一个事件进行追踪解决。由于Abacus公司没有丰厚的财力，因此服务台上的功能可以根据所要处理的事件的不同，由不同部门的IT员工进行操作。所以，服务台是一个动态实体，包含通达各方的基于软件的路由。请参见图2-2体会这一过程。
根据网络和主机感染的不同类型，选择适当的人来评估漏洞信息。如果一个漏洞是高危漏洞，则需要创建事件并追踪其解决进度。如果是非高危漏洞，则将其放到非紧急变更流程工作表中。
当解决方案中的某一变更操作很复杂，并且已经确定实施这一变更会对其他功能造成影响时，变更管理系统则会创建一个变更并产生一个变更标签。这使得受影响的部门能够通过相应的潜在影响通知来了解变更过程。它还能将目标机的技术性配置数据的变更通知给管理人员。
一旦为修复漏洞打上补丁或升级配置，变更标签就可以关闭了。变更标签关闭时还将发出警告：相同的漏洞在下次漏洞扫描时应当不会再出现。
要么是根据常规时间表的安排，要么是在系统请求下手工启动，漏洞扫描程序再次运行了。响应请求性质的扫描一般执行得很快，因为只扫描受变更影响的系统。
当变更标签关闭后，事件标签也将关闭。这一过程由变更管理系统和事件管理系统自动执行，但只在事件管理系统自动产生变更标签的情况下进行。
对于缺乏经验的人来说，这个过程看上去相当烦琐，但Abacus公司的员工有很强的纪律性且训练有素。该流程运行得非常好，为关键产品系统提供了典型的、不间断的、可预测的服务。在本例中，看上去整个过程都安排得非常妥当。但是，在系统集成过程中仍然存在几个缺陷。
一个明显的问题是事件管理系统和变更管理系统之间的持续的相互影响。对每个关键漏洞，负责服务台的IT员工都需要创建事件以便于追踪。接着，如果确定需要进行重大变更，还得创建一个变更标签来通知可能受到影响的其他人。
下面举一个利用该流程妥善管理漏洞的例子。如果微软SQL服务系统的某个普通账户的用户ID设置了一个弱密码，该密码的脆弱性将成为一个漏洞。如果很多人，甚至公司外的人都能访问数据库服务器，这个弱密码可能成为一个非常严重的攻击载体。为了修复该漏洞，必须更改该密码，但这么做可能会打乱几个依赖于该密码的应用程序的执行。于是，创建一个变更标签并通知所有应用程序的管理者。一旦应用程序的管理者根据系统的变动对程序做出相应的更改，该变更就完成了。
变更完成后变更标签将被关闭。在Abacus公司，仅仅是标签被关闭，而不是事件被关闭。在事件关闭之前必须先对该系统进行一次扫描，以确认漏洞修复成功。本例中，即是对密码强度进行测试。如果该漏洞确实不存在了，那么就手动关闭该事件。
到目前为止，我们有四项手工操作都可以自动实现。图2-2展示了该过程。图中用不同阴影的方框来标识人工执行和自动执行的步骤。图中基本都是自动执行的过程。图中的数字与如下步骤对应：
1：漏洞管理员审阅报告，识别主机中的关键漏洞。该项工作最适合由自动系统来完成。漏洞通常是众所周知的，由世界各地的专家评估。可以将这些评估信息内置到自动化系统中，系统就能基于该信息进行漏洞鉴别。
2，3：如果发现了一个关键漏洞，管理员就打开事件标签，并将它分配给该系统的负责人。
4，5：修复完成后，变更标签被关闭，漏洞管理员重新扫描问题主机。
6，7：再次审查漏洞报告，以确认漏洞是否还存在。这其实是重复步骤1，因此也易于自动执行。
创建事件标签是一个简单的可以由机器执行的利用接口的追踪活动。在步骤3中，可以自动实现重新扫描的行为：将变更管理系统和漏洞管理系统关联起来，使得发出变更完成的通知后，发起后续扫描触发扫描操作。但仍然保留重新扫描行为的手动执行功能，使得可以根据所使用的流程选择执行方式。如果程序要求暂停等待，直到下一次预定的扫描操作，那么步骤4就可以省略了。如果在该过程中需调用手工扫描，则也许需要重新扫描。重新扫描的一个细节是对目标进行限制或参数化使用。例如，某台特殊主机或某个特定网络只允许在晚上扫描，以免服务受到影响。这将避免在工作时间发生任何可能的服务中断。因为一旦修复完成，重扫描只能在第二个晚上进行，而不是立即进行。
现在，让我们从自动化的角度来分析该流程。重新回到图2-2。下面的流程非常类似于前面所描述的流程。但是，该图中还用双层框线指示能够自动执行的部分（第二版 自动化）。在所有自动化步骤中，过程都被加速，只需几秒就能执行完毕。图中数字的含义如下：
1：关键漏洞触发漏洞管理系统自动创建事件标签，并将其分派到漏洞主机所属网络的负责人处。本例中，责任人为事件管理员。漏洞管理系统将获取事件编号（ID）。
2：事件管理员检查变更需求，以确认是否需要大量的工作或是否会影响其他系统。
3：事件管理员进入事件管理系统，标记该事件需要变更，该需要变更的标记在变更管理系统中通过两个系统间已有的接口进行实例化。
4：变更将按计划由一位工程师执行，大部分情况下由事件管理员执行。
5：工程师完成工作后，通过事件管理系统的用户接口，关闭变更活动。这一步无法自动化执行，但需要的工作量很小。事实上，一些变更管理系统能够监听电子邮件消息对升级状态的回复。升级自动触发发往事件管理系统的通知，以临时关闭该事件。
6：事件管理系统按照事件编号，向漏洞管理系统发送确认消息。利用事件编号进行索引，创建另一个对该漏洞主机的扫描操作，检查特定的漏洞及其他漏洞。
7：如果重新扫描发现漏洞已不存在，事件管理系统将收到一个确认消息，随后关闭该事件。如果漏洞仍然存在，将返回确认消息，并发出另一个通知给事件管理员。然后再次重复步骤3到步骤6。
Abacus公司实现中的另一个问题是选择了两个不同的产品，而这两个产品在设计之初从未考虑过兼容工作。虽然市场上的一些产品都能进行基于代理和基于网络的漏洞评估，但基于代理的更多一些。经常会发生这样的情况：两个看起来都很不错的产品由于缺乏关键的兼容性而无法在漏洞管理中很好地配合使用。
结果是，用户一开始就被迫使用两套不同的系统。首先，基于代理的系统只扫描服务器，而基于主机的系统只扫描PC。这种分别管理的逻辑与公司的地方及全球的责任分离管理模式相符。但是，如果在某些情况下，基于代理的PC扫描能执行，但基于网络的扫描在经济上无法承担时，这种责任分离和系统可用性就失效了。
一位知识丰富的系统工程师满腔热情地试图进行一些补救。但是，结果并不理想，仅仅得出了一份管理报告。由于不必进行系统交互，数据采集和规范性都很简单。但是系统中的数据结构和标准值都仍然存在问题。在任何其他的应用中都能发现类似的问题。后面我们可以看到，工业界正努力地避免这样的问题。
2月10日，要求将9个用户ID加入系统中。此时，系统管理员肯定在心里祈祷希望这个任务不要太复杂，因为收集数据并录入到系统一向是个耗时的工作。由于Abacus公司大多使用微软产品，那么为何不用活动目录（Active Directory）来整合用户认证和授权呢？或者使用几乎无所不在的RADIUS协议。这种系统整合对今天的大多数使用标准授权机制的企业来说是非常重要的。我们看到在2月的13日、14日、25日，陆续有其他的用户加入到系统中。最后大约共有50名用户。当一个用户从公司离职后，Carl的小组两周后才意识到应该解除该用户的访问权限。如果用活动目录组技术，则分配到活动目录组中的用户可能早就被删除或禁用了。
图2-3展示了目录结构与漏洞管理系统的结合情况。漏洞管理系统中有各种对象和行为。一个组或一个用户可能是一个成员、也可能是一个角色，包括对象和行为在一起的种种组合。例如，角色为“管理员”的人员要负责维护所有的系统。因此，必须授予他访问所有对象和行为的权限。但是，前面提到的工程师只能有访问特定办公室报表的权限。因此，该组被允许的行为是“报告”，被允许的对象是当地的“网络”。
可以分配给每个组或用户一个或多个角色、特定的网络和图2-4中所示的相应功能。这种分配的优势在于，当一个用户从一个组转到另一个组时，将被授予新组的角色，而不会依然是先前的角色。例如，如果一个工程师从加利福尼亚州的IT部门调到内布拉斯加州的PC团队，该工程师只能够按他新职位的权限访问相关漏洞信息。漏洞管理员也只能对分配给该组的网络进行扫描。
这种整合方式现在看上去是显而易见的，但当初，对Carl或漏洞管理小组的其他人而言，可能都难以想象会有这么多的用户。这也将我们带回前面的讨论：漏洞是如何产生的？本场景与另一个场景相似：原始系统的设计者没有考虑到系统所有可能的使用方式，这会带来包含有太多假设的需求采集活动。Carl的设计与选择小组应该准确分析使用该系统的用户、用户的数量、这些用户将开展的主要活动。其中的情况很多：可能有人离职、有新人加入、分析员核查报告，此外还可能有人变更扫描参数及日程计划。
