Virtual Patching: An Immediate Response To Zero-Day Exploits

Permanent patches sometimes take months to deploy—leaving digital assets open to attack. That's where virtual patching comes into play.

When an application vulnerability is identified, the ultimate goal should always be to fix the code with a permanent patch. But this takes time. If it’s a commercial application, you most likely will not be able to modify the source code yourself. You will have to wait until the vendor releases an official patch—and that may take months. In the meantime, the application is at risk. 

Enter the Virtual Patch!

Sometimes called a web application firewall, virtual patches are primarily used to protect web applications. They provide a quick way to divert an attack from a known vulnerability by utilizing a security policy enforcement layer that prevents exploitation. This is a great counter to zero-day exploits in which updates for an application have not yet been deployed. The patch analyzes transactions and intercepts attacks in transit so malicious traffic cannot reach a targeted application.

The Critical Role of Virtual Patches

While the actual source code of the application is not modified, applying virtual patches is key given the numerous situations when it’s impossible to immediately edit the source code of a web application and apply a permanent patch. Virtual patches also scale easily—they can be installed in a few locations rather than patching all hosts.

Your business also receives several other key benefits:

• Provides protection for mission-critical systems that can’t be taken offline.
• Eliminates time and money spent performing emergency patching.
• Reduces the risk until vendor-supplied patches are released, tested and applied.
• Decreases the likelihood of introducing conflicts as libraries and support code files are not changed.
• Enables normal patching cycles to be maintained—rather than forcing them to be rushed.

Utilizing virtual patches is critical because even if an official patch is available, or a source code fix could be applied to a custom-coded application, the normal patching processes is usually time-consuming due to the extensive regression testing that’s required after code changes. It is not uncommon for these testing phases to be measured in months.

Listen: NotPetya, Is It For The Money Or The Infrastructure?

Tips for Creating Virtual Patches

Virtual patching, like most other security processes, should follow a consistent, repeatable process. The workflow should mimic general industry-accepted practices for IT incident response—consisting of preparation, identification, analysis, creation, implementation, testing, and recovery.

Ideally, you should establish the process proactively—and not under the duress a newly-discovered vulnerability. A great resource to help establish a virtual patch methodology is Virtual Patching Best Practices, published by The Open Web Application Security Project.

Each step is critical, but one in particular we recommend to focus on is the creation phase. When creating a virtual patch be sure to adhere to the two main tenants of any IT security tool: do not block legitimate traffic, and do not miss any attacks.

When a vulnerability is identified, begin the creation phase by searching for all the necessary conditions for an attack to succeed by obtaining technical data that triggers the vulnerability. Variation changes should be made one-at-a-time. This includes strings, length values, character encoding, and white space.

After identifying the complete set of variables that are important to the attack’s success, arrive at a set of criteria that must be collectively satisfied for any attack to succeed. If there are multiple distinct attack vectors, perform the analysis on each one separately.

Next, describe the virtual patching logic that has zero false negatives. That is, an attack simply cannot succeed unless the associated web application attack traffic has exactly the characteristics that the virtual patch is looking for. Given a zero false negative virtual patch, evaluate the accuracy of the patch in terms of the false positives.

At this stage, identify at least one characteristic that would never occur in normal web traffic. If a characteristic exists that is both anomalous compared to normal traffic and critical to the attack’s success, then the zero false negative virtual patch is also a zero false positive signature.

Positive or Negative Security Model?

A virtual patch may employ either a negative or positive security model. Which one you decide to use depends on the situation:

A Negative Security Model

A negative security model can be built based on a set of rules that detect specific known attacks rather than allowing only valid traffic. An example is limiting the characters allowed in an input field. Since the character set is a closed set, providing a white list of permitted characters is actually similar to providing a black list of forbidden characters including the characters complementing the first group.

A Positive Security Model

A positive security model virtual patch is a comprehensive security mechanism that provides an independent input validation envelope to an application. The model specifies the characteristics of valid input (such as character set or length) and denies anything that does not conform. By defining rules for every parameter in every page in the application, the application is protected by an additional security envelop independent from its code.

Negative Security Model Vs. Positive Security Model

Negative security rules can usually be implemented more quickly, however evasions are more likely. Positive security rules provide better protection, but this approach is often a manual process and thus not scalable and difficult to maintain for large or dynamic sites. While manual positive security rules for an entire site may not be feasible, a positive security model can be selectively employed when a vulnerability alert identifies a specific location with a problem.

Protecting Apps Without Waiting For Updates

Virtual patching essentially gives you the ability to protect your applications without having to patch them. This is particularly helpful when applying a permanent patch is not immediately available. The virtual patching approach is faster, does not require programming in the application language, and leaves you in control of the patch cycle without sacrificing security.

And all this can happen without having to take your production systems down. That means the business can literally stay up-and-running!