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