2.4 使用漏洞管理程序的理由
我们为何要开发漏洞管理程序呢？原因既有技术方面的，也有业务方面的，下面将一一列出，你总会找到与你的情况最相符的理由。
2.4.1 网络过度开放
在IT安全方面，企业通常有两种不同的目标：任务性目标（mission）和强制性目标（compulsory）。任务性目标的实现直接关系到企业创收与增加利润；强制性目标的实现则主要是出于谨慎和遵守规则的考虑。购置保险就是强制性目标的一个例子。公司购买责任保险以降低可能的损失。很多公司十分重视任务性目标的实现，将其置于很高的优先级，而不是强制性目标。网络安全是强制性业务目标的另一个例子。当现有的网络防御措施不足以抵抗精心设计的攻击时，一些公司会自然地选择进行风险分析（risk analysis），并继而以此来决定在网络安全方面的支出。有时，网络的规模和复杂性使得符合成本效益的防御实际上无法抵御风险。所以有的公司干脆选择了放任风险的存在。
也许你的公司的网络防御焦点是放在检测和防范攻击上的，但是，仅仅阻挡网络访问或关闭边界是不够的。这些防御措施不可能是完全可靠的、全自动化的或是能全面应对各种潜在攻击的。任何从事安全行业的专业人员都知道内部威胁和外部威胁同样严重，然而大多数防御措施都不是面向内部威胁的。目前，在一个拥有5万结点的网络中，要在每一个端口都实现入侵防护、病毒防范、内容过滤、流量分析以及应用行为分析是不经济、不现实的。即使公司财力充足，能做到这点，也还会需要更多的防御措施。因为上述网络防御措施不可避免地会存在一些漏洞，而这些漏洞可能会被利用且直接用于攻击该公司。例如，众所周知的绕过入侵检测系统的方法中，加密就是其中较为简单的一种。采用加密的应用软件能很好地降低攻击的成功率。
解决这些漏洞的唯一出路就是采用基本的防范策略，该策略的做法就是移除每一个防御失效的结点。大多数网络安全策略依赖于边界防御（perimeter）和/或链接防御（bolt-on defense），但如果这些防御措施失效，就会导致主机向各种漏洞利用手段完全打开大门。这就是网络过度开放所导致的最糟糕的情况。用户觉得安全，但并不是真正的安全，需要增加额外的安全防御措施，其中一项就是主机必须加强防御，排除各种可能被利用的漏洞。
2.4.2 安全系统配置标准缺失
大公司通常会为联网系统制定一个或多个配置标准。这些标准包括台式机和服务器操作系统、网络设备，甚至打印机的配置标准。在这些标准中通常有内置的实践案例。如果设置的标准没有实施到位，那么漏洞可能会比标准缺失时出现得更多。其实，有成文的标准仅仅能说明人们确实关注到了设备的状态。
但是，即便存在标准，配置仍可能老化过时。标准一经建立就不会再轻易更改，因为很难同步所有的主机使其按修改的内容变更配置。即便有一个良好的补丁管理系统，也无法依靠补丁完全解决这些固有的配置问题。大多数情况下，补丁管理系统无法检测出每一个需要修复的问题，因此它并不能取代漏洞管理。
标准化的缺陷在于漏洞的普遍存在性。如果一项标准配置存在某一漏洞，而这一配置又被全面部署，那么该漏洞就会广泛地存在于各个部署结点中。如果不能对其进行及时的检测和修复，将会导致严重的安全问题。
2.4.3 重大经济损失风险
当遭受攻击的风险较高时，管理层自然地会将注意力转移到风险识别的作用上。随着政府和维权体系法规的日益完善，由诉讼和/或民事处罚等造成经济损失的可能性显著增大。想象一下，如果因为没能及时补救一个危险的、已发布的漏洞而导致客户机密数据的丢失，那么客户可能会马上诉诸法律。
加利福尼亚州民事法（California Civil Code 1798.84）条规定，与加利福尼亚州居民有商务往来的公司如果未能在规定期限内将安全漏洞告知受害者，则将处以高额罚金。公开这些漏洞可能会造成巨大损失，而如果对这些漏洞放任不管，所导致的民事罚款也很高。该法律条款仅是一个例子：无论公司的实际地理位置在哪里，只要公司与当地居民进行商业活动交易，就要为数据漏洞承担责任，接受惩罚。
2.4.4 收益损失
任何商业活动最为关心的问题就是收益或潜在收益，因为它们的损失将是直接的损失。当一个客户流失时，企业不仅遭受了收益上的损失，名誉也会受到影响。挽回名誉损失比挽回其他的损失要困难十倍。对潜在客户来说，也是如此。通常来说，一起安全事故被大肆宣传后，若想在此逆境中赢得新客户，是非常困难的，并且要付出巨大的代价。
有一个非常奇怪的现象，普通客户比集团客户更容易抚慰。由于某种原因，普通客户常常忘记或忽略某个特定公司的安全危害，但集团客户则不同。但是，普通客户也会逐渐变得不愿与任何遭到过政府处罚的公司进行交易。鉴于此，企业更应该致力于漏洞的管理。
2.4.5 生产力损失
系统遭受损害后会有一段时间不可用，如果是核心系统，员工将无法正常工作，企业生产力也将显著下降。比起员工完全停止工作，我们更难评估以下这种情况造成的损失：员工仍能继续工作，但要花更长时间才能完成任务。有时，这种应急工作状态很难立刻启用；而同样的，当遭受损害的系统恢复服务状态后，应急状态也难以立刻终止。即使对事故进行总结分析后，应急工作状态下产生的数据记录可用，这些数据也必须与恢复后运行的系统重新进行同步。
并且在系统恢复服务前通常都有一些耗时的事情必须先行完成：分析故障原因、重建工程、打补丁、考虑附加的安全性，以及密切监视第二轮攻击。为了完成这些事，负责处理故障恢复系统的IT员工将无法从事那些能够更直接地增加收益、减少成本、提高生产力的工作。而启动应急工作状态并不能及时地满足市场需求，甚至还有可能会增加一些机会成本。而且不可能让一些IT员工专门等着应对突发事件，所以我们只有在事件发生时，将现有的资源临时投入到应急响应措施当中。
