有效的现代补丁管理流程与补丁运维最佳实践

Thu, 01 Aug 2024 06:01:00 Z

实施一项基于风险的漏洞管理计划，对于维护安全的企业计算环境至关重要。在上一篇博客《实施基于风险的补丁管理如何优先处理活跃利用漏洞》中，我分享了关于如何确定漏洞优先级的观点。要落实这一流程，优化系统安全保障的运维环节至关重要。

在组织中开展补丁运维可能是一个复杂的过程。即使已经了解了漏洞优先级，您仍需要考虑：

补丁发布节奏。
使这一流程有效运行的配套策略。
用于部署更新的活动。
服务级别协议 (SLA) 与合规性衡量。

这看起来似乎需要兼顾很多方面，但一个既能管理计划内事件、又能应对计划外情况的灵活系统，将帮助您全面掌控。

您是否真正掌控了局面？

补丁发布有些方面可以提前规划，有些则无法预判。

以安全补丁的发布节奏为例。在每月的第二个星期二，也就是“补丁星期二”，Microsoft 会尽可能发布其所有最新更新。这些更新包括操作系统、Office 和其他用户应用程序的更新，也包括 Visual Studio 等开发工具以及 Azure 中的云组件更新等。

补丁星期二于 2023 年 10 月迎来 20 周年，它是许多补丁计划的基础，为分发所有最新 Microsoft 更新以及可用的第三方更新提供了一个固定时间点。没有其他厂商对推动组织补丁计划产生过如此深远的影响；直到今天，以补丁星期二为锚点的月度补丁周期仍是行业标准。

其他厂商也曾尝试效仿，按固定计划发布更新：

Oracle 每季度发布一次关键补丁更新。
Adobe 通常每月发布一次更新，往往与补丁星期二同步。
Google 最近开始每周发布一次单一更新。

然而，大多数厂商会尽可能及时、频繁地发布安全更新，以确保尽快修复漏洞。这会形成随机且持续不断的更新流，需要在整个组织内不断确定优先级并进行分发。

面向策略和活动的补丁管理流程

要让混乱的补丁发布变得可控，需要一套明确定义的规则，以及用于执行这些规则的基础设施。在补丁领域，这些规则和基础设施体现为策略和活动。

补丁策略需要在漏洞优先级之外考虑广泛因素，包括更新对业务运营的影响、对不同类型系统的适用性、对更新的控制程度以及其他因素。

补丁策略会因业务不同而呈现明显差异。对于承载关键业务应用程序的服务器，其策略涉及一组在严格配置控制下明确定义的更新，仅在指定维护窗口内执行，并始终在完成后强制重启，以确保系统已完全更新。而对于市场营销用户的笔记本电脑，补丁策略会识别一系列可能存在也可能不存在的应用程序及其已批准更新，并允许用户在方便时延迟更新和重启。

活动会将这些策略纳入考虑，同时也能让持续发布的海量补丁得到有效控制。

现代补丁管理最佳实践要求比每月一次更频繁地打补丁。Google Chrome 补丁每周都会发布，零日补丁也可能随时发布。仅依靠月度活动会使许多系统长时间处于易受攻击状态。

建立三种类型的活动

一项最佳实践是建立三种类型的活动：常规维护、优先更新和关键部署。

常规维护活动

常规维护活动用于执行大多数组织如今采用的标准月度分环补丁推出流程。此活动包括：

在受控环境中进行初始测试，确保补丁按计划安装。
向规模更大的早期采用者试点组推出，由其关注并报告问题。
向预定义的生产系统组推出，以完成整体分发。

维护活动中的补丁包括发布频率较低的安全更新，例如 Microsoft 补丁星期二发布的更新，也包括性能或应用程序升级。此活动的目标系统也可能是维护窗口有限、且一旦中断会对业务产生重大影响的系统。大多数补丁更可能归入优先更新活动。

优先更新活动

优先更新活动旨在快速处理那些持续暴露于新漏洞、但可以更频繁更新的系统。运行生产力应用程序和浏览器的用户系统属于此类活动，并且由于面临网络钓鱼、恶意软件和勒索软件的威胁，通常风险最高。

与此活动相关的补丁通常因漏洞已知被利用而具有最高优先级，但其业务影响也可能相对较低，只需要重启浏览器或应用程序即可。因此，这些策略在发布前的测试周期可能更短，并且可能更快分发到更大范围的非业务关键系统，例如服务器可能未安装浏览器，但销售人员的笔记本电脑通常安装了浏览器。

零日响应活动

零日响应活动用于处理由公司或行业强制要求、必须在短时间内完成的紧急补丁部署。这类活动优先于所有其他活动。

此活动的策略可以缩短分阶段推出各关口之间的时间或降低标准；也可以根据必须满足的 SLA 完全跳过这些关口。对于零日响应活动，最重要的是：这仍然是受控的补丁分发，所有活动仍会被报告，以便准确跟踪活动事件直至完成。

暴露时间决定合规性

如果以已完全打补丁的计算机数量来衡量合规性，那么按这一指标，大多数系统每个月只有有限的几个小时处于合规状态。虽然从技术上讲这是准确的，但在基于风险的计划中，它并不能很好地反映系统随时间变化的安全状况。展示某个漏洞或一组漏洞的“暴露时间”，能更好地反映风险。

以下是一个示例：CVE-2024-4761 据报告已在 5 月 14 日发布的 Google Chrome 更新中修复，而当天恰好是 5 月的补丁星期二。第二天，该 Chrome 补丁被加入优先更新活动，该活动包含两周的分发期，覆盖第 1 组的 500 台系统和第 2 组的 1,000 台系统。假设大多数系统都在这两周窗口期内成功更新，报告会显示每个系统的更新时间；但更重要的是，它会显示这 1,500 台系统各自保持未打补丁状态的时长，也就是暴露于该漏洞并面临风险的时长。

这是一个简单的单漏洞、单补丁示例。但如果活动中包含多个补丁和多个漏洞，则可以汇总这些信息，提供更全面的活动视图。如果在同一时期运行了多个活动，还可以叠加或合并结果，提供更准确的风险评估。

借助这些数据，您可以向审计人员展示系统的真实安全状态。也许更重要的是，您可以开始评估结果，并提升现代补丁管理运维的有效性。到那时，是您在掌控运维，而不是被运维牵着走。

Ivanti 博客: 作者