PDF后 Meltdown 时代的生活指南
和 -Spectre 时代的生活指南
从过去中学习，为下一场战斗做好准备。
Rich Bennett、Craig Callahan、Stacy Jones、Matt Levine、Merrill Miller 和 Andy Ozment
漏洞管理的世界正在快速变化，以跟上潜在威胁的复杂性，这些威胁需要修复。未来 10 到 15 年，生活在这个环境中会是什么样子？
1996 年，Aleph One 发表了《为了乐趣和利益而粉碎堆栈》。1 在接下来的十年里，堆栈粉碎是一种常见的利用形式，安全社区花费了大量精力来寻找防御它的方法。Spectre 和 Meltdown 漏洞可能构成一个同样具有开创性的时刻，开启长达十年或更长时间的长期风险管理问题。事实上，最近发布了两个变体：SpectrePrime 和 MeltdownPrime，Caroline Trippel、Daniel Lustig 和 Margaret Martonosi 最近的一篇论文中对此进行了详细介绍。3 预计这将是众多变体中的第一个。
Spectre 和 Meltdown 创建了一个风险格局，其中问题多于答案。本文探讨了在宣布这些漏洞时如何对其进行分类以及可用的实用防御措施。最终，这些漏洞呈现出一系列独特的情况，但对于高盛的漏洞管理计划而言，应对措施只是日常工作。
初步分类和补丁
虽然这些漏洞在理论上令人着迷，但我们必须接受它们的实际影响。作为高盛（一家拥有约 35,000 名员工的大型企业）的风险管理人员，我们不得不迅速应对漏洞的宣布。此外，我们还必须继续管理未来十年内因新变体或类似漏洞而产生的风险。
我们在 2018 年 1 月 3 日公开宣布漏洞时了解了这些漏洞。之所以比计划提前宣布，是因为消息已经开始泄露。这意味着许多供应商尚未发布补丁或准备关于影响、缓解策略以及补丁可用时间表的客户沟通。供应商无法立即帮助理解这些漏洞。
发布任何重大漏洞时的首要挑战是收集信息：哪些系统受到影响，补丁何时可用，有哪些补偿性控制措施到位，以及漏洞是否正在被积极利用？如果知道漏洞是否正在被历史上以贵公司为目标的威胁行为者利用，那就更好了。
Meltdown 和 Spectre 特别难以分类。早期就很清楚某些处理器系列受到影响，但怀疑全部范围要广泛得多。此外，我们的硬件和软件清单侧重于操作系统、应用程序和整体计算机型号。它们并未设置为快速显示处理器的品牌和型号。
如果修补我们所有的机器会更简单，但我们对补丁可能会导致显着性能影响的消息持谨慎态度。
最初，关于补丁性能影响的估计在博客和文章中差异很大，并且没有在官方文件中直接引用。2018 年 1 月 18 日，Altaro.com 的 Eric Siron 总结了这种情绪，他说：“我们都看到了 Meltdown 补丁可能会影响 5% 到 30% 性能的估计。我们没有看到的是可靠的数据集，表明在真实环境中会发生什么。”2 这些范围在我们自己的补丁测试中得到了证实，某些系统比其他系统遭受了更严重的减速。此外，与其他首席信息安全官的圆桌会议表明了类似的范围。
这些补丁具有特别差的风险权衡：潜在的性能影响高，安全效益不完善。通常，补丁会修复漏洞。由于这些是基本的设计漏洞——更糟糕的是，硬件设计中的漏洞——补丁机会有限。它们不是修复根本漏洞，而是基本上设置了一个迷宫来阻止对手利用它，但根本漏洞仍然存在。此外，我们处理复杂漏洞的经验是，第一个补丁通常存在缺陷，因此我们预计许多补丁会随着时间的推移而更新——这一预期后来被证明是正确的。
尽管修补显然会成为问题，但我们的快速分类突出了一些好消息。利用这些漏洞需要在受害者机器上本地执行代码。这导致考虑哪些操作系统环境部分可能运行不受信任的代码：公共云中的虚拟机监控程序、员工端点（如台式机和笔记本电脑）、移动设备以及经常打开电子邮件附件的浏览器或应用程序。由于补丁可能会对性能产生重大影响，因此每个决策都必须涉及风险权衡。
结论是，台式机的风险最高，测试表明性能影响将是可管理的。因此，我们立即开始修补我们所有的台式机。对于服务器，我们决定进一步调查并做出更细致、基于风险的决策。网络攻击的风险必须与补丁破坏或显着减慢系统的操作风险相平衡。
没有信息表明这些漏洞正在被积极利用，这令人放心。另一方面，这些漏洞的性质是难以检测到利用。如果我们知道漏洞正在被利用，即使补丁破坏某些系统的风险很高，我们也会尝试推送补丁。对于这些漏洞，缺乏已知的利用加强了我们花更多时间评估服务器的决定。
为了帮助评估风险，我们通过以下视角检查了我们的补丁策略和补偿性控制措施：公共云、服务器、员工端点、浏览器和电子邮件。这些视角还有助于向我们的业务领导层传达风险。
公共云
研究表明，利用 Meltdown 和 Spectre 的攻击可能会以公共云环境为目标。在某些情况下，攻击者可能会击败公共云提供商使用的技术，以确保客户实例之间的隔离。如果恶意用户能够绕过虚拟机监控程序或容器引擎控制，则该用户可以访问与同一硬件上并置的其他客户的数据。
因此，我们最直接的担忧是公共云提供商。公共云风险可以进一步细分为实例到实例的攻击和实例内部的攻击。
在实例到实例的攻击中，客户可能会攻击同一虚拟机监控程序上的另一个客户。Meltdown 是这种攻击最明显的载体。攻击者理论上只需支付公共云上的实例费用，然后以该硬件上的任何其他客户为目标。幸运的是，包括亚马逊、谷歌和微软在内的几家大型提供商已收到提前通知，并已完成或几乎完成了对其虚拟机监控程序的初步修补，以解决这些担忧。此外，一些提供商告知我们，他们在漏洞公开之前几个月就已修补，而没有任何明显的性能影响。
对于实例内部的攻击，攻击者必须在同一实例上运行代码。这将需要访问系统或应用程序才能利用漏洞。目前尚不清楚需要做些什么才能完全防止可能用于此攻击的多种变体。公共云提供商实施的保护措施修复了 Meltdown，但 Spectre 变体需要多种缓解措施。谷歌发布了一种名为 Retpoline 的二进制修改技术，它使用该技术来修补其系统以应对 Spectre Variant 2。与 CPU 补丁相比，这具有最小性能影响的优势。其他提供商的缓解措施包括芯片固件、虚拟机监控程序补丁、操作系统补丁，甚至应用程序重写。
Spectre 修复变得更加复杂，因为客户和云提供商必须协同工作，具体取决于使用的云服务。我们的影响分析确定，在公共云中运行实例并没有显着增加实例内部的风险：它本质上与内部服务器面临的风险相同。因此，我们像对待所有服务器一样对待它：通过做出个别的、基于风险的决策。
服务器
在高盛，服务器性能至关重要，因此我们在修补服务器时必须小心。在金融服务领域，许多关键应用程序对时间敏感，只有在处理迅速完成时才有效——例如，执行交易或大规模复杂风险计算的应用程序。此补丁可能会产生非常实际的影响。如果每晚用于执行复杂风险计算的数十万个公共云处理器的处理速度降低 30%，除了可能引发的操作风险以及对稳健和实时风险管理的潜在担忧之外，我们的账单可能会显着增加，以补偿损失的计算能力。
服务器修补实际上变成了理解公司数千个内部应用程序并对其做出基于风险的决策的问题。对于某些应用程序，性能至关重要，并且运行不受信任的代码的可能性很低。在这些情况下，我们——以及我们交谈过的其他主要公司——决定不修补。对于这些应用程序，我们依赖于补偿性控制措施以及它们极不可能运行不受信任的代码这一事实。对于其他应用程序，我们评估风险更高并修补了它们的服务器。为了进行这种类型的基于风险的分析，公司必须了解其应用程序的行为（应用程序分析）和风险（基于风险的分类）。
端点
员工端点（如台式机和笔记本电脑）也是我们分类过程中的高度优先事项，因为它们可以通过网络和电子邮件访问互联网。这些是寻求利用这些漏洞的威胁行为者可能尝试传递恶意软件的关键渠道。
高盛端点响应有两个关键主题：修补和控制。由于用户端点比服务器更有可能运行不受信任的代码，因此我们决定在所有情况下都进行修补，除非是最特殊的情况。因此，我们在托管的 Windows、macOS 和 iOS 设备可用时迅速部署了补丁。由于担心潜在的最终用户性能影响，能够在隔离的端点集上运行可重复的自动化测试，然后再将补丁推送到整个企业，这非常有益。
修补不仅仅关注操作系统。我们还考虑了员工台式机上组件的补丁可用性，这些组件可能允许执行不受信任的代码——例如，打开与业务相关的文档的应用程序。不幸的是，即使几个月后，许多这些应用程序仍未被其供应商修补。
我们的评估包括端点上可用的更广泛的控制集——包括预防性和检测性控制。我们最感兴趣的是确定哪些防御层可以在降低风险方面发挥作用。对于预防，我们审查了我们构建和应用程序白名单功能的配置强化，并得出结论，它们不需要任何更改。我们还在我们的端点和传入电子邮件上使用基于签名和基于启发式的恶意软件检测。当然，只有在漏洞利用公开时，基于签名的工具才会有价值。
不仅要查看所有可能的选项来降低风险很重要，而且还要拥有基础模块来控制可以适应以降低不断发展的环境中广泛威胁的控制。
浏览器
网络包含大量可能尝试利用这些漏洞的恶意网站。即使是合法的网站也可能无意中托管恶意广告。或者，在水坑攻击的情况下，对手可能会入侵一家公司的员工群体已知访问的网站，并使用它来传递恶意代码。
在高盛，我们使用网络代理和服务对域名进行分类以降低风险。我们的代理设置非常保守，阻止与我们的业务无关或可能存在风险的整个网页类别。这包括许多用于托管广告的服务器，因此我们已经进行了相当数量的广告阻止。代理还阻止下载可执行文件。
此外，谷歌 Chrome 和 Microsoft Edge 具有站点隔离功能，可阻止恶意代码影响浏览器窗口中的多个选项卡。与修补一样，这对于这些漏洞来说不是一个完美的缓解措施，但它确实提供了部分控制和另一层防御。由于此功能甚至在某些补丁之前就已准备就绪，因此已迅速实施。虽然我们担心它会破坏许多内部或外部站点，但实际上问题很少。
更具体的浏览器补丁在最初的漏洞披露后的几天到几周内发布。我们迅速推送了这些补丁。我们有数百名开发人员使用非标准浏览器来测试他们的应用程序，因此我们在用户端点上使用了应用程序白名单，以确保仅使用托管浏览器或批准和修补的例外情况。
浏览器插件也可以执行不受信任的代码。作为部分缓解措施，可以将特定插件锁定到一组白名单站点。很少有插件发布补丁，因此这仍然是一个令人担忧的领域。
一些公司还选择虚拟化浏览器，以将应用程序与操作系统隔离。浏览器可以虚拟化为独立应用程序或整个桌面操作系统。如果任何关键任务 Web 应用程序在旧版浏览器上或使用插件运行，则虚拟化浏览器可以为执行此操作提供更受保护的机制。
电子邮件
电子邮件是另一种常见的不受信任代码载体。它不太可能成为利用这些漏洞的工具，因为大多数攻击向量都包含缓存计时攻击，这些攻击很难或不可能通过电子邮件利用。尽管如此，解决网络钓鱼攻击作为一般利用手段非常重要。包括高盛在内的大多数公司都使用各种技术来阻止基于电子邮件的攻击。
最简单的技术是阻止某些类型的附件。如果您的业务支持，这是一种相对廉价的控制措施，可以产生重大影响。不幸的是，许多企业依赖于共享 Office 文档（如 PDF 或 Excel 文件）的能力，这些文档可能包含宏或其他类型的代码。
当然，网络钓鱼电子邮件不一定包含附件。它们也可能包含指向恶意网站的链接。我们重写传入的 URL，以便出站调用必须通过中央控制点，我们可以在其中快速实施阻止。出站 Web 连接也必须通过前面描述的基于代理的控制措施。
此外，我们在分层方法中使用基于签名的电子邮件阻止技术。但是，只要没有已知的漏洞利用，就没有已知的签名可以部署。当漏洞利用从研究概念验证转变为武器化时，这将是需要跟踪的领域。
“燃烧室”可能会更有价值，它在虚拟机中打开附件并查找恶意行为。一些燃烧室供应商正在考虑运行未修补的虚拟机并使用它们来检测这些漏洞的利用。
硬件修复
虽然补丁和控制是这里的重点，但硬件修复并非完全不可能。英特尔在其第四季度财报电话会议中表示，采用硅芯片更改（直接解决 Spectre 和 Meltdown）的芯片将于今年晚些时候开始上市。然而，与操作系统补丁类似，第一代硬件修复可能无法完全解决这些漏洞。此外，组织需要数年时间才能使用新芯片升级所有硬件。
仅仅是漏洞管理的又一天？
这些漏洞推动了高盛的漏洞管理流程，但并没有破坏它。我们习惯于在这个领域进行风险权衡：例如，您是否更快地修补以降低网络利用的风险，即使这会增加操作崩溃的风险？
这些漏洞带来的风险是这种情况更具挑战性的版本。问题不仅仅是补丁是否会破坏系统，而是它们是否会对性能产生重大影响。必须以分布式方式评估该风险，因为它对每个应用程序都是唯一的。与此同时，关于这些漏洞以及它们可能被轻易利用的程度存在很多不确定性。因此，当操作风险和网络攻击风险都不明确时，我们必须平衡两者。
Meltdown 和 Spectre 等漏洞的范围如此之广，以至于难以解决。在最好的情况下，对于像高盛这样拥有专门的威胁、漏洞管理和基础设施团队的组织来说，这是一种极其复杂的情况。对于没有专门分类团队的中小型企业来说，导航可能更难。我们在很大程度上依赖供应商协调以明确补丁依赖性，并且有时仍然必须在答案不完美的情况下前进。
良好的网络卫生习惯仍然是基础——漏洞的性质不同，但管理它的框架和方法没有改变。在零日漏洞和 Spectre 和 Meltdown 等多维度漏洞的世界中，响应分类和优先考虑降低风险努力的速度和有效性对于所有组织都至关重要。更多备受瞩目和复杂的漏洞肯定会随之而来，因此现在是从 Spectre 和 Meltdown 中吸取经验教训，并利用它们来帮助为下一场战斗做好准备的好时机。
参考文献
1. Aleph One。1996 年。为了乐趣和利益而粉碎堆栈。Phrack 49(7)； http://phrack.org/issues/49/14.html#article。
2. Siron, E. 2018 年。Spectre/Meltdown Hyper-V 更新的实际性能影响。Hyper-V 博客； https://www.altaro.com/hyper-v/meltdown-spectre-hyperv-performance/。
3. Trippel, C.、Lustig, D.、Martonosi, M. 2018 年。Meltdown Prime 和 Spectre Prime：自动合成的攻击，利用基于无效化的相干协议。 https://arxiv.org/abs/1802.03802。
相关文章
保护错综复杂的网络
Christoph Kern
通过软件设计预防脚本注入漏洞
https://queue.org.cn/detail.cfm?id=2663760
领先一步
Vlad Gorelik
安全漏洞比比皆是，但一些简单的步骤可以最大限度地降低您的风险。
https://queue.org.cn/detail.cfm?id=1217266
了解软件补丁
Joseph Dadzie
开发和部署补丁是软件开发过程中越来越重要的组成部分。
https://queue.org.cn/detail.cfm?id=1053343
Rich Bennett、Craig Callahan、Stacy Jones、Matt Levine、Merrill Miller 和 Andy Ozment 是高盛全球技术风险和信息安全团队的成员。
版权所有 © 2018，归所有者/作者所有。
最初发表于 Queue 第 16 卷，第 4 期—
在 数字图书馆 中评论本文
更多相关文章
Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用机密联邦学习的可信赖人工智能
安全性、隐私性、问责制、透明度和公平性原则是现代人工智能法规的基石。经典的 FL 设计非常强调安全性和隐私性，但以透明度和问责制为代价。CFL 通过将 FL 与 TEE 和承诺相结合，弥补了这一差距。此外，CFL 还带来了其他理想的安全属性，例如基于代码的访问控制、模型机密性以及推理期间的模型保护。机密计算（如机密容器和机密 GPU）的最新进展意味着可以无缝扩展现有的 FL 框架，以低开销支持 CFL。
Raluca Ada Popa - 机密计算还是密码计算？
通过 MPC/同态加密与硬件 enclave 进行安全计算，需要在部署、安全性和性能之间进行权衡。关于性能，重要的是您想到的工作负载。对于简单的求和、低阶多项式或简单的机器学习任务等简单工作负载，这两种方法都可以在实践中随时使用，但对于复杂的计算（如复杂的 SQL 分析或训练大型机器学习模型），目前只有硬件 enclave 方法在许多实际部署场景中足够实用。
Matthew A. Johnson, Stavros Volos, Ken Gordon, Sean T. Allen, Christoph M. Wintersteiger, Sylvan Clebsch, John Starks, Manuel Costa - 机密容器组
此处介绍的实验表明，Parma（在 Azure 容器实例上驱动机密容器的架构）增加的额外性能开销不到底层 TEE 增加的额外性能开销的百分之一。重要的是，Parma 确保了容器组在证明报告中扎根的所有可达状态下的安全不变性。这允许外部第三方与容器安全地通信，从而实现广泛的容器化工作流程，这些工作流程需要对安全数据的机密访问。公司获得了在云中运行其最机密工作流程的优势，而无需在其安全要求上妥协。
Charles Garcia-Tobin, Mark Knight - 使用 Arm CCA 提升安全性
机密计算具有通过将监管系统从 TCB 中移除来提高通用计算平台安全性的巨大潜力，从而减小 TCB 的大小、攻击面以及安全架构师必须考虑的攻击向量。机密计算需要平台硬件和软件方面的创新，但这些创新有可能增强对计算的信任，尤其是在由第三方拥有或控制的设备上。机密计算的早期消费者将需要自行决定他们选择信任的平台。
© 保留所有权利。