Virtual patching is a highly effective technique for countering zero-day threats, i.e., stealthy cyber threats designed to exploit system and application vulnerabilities that software vendors have yet to release a patch for. In this post, we explain what virtual patching is, why it’s essential for effective threat prevention, and what virtual patching method works best in most scenarios.
Why do we need Virtual Patching? Can’t we just patch the application itself?
While patching the source code of the application might seem the obvious and most effective course of action, it isn’t always feasible in the real world.
- This process is heavily dependent on the software vendor, which needs to develop the patch. This can often take a long time, assuming the vendor develops the patch at all. If the vendor doesn’t deem it a priority, it may delay development of a patch indefinitely.
- Once the patch is made readily available, it still needs to be applied and installed on all the vulnerable end points. This too can be very time consuming and therefore is often delayed. The Symantec Internet Thread Report states that, on average, it takes organizations 55 days to patch their systems. When taking into account that this same report states that it takes on average 6 days for threat actors to start releasing malicious code which exploits these vulnerabilities, you can understand why a faster solution is needed.One real-world example that highlights this issue is the WannaCry Ransomware Attack, which affected 300,000+ computers globally. WannaCry exploited a vulnerability in Microsoft’s implementation of the Server Message Block (SMB) protocol. Although Microsoft released patches for all supported Windows versions on March 14, 2017, many systems still remained unpatched on May 12 of that year—practically 2 months after—when the first incidents were reported.
- There are end-point-run legacy software applications that simply can’t be upgraded to a current OS—and therefore a current version of the application—thereby making the process of applying a patch impossible.
Of course, leaving a vulnerability unprotected is out of the question. So, in cases like these, when patching a software’s source code is not yet possible or not possible at all, the best alternative is to apply virtual patching.
CVE based – The most common method of virtual patching
Currently, the most common virtual patching methods are CVE-based )Common Vulnerabilities and Exposures).
A CVE is a database of publicly disclosed security vulnerabilities and exposures that are uniquely identified using CVE IDs and represents a known vulnerability that can be exploited by threat actors. CVEs are released by security and application vendors daily. Many CVEs have exploits created for them. Some exploits are just proof-of-concepts (POCs), built to demonstrate the exploitability of a vulnerability, while others are readily used in the wild, wreaking havoc in user and IT environments.
Each CVE is given a severity rating based on how easy the vulnerability can be exploited and how big the impact is if exploited. Vendors that support CVE-based virtual patching in their threat prevention solutions typically take these severity ratings into consideration when assessing whether to implement a patch for it in their product or not.
Proper assessment is necessary since each CVE rule consumes memory on the endpoint. Basically, it is a virtual addition which sits on TOP of the existing OS in the memory. In other words, each additional CVE implementation can adversely impact the endpoint’s performance.
Traditional Virtual Patching methods are weighed down by the following problems:
- Need to wait for CVE release: Traditional virtual patching methods are still at the mercy of CVE patch provider. Once a CVE-ID is assigned to a vulnerability, it gets assigned a “reserved” status until the actual CVE is published. On average, a CVE is published 40 days after its CVE-ID is assigned. However, more than 10,000 CVEs have been stuck in “reserved” status for more than two years[2]. This means that even after a vulnerability is discovered, there is often still a critically long time until a virtual patch can be applied. As we stated before, it takes threat actors only 6 days on average to start releasing malicious code that exploits new vulnerabilities!
- Heavy Resource Consumption: Traditional methods cause performance issues and demand high operational overhead. Each virtual patch (CVE) applied sits in the endpoint memory in addition to all the previous patches and software, meaning the more patches you apply, the more resources will be used by the virtual patch. This will eventually cause a real negative impact to the endpoint’s performance.
- Lacks Flexibility: Organizations are fully dependent on the vendor. With each new vulnerability, the organization has to wait for the vendor to add a new virtual patch (CVE rule) to the CVE database. In some cases, the vendor may decide that the desired patch for the customer’s internal system is NOT critical enough (CVE exploit has no PoC, low footprint in the wild, etc.) and will therefore choose not to add it to the CVE database.
- Limited (unknown / future) coverage: Each CVE covers one specific, known vulnerability. Patching this single vulnerability will not protect the user from unknown vulnerabilities in the future, even if applied to the same resource.
Minerva’s Virtual Patching through simulation and isolation
Minerva offers a unique way of applying virtual patching (VP). Rather than leaving the organization completely at the mercy of the threat prevention solution vendor (i.e., to add a new CVE rule), Minerva instead empowers organizations to proactively apply the CVE rule (the ‘patch’) themselves. This significantly reduces an attacker’s window of opportunity while allowing the user to secure a much larger scope of vulnerabilities.
How does Minerva’s Virtual Patching work?
Minerva’s Virtual Patching allows users to easily define how processes and files are seen by and can communicate with their surroundings. This lets us create virtual patching rules which can easily close known (and unknown) vulnerabilities of specific processes or files.
For example, in 2021 a remote code execution vulnerability was found on the Microsoft Windows Print Spooler. Exploiting this vulnerability would allow a user to remotely execute malicious code on the endpoint. With Minerva’s VP, the user can easily isolate the Print Spooler and prevent any code from being spawned or executed from that process, regardless of the vulnerability. The Virtual Patch can also be used to isolate the process, so only predefined processes or commands can see/access the spooler, further securing against future not-yet-known vulnerabilities.
Applying a CVE rule to Minerva’s Virtual Patching module is quick and easy, and can also be performed on legacy systems that are no longer supported by manufacturers. Since the Virtual Patch serves as a layer between the process and the OS, once it is deployed, the user will receive alerts if ever there is an attempt to exploit the vulnerability. The VP can be applied at various levels, e.g. at the process level, at the file level, and so on.
Thousands of CVEs are released every month, with over 500 CVEs often being released in a single day! Unlike traditional virtual patching methods, Minerva’s VP has no impact on the endpoint device’s performance. This also allows it to simultaneously support an unlimited number of VP rules. This is important because users are naturally opposed to security solutions that hamper productivity. If a VP solution causes devices to slow down, users might secretly look for methods to disable it.
Figure 1: Number of CVEs released each day 2019 – mid Feb 2022.[1]
A CVE-based VP solution is limited to published/known vulnerabilities. If a new threat exploits an unknown vulnerability, that CVE-based VP solution won’t be able to counter it. Minerva does not have this limitation.
Minerva’s Virtual Patching vs traditional methods
|
Parameter |
Minerva |
Traditional |
|
No impact on endpoint resources or speed |
 |
 |
|
Supports unlimited virtual patches |
|
|
|
No dependency on security vendor / software releases |
|
|
|
Personalized patch creation |
|
|
|
Local endpoint level protection |
|
|
|
Supports legacy (end of life) systems |
|
|
|
Agentless |
|
|
To learn more about Minerva’s anti-ransomware platform and virtual patching feature, feel free to contact us.
Resources
[1] cve.icu/calendar.html
[2] unit42.paloaltonetworks.com/state-of-exploit-development