很多人应该都记得2003年“蠕虫的一年”，在那年的1月25日，我们看到了SQL Slammer蠕虫攻下了整个美国的自动提款机，同时感染了全球范围内数百万台个人电脑和服务器，该蠕虫病毒利用了微软SQL服务器中的漏洞，事实上，微软早在攻击发生前的六个月就已经发布了这个修复程序。
当年晚些时候，Blaster蠕虫病毒则利用了一个月前刚刚修复的漏洞。这种趋势越来越明显：发现漏洞和利用漏洞的恶意软件出现之间的时间越来越短。随着而来的是，漏洞管理新时代的诞生，企业们疯狂地扫描他们的网络查找有漏洞的设备。
在信息安全领域经常就是这样的情况，只有在真正发生严重事故后，才会采取行动。随着Slammer和Blaster的出现，IT安全部门就能够拿出令人信服的案例来说服管理层部署企业级别的网络扫描技术，从而发现和报告漏洞风险的状态。所以我们部署来自Foundstone、nCircle、Qualys和Rapid7等供应商的工具。
这些漏洞管理工具能够向我们提供关于连接网络的端点以及资产资源状况的情报信息。事实上，存在太多数据，需要花一些时间来整理优先事项以及考虑如何向企业内的负责方报告。不过现在我们就能够对这些情报信息和数据作出反应了。
不过，拥有漏洞数据还只是解决了一半问题。另一半问题是进行修复，为此，我们需要获得IT部门其他团队的帮助。面临的挑战：我们如何让支持团队认识到问题的存在，并且需要让他们明白，他们必须在漏洞被利用前迅速修复漏洞。
在本文中，我们将分析漏洞管理的五个阶段，并提供一些建议来如何到达最后一个阶段：即接受漏洞管理。
1. 拒绝。“扫描结果是不准确的，在你的扫描结果中存在误报(没有漏洞却说有漏洞)”
拒绝通常只是个人(或者支持团队)的暂时抵抗。为了度过这个阶段，你必须让支持团队将注意力放在积极行动上。换句话说，将他们认为是错误的项目暂停，让他们将重点放在他们赞同的项目上。这将能够让工作继续进行下去，而不是让他们怀疑漏洞结果。
2. 愤怒。“这是谁的错?是你提出进行这些扫描的更高请求吗?”
很多支持部门会对于结果所有权的偏离表示愤怒，质疑扫描他们网络中设备的权利。要度过这个阶段，你最好获取足够的和可证明的预先授权，再对这些网络进行扫描。这可以通过更改控制过程进行确认，但这通常涉及对扫描次数的协商，可以通过获取高层的授权来进行扫描。
3. 争吵。“真正的风险是什么?你可以将扫描工作延迟到下一个季度吗?因为我们太忙了。我不明白!”
第三阶段涉及某些个人(或者支持团队)希望能够以某种方式推迟或者拖延不可避免的扫描。风险所有者和修复职责是这个阶段的主题。要度过这个阶段，你必须确定扫描对业务的影响以及考虑自上而下地进行扫描。确认依存关系和定义移除障碍的责任是关键的成功因素。
4. 沮丧。“我一直都保持及时修复补丁，但新的漏洞总是让我们举手无错，我似乎无法取得任何进展!”
在第四阶段，支持团队开始明白可能出现新漏洞的必然性，以及问题的严重性。在这个阶段，支持团队将会需要你的支持。他们将会想知道他们的努力确实取得了成果。一个有用的策略就是确保你的扫描和报告过程采取了风险规避和降低风险评分作为关键指标。换句话说，如果你可以量化这些良好修复工作，那么支持团队将可以开始接受这样的事实，即成功只需要一次努力，但是不断进行修复才能获得长期的成功。
5. 接受。“一切都会好起来，虽然我可能不能打败它，但是我可以全面做好准备。”
在这个最后阶段，终于获得了支持团队的理解，并且对于漏洞管理，他们将更好的集中在风险问题上。一旦支持团队意识到这是一个长期持续的工作，并且扫描结果实际上是帮助识别风险区域，他们通常都愿意部署更有意义的程序更改，而且更能够帮助保护在其控制下的资产。
最后请注意：在这些阶段中出现倒退是很正常的现象，但只要你充分地理解了这些行动背后的动机，你将能够帮助支持团队最终接受漏洞管理。如果可能的话，在评估过程的初期阶段让责任方参与以帮助接好在所有这些阶段中的负面影响。
