VMware ESXiArgs 显示旧版补丁如何成为连续性责任

摘要

• 2023 年 2 月，各国政府和响应人员警告称，攻击者正利用 VMware 2021 年已修复的漏洞，在 ESXiArgs 勒索软件活动中攻击未打补丁的 VMware ESXi 系统。
• 核心责任问题是：谁对虚拟机管理程序补丁欠账、互联网暴露面、不受支持的版本、备份隔离、恢复脚本、客户沟通以及虚拟化服务的连续性拥有实际控制权？
• 该事件的实际根源并非单一标签，如泄露、停机、漏洞或供应商失败。记录主要集中在旧的 VMware ESXi OpenSLP 暴露面、补丁采纳失败、面向互联网的虚拟机管理程序、配置文件的勒索软件加密、恢复指南、备份质量以及隐藏于虚拟化集群中的业务依赖性。
• 当虚拟机依赖于补丁状态和恢复就绪状态未保持最新的虚拟机管理程序时，托管服务商、公共机构、小型企业、大型企业、应用所有者和最终用户均面临服务损失。
• 记录支持对控制责任和证据缺口做出高置信度的责任认定，但不支持假设那些仍属于隐私的事实，例如每一条日志条目、每一项客户影响、每一个内部决策或每一项下游损失。

证据记录及其使用方式

本文将公开记录视为分层证据，而非单一的主叙述。公司公告用于反映 Vmware International Unlimited Company 所述的发现、更改或建议。政府、监管机构、漏洞和安全研究材料则用于围绕该事件界定控制责任。二级报道仅在它们保留了难以从稳定主文档中获取的公开声明、时间线或受影响方背景信息时才会被使用。

事件本质关乎控制

VMware ESXiArgs 事件表明旧版补丁如何变成连续性责任，因为该事件将实际控制权置于比标题更明亮的光线下。公开记录始于VMware VMSA-2021-0002 公告，并得到NVD CVE-2021-21974 条目和CISA ESXiArgs 勒索软件公告的强化。这些记录之所以重要，是因为它们区分了模糊的安全故事和一套明确的操作责任：找到受影响的系统，确认哪些数据或信任材料可被触及，通知必须采取行动的人员，并证明旧的风险路径已被关闭。

重要的分析举措是将触发因素与责任区分开来。触发因素是 2023 年利用未打补丁的 VMware ESXi OpenSLP 漏洞 CVE-2021-21974 的 ESXiArgs 勒索软件活动。而责任则更为广泛，包括事件发生前的设计选择、本应检测到异常活动的监控措施、实施遏制的应急权限、区分已确认失陷与潜在暴露的证据，以及让依赖方能够做出自身决策的沟通。供应商可能对狭窄的技术触发因素描述准确，但仍可能让客户缺乏足够证据来管理自身风险。

因此，对于 Vmware International Unlimited Company 而言，公开问题在于其控制面：旧的 ESXi 补丁欠账、OpenSLP 暴露、勒索软件浪潮、虚拟机管理程序恢复、备份隔离、不受支持的版本以及连续性证据。这些并非公关细节，而是损害扩大或缩小的机制。短暂的入侵可能产生长期的身份证风险；旧漏洞可能演变为实时连续性故障；供应商账户可能成为客户账户问题；平台支持工单携带的敏感材料可能比生产服务本身还多。本文始终以此视角进行分析。

时间线是证据的一部分

时间线之所以重要，是因为客户只有在掌握足够信息后才能行动。在本案例中，公开时间线始于上述触发因素，随后经历遏制、客户指导、后续报告和事后分析。早期阶段考验检测和升级能力；中期阶段考验临时控制措施是否转化为持久修复；后期阶段则考验组织是否已吸取教训，以避免类似路径再次发生，而不仅仅是在关注度消退后关闭事件。

一份良好的事件时间线应回答若干问题：异常活动何时开始？防御者何时首次发现？防御者何时理解其严重性？组织何时遏制了路径？它何时知晓哪些客户、记录、服务、凭证或系统可能受到影响？组织外部人员何时收到足够信息以保护自身？公开公告很少能回答所有这些问题，但它们仍是正确的责任框架。

内部事件与公开公告之间的时间差并非自动构成不当行为。事件响应人员需要时间核实事实。过早发布通知可能传播错误建议。但这一时间差必须能够得到合理解释。如果客户控制着密码、令牌、端点、支持文件、银行账户、管理员或下游用户，延迟也会将风险转移给他们。问责标准并非要求即时的完美，而是要求及时、分阶段的沟通，区分已确认的事实、可能的风险、建议的行动以及尚未解决的未知因素。

数据或信任对象并非偶然

本案例中暴露或受威胁的对象对业务而言并非偶然。记录集中在旧的 VMware ESXi OpenSLP 暴露面、补丁采纳失败、面向互联网的虚拟机管理程序、配置文件的勒索软件加密、恢复指南、备份质量以及隐藏于虚拟化集群中的业务依赖性。这意味着该事件触及了一个信任对象，而该对象正是组织赖以存在或已邀请客户依赖的。当该对象是凭证、签名证书、支持附件、客户元数据集、构建服务器、防火墙、虚拟机管理程序或公共服务身份记录时，组织不能将其视为普通的办公系统细节。

信任对象具有特殊的责任属性。它们允许其他系统做出决策。代码签名证书告诉端点软件是否合法。支持凭证告诉平台某人是否可查看客户记录。构建服务器告诉下游用户某件制品来自预期流程。防火墙或远程访问网关告诉网络哪些会话可以进入。客户元数据记录告诉欺诈者该瞄准谁。损害往往在后来的某个时间点发生，当某人将信任对象用于不同场景时。

这便是为何范围分析需要涵盖功能，而不仅仅是表名或服务器名。如果复制的字段标识出管理员，那么询问是否复制了数据库表就过于狭隘。如果企业记录揭示了随后如何攻击数据平面，那么询问生产数据平面是否被入侵就过于狭隘。如果凭证、证书或附件在事件后仍可继续使用，那么询问服务是否保持在线就过于狭隘。

供应商责任遵循最高杠杆控制措施

本故事中的供应商控制了公开事件发生的环境，但这一说法并不足够。更精确的问题是：高杠杆控制措施中有哪些落在了供应商一侧？在许多事件中，这些控制措施包括架构、特权访问、服务分段、证书或密钥处理、日志覆盖范围、客户数据最小化、安全默认配置、紧急撤销、发布工程以及发布可靠指南的权限。

评判供应商的依据应是它使风险路径变得容易还是困难。特权工具是否要求强认证和紧密角色？敏感支持附件或元数据是否保留了超出必要的时间？生产系统是否与企业系统分离？暴露的服务是否设计为故障关闭？日志是否足够完整以重建访问？组织能否迅速撤销信任材料？客户能否验证自己已安装安全版本或采取了正确的遏制步骤？

公开记录可能只展示该控制状况的一部分。它可以显示已发布通知、已发布补丁、已要求密码重置、已禁用供应商账户、已更换证书或公共机构保持了服务运行。但它通常无法显示内部访问审查、董事会讨论、取证置信度或每一条客户沟通。这种不完整的可见性不应以猜测填补，而应被指认为证据局限性，并转化为对未来更明确保证的需求。

客户和运营商的责任并未消失

客户和运营商同样负有责任。这并非推卸责任，而是承认许多技术事件跨越了组织边界。客户可能控制着端点更新、密码重用、特权账户、防火墙暴露、支持上传、管理员行为、备份隔离、警报审查和用户教育。公共机构可能控制着身份证明和公民通知。托管服务提供商可能控制着客户从未见过的控制台。

正确的分配取决于能力。如果只有供应商能识别哪些支持记录被访问，供应商便拥有该证据。如果只有客户能轮换下游密钥或审查自己的日志，那么客户在收到可靠通知后便拥有该行动。如果托管提供商运行着受影响的工具，那么该提供商对客户负有行动和证据的双重义务。责任跟随实际控制权，而非品牌可见度。

这一点很重要，因为反应不足往往隐藏在另一方的过失背后。客户可能说供应商导致了问题，因此未能审查自己的暴露情况。供应商可能说客户配置错误了系统，因此未能改进安全默认配置。托管提供商可能说自己打了补丁，却避免解释是否审查了失陷情况。只有当各方都说明自己控制了哪些方面以及如何运用了该控制权时，公共利益才能得到保障。

分割是事件与级联之间的边界

分割决定了事件是否保持局限。在本案例中，相关的分割可能存在于企业 IT 与产品基础设施之间、支持工具与生产数据之间、元数据与客户内容之间、管理平面与流量平面之间、构建服务与签名密钥之间，或虚拟机管理程序主机与备份集之间。确切的边界因主题而异，但问责原则是稳定的。

分割声明应当可测试。仅仅说一个环境与另一个环境分离是不够的。记录应显示哪些身份可以穿越边界、存在哪些网络路径、哪些日志确认了未遂或缺失的移动、哪些服务账户被审查，以及应用了哪些应急控制措施。客户不需要每一个敏感细节，但他们需要足够的保证，以了解供应商端事件是否改变了自身的风险。

最强有力的公开声明避免两种极端。它们不会通过暗示每个依赖系统都已被攻陷而夸大危害，也不会躲在狭隘的技术边界后无视关联风险。说生产数据平面未受影响是有用的。说哪些元数据、凭证、证书、附件或管理记录受到了影响同样必要，因为这些材料后续可被用于攻击数据平面。

通知必须告知接收者他们能做什么

通知不是一种仪式，而是可操作证据的传递。有用的通知会告诉接收者发生了什么、可能涉及哪些数据或信任材料、组织已经做了什么、接收者现在应该做什么、哪些仍然未知，以及后续更新会出现在哪里。如果通知只说发生了一起事件，它可能满足了形式上的沟通需求，却未能满足操作需求。

不同的接收者需要不同的内容。安全管理员需要指标、受影响的账户、重置要求、日志审查窗口和配置指导。消费者需要通俗易懂的身份风险建议、支付和密码指导以及支持联系方式。公共服务用户需要基本服务持续或替代方案存在的保证。开发者需要构建完整性指导和密钥轮换步骤。高管需要一份关于暴露、失陷、补救和残留风险的矩阵。

因此，本文将沟通视为一种控制措施，而非一种礼貌。迟发或含糊的通知即使初始入侵被迅速遏制，也可能增加损害。分阶段的通知甚至能在每个事实澄清之前就减少损害。经更正的通知在范围扩大时可以是负责任的。关键在于诚实地标注不确定性，而非假装首次公开版本即为最终版本。

滥用面超出已确认的入侵

已确认的入侵仅是首个风险面。攻击者、犯罪分子和机会主义者可重复利用事件信息进行网络钓鱼、欺诈、凭证窃取、勒索、虚假支持电话、软件更新诱饵、发票诈骗、就业目标锁定和社会工程压力。当虚拟机依赖于补丁状态和恢复就绪状态未保持最新的虚拟机管理程序时，托管服务商、公共机构、小型企业、大型企业、应用所有者和最终用户均面临服务损失。因此，组织必须不仅衡量入侵者做了什么，还要衡量暴露的信息使其他人随后能做什么。

当暴露的材料标识出管理员、支持联系人、支付关系、特定品牌的客户、提交了身份文件的用户或运行特定技术的组织时，这一点尤为真实。这些记录降低了攻击者的搜索成本，使社会工程攻击更便宜、更可信，也让犯罪分子能够个性化时机：在真实事件后发出的虚假重置通知比普通钓鱼信息看起来更可信。

事件后的滥用预防应包括监控冒充行为、警告客户可能的诱饵、加强支持验证、撤销过时令牌、轮换暴露的密钥、监控新账户活动，并为一线支持人员提供不会泄露更多信息的脚本。组织还应审查其是否收集或保留了超出支持或服务功能真正需要的数据。

取证必须支持信任决策

取证审查有明确目的：它支持信任决策。客户能否继续使用该软件？组织能否信任该防火墙？能否信任构建制品？能否信任支持记录？能否信任身份提供商、元数据存储、虚拟机管理程序、证书、备份或远程访问会话？打补丁、重置或禁用某些组件仅是答案的一部分。

信任决策需要关于哪些被访问、哪些可能被访问、哪些被更改、存在哪些凭证或密钥、哪些日志是完整的、日志是否可能被篡改，以及哪些独立信号证实了结论的证据。当证据不完整时，组织应说明这一点，并对高价值资产做出保守决策。即使原始漏洞已修复，受感染的边界系统或构建服务器可能仍需重建和密钥轮换。

薄弱的取证记录会产生二次责任问题。如果组织无法证明信任对象保持安全，它可能需承担更广泛补救的成本。这代价高昂，但替代方案是将不确定性转移给缺乏提供商证据的客户、公民或下游用户。成熟的事件管理将私人日志转化为足够的外部保证，使外人能够理性行动。

经济激励解释了投资不足

事件中反复出现的模式并不神秘。预防性控制在事件发生前往往带来可见成本。分割破坏了便利性，最小特权阻碍了支持，证书轮换产生兼容性风险，构建服务器加固减缓了交付，虚拟机管理程序打补丁需要维护窗口，客户数据最小化可能减少营销或支持细节，备份测试消耗时间。这些成本是即时的，而避免的损害在到来之前是不确定的。

这种激励差距解释了为何问责不能等待法庭记录或确认的损失数字。如果每个组织都等到损害被证明，最廉价的路径永远是推迟控制并希望另一方承担损失。客户可能遭受身份风险、停机、欺诈监控、紧急人员配备、合同中断或公共服务不便，而拥有最佳预防控制的一方却将成本视为外部因素。

更好的激励模型将控制责任与能在事件前以最低成本降低风险的一方捆绑。供应商应使安全默认配置和完整日志成为常态。客户应维护资产清单、补丁窗口、恢复测试和凭证卫生。托管提供商应提供证据包。监管机构和保险公司应在事件前要求这些控制的证明，而非仅仅事后叙述。

治理记录应在新闻周期过后仍然有用

治理记录应在新闻周期消退后仍然有用。该记录应描述触发因素、受影响资产、受影响人员、遏制行动、客户建议、证据质量、残留风险、业务影响、补救负责人和后续测试。它还应展示事件后改变了什么：访问规则、保留期、供应商监督、日志覆盖范围、补丁服务水平、密钥轮换、备份隔离或客户通知手册。

没有该记录，组织只会短暂学习。员工轮换，应急例外保留，临时缓解措施变为永久。同一类事件将以不同产品或供应商关系重现。长效问责记录使得董事会、监管机构、客户或未来的操作员能够在六个月后询问：承诺的修复是否仍然存在？

对于 Vmware International Unlimited Company 而言，持久的教训并非所有可能的损害都已发生，而是这一公开事件暴露了一个将反复出现的控制类别。下一个案例可能涉及不同的产品、地区、攻击者或数据集，但考验将是相同的：组织能否展示谁控制了风险路径、他们做了什么，以及为何外人应信任结果？

什么会改变评估

评估会随证据的强弱而改变。更强的证据包括独立的取证摘要、完整的客户影响类别、从首次检测到遏制的清晰时间线、相关信任材料已被轮换或从未暴露的证明，以及显示同一路径不再有效的后续测试。较弱的证据包括缺乏解释的延迟范围扩大、模糊的数据类别、缺失的日志、类似事件的重复发生，或一种在客户行动必要之时却将客户行动视为可选的模式。

受影响方的证据也会改变评估。能证明无暴露、快速更新、完整日志且无可触及信任材料的客户，应不同于那些存在过期版本、暴露的管理面、不完整日志、重用凭证或敏感支持文件的客户。拥有安全默认配置和狭窄保留策略的供应商，应不同于那些赋予广泛内部工具持续访问敏感记录权限的供应商。

这便是为何一篇好的问责文章既抵制恐慌也抵制赦免。公开记录可以在不证明每一项损失的情况下支持控制发现，可以在不编造事实的情况下识别证据缺口，可以承认供应商负责任地处理了事件的一部分，同时仍质问事件前设计是否创造了可避免的风险。精确并非软弱，而是让问责变得可信。

客户应在记忆褪去前保存的证据

最有用的客户证据通常是在通知发出后的最初几个小时内收集的。管理员应保存认证日志、支持通信、暴露的账户列表、防火墙或端点事件、配置导出、密码重置记录、证书或密钥清单，以及当时存在的供应商通知截图。这些材料日后将解释为何组织选择了狭窄重置、广泛重置、重建、披露或监控响应。没有它们，后续审查将成为对记忆的争论，而非对控制权的记录。

保存之所以重要，也因为供应商通知可能会演变。首次通知可能说调查仍在继续，后续通知可能缩小或扩大受影响人群，安全公告可能添加已被野外利用的状态。保存每个版本的客户可以将其决策映射到当时可用的事实上，这能防范不公平的事后偏见，同时仍能暴露在可靠通知后行动迟缓的情况。

证据不应仅留在安全团队内部。法务、采购、隐私、支持、业务连续性、工程和高管团队各自需要适合其角色的版本。隐私团队需要受影响的数据字段，工程团队需要技术指标和系统负责人，采购团队需要合同义务，支持团队需要面向客户的语言，高管团队需要残留风险和负责人姓名。如果证据正确却困在错误的职能中，单一事件可能仍会失败。

客户行动窗口是一项可量化的责任

供应商端事件往往启动客户端时钟。如果通知要求客户更新软件、轮换凭证、审查日志、禁用暴露接口或警告用户，那么客户的响应时间便成为问责记录的一部分。供应商控制了通知和受影响的服务，客户控制了本地行动，双方都无法单独完成工作。

行动窗口应以匹配风险的尺度来衡量。关键暴露的边缘缺陷可能需要数小时内处理；广泛的元数据暴露可能需要当日钓鱼警告和管理员审查；证书更换可能需要部署更新、清理允许列表，并证明旧的签名包不再受信任；支持工单暴露可能需要附件审查和用户通知；虚拟机管理程序勒索软件浪潮可能需要紧急隔离和备份验证，而非等到常规维护窗口。

关键并非惩罚每一次延迟。有些环境很复杂，公共服务不能随意停止，紧急变更可能破坏基本操作。关键在于使延迟明确化。如果组织延迟，它应记录补偿控制、业务理由、负责人、截止时间以及风险未无限期保持开放的证据。未记录的延迟正是临时例外演变为下一次事件的方式。

修复声明需要持久的证明

当修复声明指明已改变的控制措施及证明该变更仍然有效的证据时，它便更有力。对于身份事件，证明可包括已禁用的服务账户、更短的会话、更强的管理员认证、访问审查以及防钓鱼的重置工作流。对于支持事件，证明可包括更窄的供应商角色、附件保留限制、特权操作日志记录和客户文件净化。对于边缘设备事件，证明可包括外部验证的管理隔离、已修复版本、日志审查、密钥轮换和重建决策。

公开受众不需要每一个敏感细节，但确实需要修复的轮廓。说“安全性已增强”不如说明哪类访问被移除、哪类记录被最小化、哪类凭证被轮换、哪类设备被重建以及哪项测试验证了结果来得有力。具体的修复语言让客户能够将补救措施与故障路径进行比较。

持久性是难点。许多修复在事件后立即显得强大，随后便衰退。临时防火墙规则恢复，旧的支持权限重新增长，新日志未受审查，备份未获测试，培训仅进行一次便消失。因此，问责记录应包含后期的验证点。无法在常规运营中存活的修复只是风险的暂停，而非终结。

托管提供商处于责任链内部

许多受影响组织并不直接管理公开通知中讨论的系统。托管提供商可能操作远程支持工具、构建服务器、邮件平台、防火墙、数据库账户、虚拟机管理程序、帮助台工作流或客户通知。该提供商可以迅速降低风险，也能让客户蒙在鼓里。因此，其证据义务不仅仅是服务礼貌。

托管提供商应准备好告知客户：受影响的产品或服务是否存在、是否暴露、何时更新或隔离、日志是否显示可疑活动、凭证是否轮换、备份是否测试，以及残留风险为何。一句“已处理”对于必须向其自身用户、监管机构、保险公司或董事会负责的客户而言是不够的。

合同应在紧急情况发生前明确这一期望。它们应规定紧急通知触发条件、证据交付、紧急维护权限、凭证所有权、备份责任以及谁为特殊的恢复支付费用。如果合同将安全证据视为可选项，客户可能在事件中发现，自己购买的是正常运行时间，而非可问责性。

数据最小化改变了爆炸半径

最容易保护的暴露记录是那些从未保留的记录。这便是为何在看似技术入侵的事件中，数据最小化至关重要。存储旧附件的支持工具、保留不必要元数据的账户门户、可查看广泛身份证据的客户服务提供商，或聚合了管理员联系信息的企业系统，这些都在攻击者到来前就增加了入侵的价值。

最小化并不意味着假装业务可以无记录运行。支持团队需要足够信息来解决客户问题，安全团队需要日志，金融服务需要受监管的记录，公共交通系统需要账户、优惠、退款和支付操作。控制问题在于，组织能否在事件后证明每个敏感字段、每个保留期、每个供应商权限和每个导出路径的合理性。

更小的记录也改变了通知。如果供应商能说明仅保留并触及了狭窄的字段集，客户便能精确行动。如果供应商保留了广泛的附件或丰富的元数据，通知就变得更困难，下游滥用面也更大。因此，最小化并非隐私口号，而是一种弹性控制，因为它减少了被拖入事件的人员和决策数量。

董事会监督应要求控制证据，而不仅仅是状态

高管通常将事件更新作为状态词接收：已遏制、已补救、无重大影响、调查继续。这些词过于宽泛，无法管控风险。董事会层面的监督应询问哪些控制措施失效或受压力、哪一方拥有这些措施、什么证据证明遏制、哪些客户或用户仍可能受害、哪些修复是持久的，以及哪些仍属未知。

董事会还应询问事件是否揭示了某种模式。这是否是早期支持工具暴露、旧补丁缺口、分割假设、供应商监督弱点或反复未能轮换信任材料的重演？一次事件可能是运气不好，重复的控制模式则是治理证据，表明组织是在学习还是仅仅在应对。

这并不要求董事成为事件响应者，而是要求他们索取决策级证据。他们需要暴露数量、行动窗口、客户义务、法律触发条件、业务连续性影响和后续负责人。当董事会只问故事是否结束，管理层会因安静结案而获奖励；当董事会问什么证据改变了控制环境，修复就变得可见。

事件应改变未来的采购问题

客户应将此类事件转化为更好的采购问题。他们应询问供应商如何限制支持访问、如何净化客户附件、企业 IT 如何与生产服务分离、签名证书如何保护、构建系统如何存储密钥、边缘产品如何记录管理活动、旧版本如何退役，以及客户在安全事件期间如何收到紧急证据。

这些问题应在续约前提出，而非仅在危机后。商业团队可能更倾向于简单的功能对比，但事件表明，运营保证可以像产品能力一样重要。一个拥有广泛支持权限、薄弱日志、迟缓通知和不清晰恢复职责的廉价平台，一旦出错可能变得昂贵。更自律的供应商即使在平安无事时也能降低隐藏风险。

采购也必须避免仅停留在纸面保证。问卷答案应与可测试证据关联：审计摘要、保留设置、角色模型、补丁服务水平、客户通知示例、恢复演练以及可获得的独立评估。目标并非要求不可能实现的透明度，而是购买足够的证据权，使得当供应商成为自身风险面的一部分时，客户不至于无助。

可复用性问责教训

可复用的教训是，现代基础设施事件很少停留在其启动的系统上。受感染的支持提供商可能演变为身份问题，企业系统事件可能演变为客户元数据问题，有漏洞的构建服务器可能演变为软件供应链问题，远程访问产品可能演变为证书信任问题，防火墙或虚拟机管理程序可能成为连续性问题。这些类别重叠，因为客户依赖的是组合服务，而非孤立的盒子。

这种重叠正是为何响应计划应围绕控制面编写。谁拥有身份信任？谁拥有签名软件信任？谁拥有支持数据？谁拥有边缘管理？谁拥有备份？谁拥有客户沟通？谁拥有供应商证据？如果这些负责人在事件前已知，组织便能以较少的混乱做出响应。如果它们是在事件中才被发现，事件就会在人们协商权限的过程中扩大。

一个成熟的组织应能够阅读任何此类未来的通知，并立即将其映射到负责人、行动和证据上。这便是事件意识与事件就绪之间的区别。意识说发生了某事，就绪说明谁必须做什么、在何时之前、用什么证明，以及依赖方将如何知晓。

公共利益结论

公共利益结论是：2023 年利用未打补丁的 VMware ESXi OpenSLP 漏洞 CVE-2021-21974 的 ESXiArgs 勒索软件活动，应被铭记为一次控制测试。该事件考验了组织及其客户能否区分技术遏制与信任恢复，考验了通知是否可操作，考验了敏感记录或信任对象是否被最小化，考验了依赖方是否收到了足够证据来保护自身。

应对此类事件的最强回应并非更大声的保证，而是更窄的风险路径、更快的遏制路径、更完整的证据路径和更清晰的客户行动路径。这意味着：减少不必要的数据、收缩广泛的支持权限、收紧管理边界、加强业务与服务环境之间的分离、实现更好的日志记录、经过测试的恢复，以及在信任不确定时更快速地撤销凭证或证书。

VMware ESXiArgs 事件表明旧版补丁如何变成连续性责任，因为该组织处于许多其他方必须依赖其证据的位置。当这一点成立时，问责就跟随实际控制面。拥有最清晰可见性和最强大减少损害能力的一方，不能仅仅宣称事件已结束，而必须展示为何信任关系可以安全地继续。