这份详细的指南讨论了安全团队为何会被漏洞淹没、隐藏在双重报告漏洞背后的危险，以及如何使用 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 的程度时，许多训练有素的安全专家已经对漏洞进行了审查。
即使是安全研究人员也可以将其混淆
在这个双重报告的例子中，很明显，安全研究人员应该已经知道现有的漏洞，或者如果他们在请求新的 CVE 编号之前对“新”漏洞进行了充分的研究，就应该已经找到了现有的 CVE。
这是一个令人担忧的想法。 这个内存映射漏洞位于 Linux 内核的核心，但安全研究人员显然没有意识到它，因此双重列出。 更糟糕的是，并不是每个列表都相隔十年甚至几年：同一漏洞的单个列表相隔几个月，一个在 2020 年 8 月，一个在 2020 年 11 月。
安全研究人员是否疏忽大意？ 不。安全研究人员完全被大量的网络安全挑战所淹没。 这就是为什么在这个例子中，Linux 内核安全专家错过了一份关于潜在严重漏洞的现有报告。
漏洞双重报告背后的隐患
网络安全威胁正在增长的明确证据，再加上安全专家也犯错的例子，表明双重报告的影响比乍一看的影响更大。
这并不表明 Linux 安全专家容易出错和疏忽。 它只是表明，管理安全漏洞的工作变得非常困难，甚至专家也难以跟上。
考虑一下典型的内部技术团队，其职责范围很广——是的，包括安全性，但也涵盖维护、运营和无数其他职责。
即使企业团队拥有专门的安全专家，也有可能必须将专业知识应用于一系列威胁和技术工具。 即使对于大型企业来说，聘请 Linux 内核安全专家也是极为罕见的。 即使他们这样做了，正如我们所见，这些安全专家可能会出错。
IT 团队面临艰难时期
现场团队将始终在某种程度上管理安全漏洞。 例如，通过响应重大漏洞的消息，并相应地应用补丁。 来自供应商的警告也可以推动采取行动，大多数优秀的 IT 部门都会有某种类型的补丁制度，以确保在设定的时间间隔应用补丁。
但是，IT 团队如何才能真正跟上越来越多的 CVE，这些 CVE 每天都会影响 Linux 发行版。 比如说，季度修补制度真的能提供足够的安全性吗？ 是的， 打补丁很重要，但它是否应该以牺牲其他一切为代价来主导活动——鉴于补丁的数量，这很容易发生？
很容易看出，IT 团队会发现很难领先于不断增长的漏洞列表。
让你的修补制度正确
正式化您的修补制度是尝试应对堆积如山的 CVE 的第一步。 基于令人震惊的新闻报道的临时补丁不是要走的路 – 漏洞太多，而广为人知的漏洞相对较少 – 留下无数隐藏的漏洞和相关的漏洞利用，构成危险。
尽管如此，创建补丁制度的关键步骤之一是确定补丁的优先级。 必须迅速修补关键的、广为人知的漏洞 – 不得拖延，并在必要时牺牲可用性。 可以安排针对中低风险漏洞的补丁，以适应技术团队的工作量，或者避免可用性问题。
另一个关键步骤是建立一个足够完整的需要打补丁的硬件和软件清单。 一些修补目标将立即显而易见，但其他目标很容易被遗漏。
在建立您的清单时，您还可以确定一些标准化的范围 – 换句话说，将软件升级到相同版本或合并供应商以更轻松地管理修补程序。
最后，值得将您的修补制度编入正式的修补政策中。 修补很难始终如一地进行，所需要的只是一次失败即可打开灾难之门。 编纂的修补制度可以帮助您的团队在修补方面保持正轨 – 年复一年。
打补丁的权衡
对于任何修补机制，通常都需要在可用性和安全性之间进行权衡。 是的，您可以以高度安全的方式打补丁——尽快应用补丁。 但是修补不可避免地会对可用性产生影响，因为修补通常需要重新启动服务器。
事实上，一些公司可能有特定的业务要求，即使出现关键 CVE，也可以防止关闭服务或服务器以应用补丁，这会使服务容易受到新的攻击。
即使您可以让服务器离线进行维护，服务也会降级，最终用户体验也会降级。 例如，想象一下拥有数千名在线客户的在线零售商突然将一半的服务器离线进行维护。
然后还有技术团队的消耗，他们不可避免地牺牲花在其他任务上的时间来花时间打补丁。 安全团队可能完全被修补的负担压得喘不过气来。 然而，还有一种选择。
考虑自动修补工具
我们已经确定了标准修补制度背后的两个关键问题：修补所需的时间和精力，以及与修补相关的中断。 一个值得考虑的解决方案是自动打补丁——如果是这样的话就更是如此 无需重启的自动修补 无需重启服务器即可应用补丁。
自动补丁工具持续监控补丁发布并自动应用这些补丁而无需干预。 它消除了专门为服务器机群打补丁的需要——打补丁只是在后台无缝进行。有了自动打补丁，技术团队永远不会被无数的补丁任务压得喘不过气来，技术团队也不需要尝试和预测哪些补丁是最重要的。 相反，所有补丁都无缝、均匀且一致地应用。
一些自动修补工具，例如 内核护理 可以即时应用补丁 – 在机器运行时实时修补，无需重新启动。 实时修补限制了中断，因为机器不会离线处理补丁。 当中断风险最小时，补丁一致性可能会提高。
换句话说，正确的自动修补工具可以解决公司在修补时面临的两个最大问题：所需的工作量和中断。
修补至关重要，无论您选择如何进行
无论您的公司为修补自身做什么，或者您如何安排修补制度，唯一可以确定的是修补是至关重要的。 必须应用修补程序，但需要决定修补的频率和修补方式。
鉴于网络安全威胁的规模，有一个强有力的论据支持自动修补。 技术团队和安全研究人员越来越不知所措，而自动化补丁则在资源和可用性问题之间架起了桥梁。
简单地将更多人力用于修补挑战始终是一种选择，并且对于某些可能是唯一选择的工作负载。 然而，在大多数情况下，自动化的、无需重启的修补可以极大地战胜当今巨大的网络安全挑战。
- 使用 KernelCare 免费修补 Raspberry Pi Linux 内核！
- 使用 UChecker 检测内存中过时的共享库
CybersecurityKernel Live PatchingKernelCareLinux KernelLive patching安全补丁
