Overview and Evolution of Virtual Patching

This article is featured in the new DZone Guide to Security: Defending Your Code. Get your free copy for more insightful articles, industry statistics, and more!

Equifax estimates the costs associated with a 2017 security breach will exceed $600 million. And it is not just Equifax that has suffered a tremendous financial hit. Dozens of other organizations have lost more than$100 million in revenue over the past year due to outdated software.

According to Gartner, 99% of vulnerabilities exploited are not zero-days. Instead, they are vulnerabilities that were known for at least one year. In fact, most IT infrastructures include legacy platforms, unpatched software, outdated third-party components, and poor patch management processes. It is much easier for bad guys to find unpatched applications than to discover a zero-day vulnerability.SO,

Why Is Patching Still a Problem?

Patching for end-user applications may be simple to trivial most of the time. However, it is an entirely different story for enterprise software. This is because enterprise software is inherently more complex. Installing a patch for enterprise software is, in most cases, an expensive and manual process that consists of several rigorous steps that cannot always be done during regular business hours and typically requires critical systems to be offline.

Downtime is a precious commodity for enterprises and to get around it there are strategies and techniques such as rolling updates, blue-green deployments, and canary releases. Such strategies are very complex, highly error-prone, and time-consuming, and require careful planning as well as platform and infrastructure changes. Additionally, new releases of software oftentimes come with new functionality that is not backward-compatible and has the potential to disrupt the normal operation of the application.

Patching Is a Losing Battle

According to Sonatype, more than 10,000 new versions of open-source components are released daily, offering new features, bug fixes, and security patches. What is more astonishing though is that, according to Mitre, almost 15,000 new vulnerabilities surfaced in 2017. That is an average of 41 new vulnerabilities disclosed per day or a new vulnerability every 30 minutes.

There simply is not enough time or resources to address these flaws in a timely fashion before attackers use their inherent advantages to find a way in. Therefore, patching is a significant challenge for IT departments. Organizations value meeting deadlines and not slowing productivity more than the risk of unpatched software. What commonly happens is teams accept the risk and patch at a more “convenient” time, usually once per quarter or longer. However, this practice creates a window of opportunity for the bad guys.

Any time a new patch is released to fix a vulnerability, it starts a race against the clock for malicious actors to find organizations with unpatched systems and exploit the flaws. It has become a common case to see malicious activity just hours after security alerts are publicly released. According to recent Ponemon study, it takes, on average, three to six days for an attacker to successfully exploit a vulnerability, more than250 days to discover an attack is underway, and an additional 82 days to contain the attack. This raises a critical question: How can organizations protect their assets while deferring the actual patching of their systems?

Virtual Patching to the Rescue

Virtual patching refers to establishing an immediate security policy enforcement layer that prevents the exploitation of a known vulnerability, without modifying the application's source code, binary changes, or restarting the application. Using a virtual patching strategy, organizations can achieve a nice balance between substantially reducing the cost, time, and effort needed to patch while maintaining their availability SLAs and normal patching cycles.

Virtual patching can be used to add protection temporarily, giving DevSecOps teams time to deploy physical patches according to their own update schedules. Virtual patches can also be used permanently for legacy systems that may not patchable.

Additionally, there is less likelihood of introducing conflicts or incompatibilities as no application files are changed on disk.

Moreover, it is common for software vendors to release their security fixes in bundles that are installed in an all-or-nothing approach. When one of the fixes causes functional issues to the application, then the whole security bundle must be uninstalled.

Virtual patching allows organizations to cherry-pick which patches are important to their environments and lets them rollback specific patches that are not functionally compatible with the application.

Types of Virtual Patching

Virtual patching was initially pioneered by the IPS/IDS community quite a few years ago. Later, virtual patching was brought into the WAF space and, most recently, RASP products offer similar capabilities.

It is important to clarify, though, that not all virtual patching solutions are equal. In general, we could classify virtual patching according to the quality of the patching that can be delivered.

The first type of virtual patching is purely based on analyzing network traffic. The system that offers this type of virtual patching uses signatures, regular expressions, and pattern matching to identify malicious activity and block the corresponding requests.

The second type of virtual patching is based on the same principles; however, it offers a more robust way of specifying the criteria to block requests, using a rules language and capabilities such as state management. ModSecurity is an example of such a virtual patching solution.

Virtual patching of these types has several disadvantages. Because they lack context-awareness, these virtual patching techniques are notorious for generating false positives and false negatives. Signatures and pattern-matching are heuristic approaches that cannot offer the accuracy that is required to be highly effective. A poorly written virtual patch of this type risks blocking legitimate traffic, disrupting the normal execution of the application, and adding extra workload to security teams who must filter out the false alarms. With this type of virtual patching, the level of security achieved is only as effective as the patch's signature. Patching should not be dependent on the skills of engineers and their ability to write virtual patch signatures.

Additionally, patches of this type are very fragile to change. In the case of web applications, any time there is a change to the vulnerable URL or HTTP parameters, then the virtual patch is invalidated and needs to bere-configured.

More importantly, these approaches safeguard specific inputs but leave the vulnerable components unprotected. If there are more entry points that lead to the same vulnerable component, then the virtual patch will fail to protect.

One could claim that it is an overstatement to say that the above approaches provide “patching” capabilities since the code remains vulnerable even after the virtual patch is applied. This is why some refer to these approaches as “vulnerability shielding” instead of patching.

The third type is the natural evolution of virtual patching and leverages the Just-in-Time compilers of contemporary runtime platforms (such as the Java Virtual Machine and the Common Language Runtime). Being inside the application and being able to control every instruction before it gets executed allows true virtual patching to be achieved. It is now feasible to deliver a virtual patch that is functionally equivalent to the vendor’s physical patch without modifying the application’s source code or its binary files while ensuring the component is properly patched and is no longer vulnerable.

Virtual patching in the runtime compilation pipeline is the type of virtual patching that the community has aspired to achieve since its inception. WAF/IDS engineers envisioned the attraction of virtual patching, but the lack of control of the runtime platform and the architectural limitations that place such solutions outside of the application have forced virtual patching to be more or less an elaborate input/output validation solution.

This does not mean that these types of virtual patching have no use. On the contrary, there are cases where applying an input validation virtual patch makes sense. Consider the cases of legacy and end-of-life systems or when the vendor does not release a security fix. Recently, Sonatype found that 84% of open-source projects do not fix known security defects. For such cases, a compensating control based on input validation type virtual patching may be the only way to protect such systems.

Virtual patching has advanced to the point it can largely be an automated process that requires little manual intervention and is just as effective and perhaps more robust than physical patches. With compliance regimens requiring more rigid patch management processes, the time has come for security teams to adopt a virtual patching strategy into their vulnerability and patch management programs.

Virtual patching comes in various ways each having its own advantages. When teams asses their patching needs, they must be sure to have a clear goal in mind about why they are patching and what they are trying to achieve. Does a shield against known signatures that does not fix the underlying software flaw suffice, or is a virtual patch that is functionally equivalent to a physical patch and remediates the flaw in the software component required?

This article is featured in the new DZone Guide to Security: Defending Your Code. Get your free copy for more insightful articles, industry statistics, and more!