漏洞管理(VM)是每个全面信息安全项目的必备基础，不是什么可选项。事实上，很多信息安全合规、审计及风险管理框架都要求公司企业拥有并维护好漏洞管理项目。
如果你还未购置漏洞管理工具，或者你的漏洞管理项目只是临时设置的，那么马上专设一个漏洞管理项目应该成为你的首要任务。实际上，互联网安全中心(CIS)的第三号关键安全控制就倡议将持续漏洞评估与缓解作为风险与治理项目的组成部分。
如果你仍认为漏洞管理策略不过是战术性运营工具，或许你可以重新考虑一下。漏洞管理应该成为你安全项目的重要基石。
一、漏洞管理定义
无规矩不成方圆，没定义鸡同鸭讲，要确保大家讨论的是同一件事，就得先明确讨论主题的定义。漏洞管理过程一项持续的信息安全风险事业，需要多方面的管理督导。漏洞管理主要由4个高级过程组成：发现、报告、优先化及响应。强漏洞管理框架中，每个过程和子过程都是着重改善安全和减少网络资产风险的持续周期的一部分。
二、漏洞管理最佳实践
1. 以发现和再发现管理漏洞
发现过程是要找出网络资产，并加以分类和评估。关于资产的信息应按数据类型分类，比如漏洞、配置、补丁状态、合规状态或者仅仅是资产库存。
发现过程应找出网络上的每个计算资产(没错，就是每一个)，并建立起其他漏洞管理过程可使用的知识库。由于网络不停在变，资产信息也需持续更新。
2. 报告，报告，报告
发现过程中找出的数据通常以各种不同的形式报告给相应的受众。报告过程应创建馈送至漏洞管理过程的优先顺序矩阵。毕竟，每个漏洞的原始数据未必都那么有用。理想状态下，这些报告应能为战术性运营任务所用，而在较高层级可为高层管理提供可见性及面向业务的风险指标。
三、优先级最重要
优先化是根据预定义特征集排序已知风险的关键漏洞管理过程。举个例子，优先化应引发这样的思考过程：面对来自发现过程的当前资产状态、该特定资产的价值及已知威胁，风险到底有没有重要到我们应花费资源去缓解?或者，该特定资产当下的已知风险是不是公司可接受的?
优先化的目标是要用漏洞管理工具创建一张自定义的事件处理顺序表。理想状态下，该经过优先排序的动作列表被馈送到标签系统共IT运营使用，让系统管理员据此执行特定任务。
四、风险响应
风险响应是漏洞优先化过程的下半场。基本上，风险响应是企业选择来解决已知风险的方法(注意：无视风险并非响应方式之一)。
解决风险的方法分为3类：修复、缓解，或是接受。修复可以理解为修正已经发现的错漏。比如说，因为忘了打补丁而导致的漏洞，就可以通过安装补丁程序来加以修复。
另一方面，缓解是通过采取一些基本不在受影响系统直接管辖范围之内的其他动作来减轻风险。比如说，针对系统上发现的Web应用漏洞，不是去修复漏洞，而是去安装一个Web应用防火墙。漏洞依然存在，但有了Web应用防火墙，风险也就消弭了。
接受风险则是选择既不修复也不缓解，单纯承认并接受风险的存在。举个例子，安全运营团队可能会建议实验室设备运行杀毒软件。但公司利益相关者却会因杀软可能影响工程测试用例而选择不采用杀软。这种情况下，公司选择接受已知风险。
五、范围之内，范围之外
取得对漏洞管理包含内容及其重要性的共识后，就可以接着讨论有什么东西不属于漏洞管理辖下的了，因为似乎很多人对此不甚清楚。
1. 渗透测试不在漏洞管理范围内
漏洞管理不是渗透测试。有产品扫描公司系统并不意味着公司就有了渗透测试工具。事实上，情况正好相反。漏洞管理扫描器往往检查的是某个补丁是否安装之类的特定情况存不存在。
而渗透测试工具实际是要尝试使用预定义的漏洞利用程序突破公司系统。虽然两种类型的测试最终交出的结果可能都是同样的建议，但达成这些结论的途径却有很大不同。如果想要进行良好的渗透测试，你需要的可能不仅仅是一个工具。渗透测试详尽繁复，包括物理测试和面对面的交谈以及其他很多东西。
2. 配置漏洞管理
虽然很多漏洞管理系统能与配置管理系统协作，但两者之间还是存在很大不同。事实上，CIS对此有很多论述。漏洞管理覆盖与系统配置和风险标记相关的问题，而系统配置的运营与管理则是配置管理程序的特殊部分。
六、定义持续漏洞管理
漏洞管理数据的状态取决于最后一次更新的时候。与审计类似，报告的数据仅与最近一次评估相关。创建最相关数据集的关键在于定期执行漏洞管理程序。对某些公司而言，这个频率是每天或每周。一个季度一次更新是谈不上什么持续不持续的，一年一次评估更是与持续搭不上边，因为我们都知道，网络变化的速率会让年度数据在一年中的11个月里都是无用的。
七、应该做的和不应该做的
漏洞管理只是安全项目的其中一部分，解决不了整个风险管理问题。漏洞管理是安全项目的基础，只有全面了解自家网络上都有些什么，才能有的放矢。如果连网络上有些什么都不知道，又何谈保护?你还得理解网络上每个资产各自的面临的风险，才可以有效确定优先级并加以修复。
