这个详细的指南讨论了为什么安全团队会被漏洞所淹没，隐藏在双重报告漏洞背后的危险，以及如何使用 KernelCare 等实时修补工具缓解此类漏洞。
我们知道网络安全威胁正在增长，同时尝试减轻威胁和相关成本的努力也在增长。 但有证据表明，缓解措施进展得不够快。
根据联合 分析 由执行 迈克菲 和 战略与国际研究中心2020 年全球网络犯罪成本将超过 1吨 首次大关——比 2018 年的总量大幅增长 50%。 这一变化率明显超过了 GDP 增长或 IT 支出增长等任何可比指标。
意识不是问题——毕竟，公司正在花费大量资金来防御网络威胁。
相反，在本文中，我们认为网络安全参与者基本上被他们所面临的挑战所淹没。 我们指出最近发生的已知漏洞的双重报告是明确的证据。
继续阅读以了解为什么安全团队会被漏洞所淹没，它如何影响修补，以及面对不断涌现的漏洞和漏洞攻击，团队可以做些什么来持续修补。
又一个漏洞？
去年下半年，发现了一个Linux内核漏洞，并上报。 它被分配了一个 C常见的 五缺点和 乙曝光 (CVE) 编号， CVE-2020-29369，并且该漏洞已按预期进行修补。 到目前为止没有什么异常。
漏洞本身也没有什么特别之处。 在任何操作系统中，内核都必须仔细管理内存——在应用程序需要时分配（映射）内存空间，并在应用程序不再需要时正确删除分配并重新分配空闲内存。
但是，这种管理内存空间的过程很容易出现故障。 如果在没有必要小心的情况下进行编码，内核内存处理过程会给网络犯罪分子提供机会。 在 CVE-2020-29369 的案例中，问题出现在 Linux 中用于内存映射的 mmap 函数中。
该漏洞的性质意味着两个不同的应用程序可以请求访问相同的内存空间——导致内核崩溃。
如果攻击者正确地打出他们的牌——换句话说，设计了一个漏洞——攻击者将能够获取否则会受到内核保护的数据。 它可能是完全无害的数据——或者更有价值的东西，例如有价值的个人数据或密码。
两个漏洞报告的故事
所以我们可以看到一个典型的漏洞被报告了，并且按照通常的程序被接受了。 但接下来发生了令人不安的事情。
仅仅几个月后，就报告了完全相同的漏洞。 再次分配了一个 CVE 编号，这一次 CVE-2020-20200. 然而，很快发现新的漏洞警报与另一个漏洞 – CVE-2020-29369 重复。
出于某种原因第二次“发现”该漏洞的研究人员未能找到该漏洞的第一个实例，然后再为他们发现的内容请求另一个 CVE 预留。 CVE 数据库的主要目的之一是避免重复报告，但在这种特殊情况下，仍然需要另一个 CVE。
这种所谓的案例 “双重报告” 不是第一个或唯一一个漏洞被报告两次的实例。 更糟糕的是，当对漏洞的调查达到分配 CVE 的程度时，该漏洞将已经由众多训练有素的安全专家进行审查。
甚至安全研究人员也可以将其混为一谈
在这个 example 双重报告很明显，安全研究人员应该已经意识到现有的漏洞，或者如果他们在请求新的 CVE 编号之前充分研究了“新”漏洞，则应该已经发现了现有的 CVE。
这是一个令人担忧的想法。 这个内存映射漏洞位于 Linux 内核的核心，但安全研究人员显然没有意识到这一点，因此被双重列出。 更糟糕的是，并不是每个列表都相隔十年甚至几年：同一漏洞的单个列表仅相隔几个月，一个在 2020 年 8 月，一个在 2020 年 11 月。
安全研究人员是否疏忽？ 不会。安全研究人员完全被大量的网络安全挑战所淹没。 这就是为什么，在这个 example，Linux 内核安全专家错过了一份关于潜在严重漏洞的现有报告。
漏洞重复报告背后的隐患
网络安全威胁正在增长的明确证据，再加上甚至安全专家都弄错了的例子表明，双重报告的影响比乍看之下更大。
这并不意味着 Linux 安全专家容易出错和疏忽。 它只是表明管理安全漏洞的工作变得非常困难，以至于即使是专家也难以跟上。
考虑一下一个典型的内部技术团队，该团队具有全面的职权范围——是的，包括安全，但还包括维护、运营和无数其他职责。
即使企业团队有专门的安全专家，也有可能必须将专业知识应用于一系列威胁和技术工具。 即使是大型企业聘请 Linux 内核安全专家也是极为罕见的。 即使他们这样做了，正如我们所见，这些安全专家也会弄错。
IT 团队将面临艰难时期
现场团队将始终在一定程度上管理安全漏洞。 通过回应重大漏洞的消息，为 example，并相应地应用补丁。 来自供应商的警告也可以推动行动，大多数优秀的 IT 部门都会有某种类型的补丁机制，以确保以设定的时间间隔应用补丁。
但是，IT 团队如何才能真正跟上越来越多影响 Linux 发行版的 CVE，这些 CVE 每天都在涌现。 比如说，季度补丁制度真的能提供足够的安全性吗？ 是的， 打补丁很重要，但它是否应该以牺牲其他一切为代价来主导活动——考虑到补丁的数量，这很容易发生？
很容易看出，IT 团队很难在不断增长的漏洞列表中保持领先。
让你的补丁制度正确
正式化你的补丁机制是试图应对大量 CVE 的第一步。 基于令人震惊的新闻报道的临时补丁不是可行的方法 – 漏洞太多，而广为人知的漏洞相对较少 – 留下无数隐藏的漏洞和相关的漏洞，构成危险。
尽管如此，创建补丁机制的关键步骤之一是优先考虑补丁。 必须迅速修补广为人知的关键漏洞 – 毫不拖延，并在必要时牺牲可用性。 可以安排针对中低风险漏洞的补丁，以适应技术团队的工作量，或避免可用性问题。
另一个关键步骤是建立一个足够完整的需要修补的硬件和软件清单。 一些修补目标将立即显而易见，但其他目标很容易被遗漏。
在构建库存时，您还可以确定一些标准化范围 – 换句话说，将软件升级到相同版本或整合供应商以使管理补丁更容易。
最后，值得将您的修补制度编入正式的修补政策。 修补很难始终如一地进行，只需要一次失败就可以打开灾难之门。 编纂的修补制度可以帮助您的团队年复一年地进行修补。
修补的权衡
对于任何修补机制，通常都需要在可用性和安全性之间进行权衡。 是的，您可以以高度安全的方式进行修补——在补丁发布后尽快应用。 但修补不可避免地会对可用性产生影响，因为修补通常需要重新启动服务器。
事实上，一些公司可能有特定的业务要求，即使出现关键的 CVE，也会阻止服务或服务器停止应用补丁，这可能会使服务容易受到新的攻击。
即使您可以让服务器离线进行维护，服务也会降级，最终用户体验也会下降。 想想一个拥有数千名在线客户的在线零售商，突然将其一半的服务器离线进行维护，因为 example.
此外，技术团队也会流失，他们不可避免地会牺牲花在其他任务上的时间来花时间打补丁。 安全团队可能完全被打补丁的负担压得喘不过气来。 然而，还有一个替代方案。
考虑自动修补工具
我们已经确定了标准修补制度背后的两个关键问题：修补所需的时间和精力，以及与修补相关的中断。 一个值得考虑的解决方案是自动修补——如果是这样的话，更是如此 无需重启的自动修补 无需重新启动服务器即可应用补丁。
自动补丁工具持续监控补丁版本并自动应用这些补丁，无需干预。 它消除了专门为服务器机群打补丁的需要——打补丁只是在后台无缝进行。有了自动打补丁，技术团队永远不会被无数的补丁任务压得喘不过气来，技术团队也不需要尝试和预测哪些补丁是最重要的。 相反，所有补丁都无缝、均匀且一致地应用。
一些自动修补工具，例如 内核关怀 可以即时应用补丁——在机器运行时实时修补，无需重新启动。 实时修补限制了中断，因为机器不会离线处理补丁。 当中断风险最小时，补丁一致性可能会提高。
换句话说，正确的自动修补工具可以解决公司在修补过程中面临的两个最大问题：所需的工作量和中断。
修补至关重要，无论您选择如何进行修补
无论您的公司为修补自己做了什么，或者无论您如何安排修补制度，可以肯定的是，修补至关重要。 必须应用补丁程序，但需要决定您多久打一次补丁以及如何打补丁。
鉴于网络安全威胁的规模，有强烈的论据支持自动修补。 技术团队和安全研究人员都越来越不知所措，而自动修补解决了资源和可用性问题。
简单地将更多人力用于修补挑战始终是一种选择，对于某些工作负载，这可能是唯一的选择。 然而，在大多数情况下，自动化、无需重启的修补程序可以为应对当今巨大的网络安全挑战带来巨大的胜利。
- 使用 KernelCare 免费为 Raspberry Pi Linux 内核打补丁！
- 使用 UChecker 检测内存中过时的共享库
