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