转载自微信公众号“数世咨询”（dwconcn）。
如今，漏洞管理团队有海量的数据可以进行处理，而分析这些数据却要花费和修复一样长的时间。究其原因，是因为不同的工具只会提供解决隐患的一小部分数据。
在安全团队开始考虑云安全的时候，漏洞管理团队却依然想方设法流水化加速修复流程——但如果他们依然得手动将几十个工具中的数据进行整理，显然是无法实现的。另一方面，修复团队需要的是优质的数据，而不是大量的数据。
▶ 数据而生的问题
如今的漏洞管理工具会收集一些基础的数据，比如检测到的漏洞数量、受影响资产、严重性等。这些只能让安全团队监测到最需要修复的东西，但是这些工具无法提供能够提升修复成果的关联信息。比较成熟的团队会使用电子表格或者商业智能工具追踪一些数据矩阵，比如之前修复过的漏洞数量、依然存在的漏洞数量、以及最近一次扫描中发现的新漏洞数量。
虽然说这些数据也挺有用的，但是依然缺乏关联性，因此很少能为修复工作提供一个整体的视角。举例而言，它无法将一个漏洞的位置和受影响的业务单位关联、无法报告修复一个漏洞所需要的真正时长、也无法对漏洞修复优先级提出意见。这种类型的信息，恰恰是改善漏洞修复成果的基础。
▶ 真正需要的数据
安全团队不仅需要数据帮助他们基于业务风险对修复工作进行优化，还需要信息引导和推进流程的改善。真正需要的数据应该能帮助他们识别脆弱点，并且将修复的精力重新集中在最能影响自己最关键的业务的技术上。
举个例子，如果扫描器在第七行代码中发现了一个SQL注入漏洞，或者发现了一个需要进行补丁的Red Hat盒子，这些信息并没有告知受影响的具体产品、拥有者、或者对组织的重要性。这些漏洞是否有某些漏洞比其他漏洞会带来更多风险?如果无法同时修复，哪个漏洞应该得到更多关注?
另一个需要考虑的问题，在于因业务周期本身，产生的对受漏洞影响技术的依赖程度。举例说明，许多零售商管会在购物季面临更多的风险;而食品杂货店由于每个月都会有新的产品，因此会在不同的IT和业务单元中改变优先级。在这些情况下，漏洞管理团队需要更优质的数据，基于实时的业务需求进行修复决策。
接下来，修复团队需要理解某个修复会如何影响到业务运营。尽管说漏洞管理工具能够给出修复的平均时长，但是这个数据是基于每周的扫描得到的，依然缺乏关联性。上周报告的哪些漏洞已经被修复了?每个都花了多久修复?一天?五分钟过?还是 五天?
这些数据对于CISO们也是无价的。历史数据可以显示哪些平台的修复时间更长，以及相关原因。这些信息能帮助CISO们发现流程中的效率问题、产品脆弱性，甚至人员相关问题，从而着手考虑如何解决。
▶ 困境为何难以突破
改善漏洞修复流程的最大困难，在于相关的数据都被分散在许多不同系统中：扫描器中的漏洞数据、配置管理数据库或者资产库中的业务数据，甚至某些数据只在一些特定的人员手中。另一方面，安全团队可能在不同团队部署了多个漏洞管理工具——比如扫描漏洞的、威胁情报团队、IT运营人员等等，都使用不同的工具。
把这些问题聚集到一起，就是许多数据并不是由现有的工具所储存的：比如，很少有组织会追踪他们DevOps团队发现漏洞、安装补丁、检查补丁是否生效所花的时间长度。即使他们对这些时间长度进行了记录，也极少会将这个信息反馈给漏洞管理团队。
还有，一些漏洞管理工具会完全无视未储存的数据点。比如，如果CISO询问过去六个月修复了多少漏洞，大部分漏洞管理工具可能都没有相关数据。
▶ 我们能怎么做
要解决这个问题，需要创建改善修复成果所需的工作流和流程制度。这不是个简单的事情。首先，漏洞修复团队必须让业务单元的拥有者参与其中，让他们协助识别关键的业务功能点，以及资产之间的关系。将业务功能和相关的技术产品进行关联，然后评估每个自查案的关键性，并且和漏洞管理项目结合。
下一步，安全团队需要和DevOps团队以及IT运营团队合作，一起协同进行修复工作。这种关系会随着时间的推移，成为安全团队改善修复流程的关键。
然而，这样的协作并不简单。因此，安全团队的负责人必须想办法让这些跨部门的人一起合作、训练。他们需要讨论哪些数据是之后需要的，然后计划如何收集和使用这些信息，从而提升修复效率，做到主动漏洞修复。
最后，高效的收集、分析和处理数据，是使漏洞修复进程更成熟的关键。无论是使用表格还是商业智能工具，修复团队都需要决定哪些数据矩阵是需要追踪的，并且设定合理的KPI。基于数据设定目标，能确保事情走在正轨上。
这一转变是相当艰巨的。不过，对于安全团队而言，艰苦可能是一种驱动，没有什么比没有防住一个补丁就能解决的攻击更让人痛苦的了。
