【51CTO.com快译】想了解更多关于虚拟补丁的信息吗?查看下本文，我们将讨论什么是虚拟补丁，它的类型以及它可以为您的应用程序做什么。
美国个人信用评估机构Equifax估计其与2017信息泄漏事件相关的损失将超过6亿美元。不仅仅是Equifax遭受了巨大的经济打击。事实上,由于过时的软件，在过去的一年中有数十家其他组织的收入损失超过了1亿美元。
根据Gartner的数据，99%的漏洞都不是零日漏洞。相反，它们大多是已知至少一年的漏洞。事实上，大多数IT基础设施都同时包括了遗留平台、未打补丁的软件、过时的第三方组件和糟糕的补丁管理流程。可以说，坏人发现一个未及时修补漏洞的应用程序要比发现一个零日漏洞容易得多。
为什么一直存在着补丁问题?
大多数情况下，对最终用户的应用程序进行打补丁可能非常简单。然而，对于企业软件来说，这就是一个完全不同的故事了。这是因为企业软件在本质上更加复杂。在大多数情况下，为企业软件安装补丁是一个昂贵的手工过程，它由几个严格的步骤组成，而且这些步骤不能总是在正常的工作时间内完成，通常需要关键系统的离线。
但是停机对于企业来说通常会造成极大的损失，为了避免停机，已经有了一些策略和技术，比如滚动更新、blue-green部署和canary发布。但这些策略通常非常复杂，极易出错，而且耗时，需要仔细的规划以及进行平台和基础设施的更改。此外，软件的新版本还经常附带不向后兼容的新功能，并且有可能中断应用程序的正常运行。
打补丁终究是一场必败的战斗
根据Sonatype的说法，每天都有超过10000个开源组件的新版本发布，并提供了新的特性、bug修复和安全补丁。然而更令人吃惊的是，据Mitre统计，2017年出现了近15，000个新的漏洞。平均每天有41个新漏洞被揭露，或者每30分钟就有一个新漏洞被揭露。
在攻击者利用其固有优势进行攻击之前，根本没有足够的时间或资源及时地解决这些缺陷。因此，补丁工作向来是IT部门面临的一个重大挑战。显然，与未修复的软件风险相比，当下的组织更看重截止日期，而不是降低生产力。通常情况下，团队会接受风险，并选择在更“方便”的时间进行修补，通常是每季度才会开展一次修复工作甚至等待更长的时间。然而，这种做法为别有用心的人创造了机会。
每当有新补丁被发布来修复漏洞时，恶意行为者就会争分夺秒地寻找那些没有对系统进行修补的组织并利用该漏洞。在安全警报公开发布几小时后就看到恶意活动已经成为一种常见的情况。根据Ponemon最近的研究，攻击者成功利用漏洞平均需要三到六天的时间，而发现攻击的时间要超过250天，另外还需要82天才可以控制攻击。这就提出了一个关键的问题:组织如何才能在延迟系统修复时间的同时保护他们的资产?
虚拟修补才是关键
虚拟补丁是指在不修改应用程序源代码、修改二进制代码或重新启动应用程序的情况下，能够即时建立的一个安全策略实施层，用来防止对已知漏洞的攻击。使用虚拟补丁策略，组织可以在大幅减少补丁所需的成本、时间和工作之间取得很好的平衡，同时保持服务的可用性和正常的补丁周期。
虚拟补丁可用于临时添加保护，使DevSecOps团队有时间根据自己的更新计划部署物理补丁。虚拟修补程序也可以永久用于可能无法修补的遗留系统。
此外，由于没有在磁盘上更改应用程序文件，因此引入冲突或不兼容的可能性也较小。
另外，软件供应商通常以捆绑的方式发布其安全修复程序，这些修补程序只能选择全部安装或者全部不安装。当其中一个修复程序导致应用程序出现功能问题时，就必须卸载整个安全包。
但虚拟补丁能够允许组织挑选对其环境重要的补丁，并允许它们回滚与应用程序功能不兼容的特定补丁。
虚拟补丁的类型
虚拟补丁最初是几年前由IPS/IDS社区首创的。后来，虚拟补丁被引入WAF领域，最近，RASP产品也提供了类似的功能。
不过，有必要说明的是，并非所有的虚拟补丁解决方案都是一样的。一般来说，我们可以根据能够交付的补丁质量对虚拟补丁进行分类。
第一种类型的虚拟补丁完全基于对网络流量的分析。提供这种类型的虚拟补丁的系统使用签名、正则表达式和模式匹配来识别恶意活动并阻止相应的请求。
第二种类型的虚拟修补基于相同的原理;但是，它提供了一种更健壮的方式来指定阻止请求的标准，可以使用规则语言和状态管理等功能。ModSecurity就是这种虚拟补丁解决方案的一个例子。
这些类型的虚拟修补有几个缺点。由于它们缺乏上下文感知的能力，这些虚拟补丁技术会产生大量的误报和漏报。因为签名和模式匹配是启发式的方法，不能提供高效所需的准确性。所以,这类写得不好的虚拟补丁可能会阻塞合法的流量，干扰应用程序的正常执行，给必须过滤掉错误警报的安全团队增加额外的工作量。因此使用这种类型的虚拟补丁，并不能带来安全上的质的提升。好的补丁修复程序不应该依赖于工程师的技能和他们编写虚拟补丁签名的能力。
此外，这种类型的补丁需要经常修改。对于Web应用程序来说，只要易受攻击的URL或HTTP参数进行了更改，虚拟修补程序就会失效并需要进行重新配置。
更重要的是，这些方法事实上只是保护了特定的输入，没有保护易受攻击的组件。如果有多个入口点导致了相同的受攻击组件，虚拟补丁则无能为力。
所以说上述方法提供了“修补”功能是言过其实的，因为即使在应用了虚拟修补程序之后，代码仍然容易受到攻击。这就是为什么有些人将这些方法称为“漏洞屏蔽”，而不是修复的原因了。
第三种类型是虚拟补丁的自然演变，它利用了当代运行时平台(如Java虚拟机和公共语言运行时)的即时编译器。在应用程序内部，只要能够在执行每条指令之前控制它，就可以实现真正的虚拟补丁。现在，在不修改应用程序的源代码或二进制文件的情况下，交付一个在功能上与供应商的物理补丁相同的虚拟补丁是可行的，同时又能确保组件得到适当的修补，不再容易受到攻击。
运行时编译管道中的虚拟补丁是社区从一开始就渴望实现的虚拟补丁类型。WAF/IDS工程师们虽然预见到了虚拟修补的吸引力，但是由于缺乏对运行时平台的控制以及将这种解决方案置于应用程序之外的架构限制，迫使虚拟修补或多或少成为了一种复杂的输入/输出验证解决方案。
但这并不意味着这些类型的虚拟补丁没有用处。相反，在某些情况下，应用输入验证型虚拟补丁是有意义的。比如，考虑到那些遗留系统和生命周期结束系统的情况，或者供应商没有发布安全修复程序的情况。最近，Sonatype发现，84%的开源项目没有修复已知的安全缺陷。对于这种情况，基于输入验证类型的虚拟补丁的补偿控制可能是保护这种系统的唯一方法。
虚拟补丁已经发展到了这样的一个程度，它可以是一个自动化的过程，几乎不需要人工干预，并且与物理补丁一样有效，甚至更健壮。随着法规遵从性方案要求更严格的补丁程序管理流程，安全团队在漏洞和补丁程序管理程序中采用虚拟补丁策略的时机已经到来了。
虚拟修补有多种类型，每种类型都有自己的优势。当团队评估他们的补丁需求时，他们必须确保自己心中有一个明确的目标，那就是他们为什么要打补丁，以及他们想要实现怎样的目标。对未修复的底层软件缺陷的已知签名的屏蔽是否已经足够?还是说需要的是一个在功能上等同于物理补丁并能够修复所需软件缺陷的虚拟补丁?
原文地址：Overview and Evolution of Virtual Patching，作者：Apostolos Giannakidis
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
