Manage Learn to apply best practices and optimize your operations.

Use virtual patching to ease short-staffed patch management procedures

Virtual patching can serve as a quick way to deal with patch management procedures when short staffed. But how effective is virtual patching? Michael Cobb explains the pros and cons of virtual patching in this technical tip.

Although most large software vendors have worked hard to improve the release and distribution of their patches, patching still creates a lot of work for IT administrators.

Many organizations struggle to patch their systems at the rate that new vulnerabilities are discovered, and it can be a stressful time waiting for a maintenance window to install a critical security patch. On top of that, if IT staff and time are in short supply, it becomes nearly impossible to review, test and install official patch updates without leaving systems at risk in the intervening period.

The solution to this patch management dilemma may lie in what's known as virtual patching. The aim of virtual patching is to alter or eliminate the vulnerability by controlling either the inputs into or outputs from the affected application. Virtual patches can be applied using various methods, which we'll cover in a moment.

Unlike traditional patch management procedures, virtual patching allows an application to be patched without touching it or its associated libraries and the operating system it's running on. Additionally, virtual patching is sometimes the only way to support older versions of an application that are no longer supported by the vendor.

More on patch management procedures

What patch management metrics does Project Quant use?

When should a virtual patch be used?

One virtual patching approach is to change the application's runtime code. This is really useful in those cases when you don't know anything about how the actual attack works, usually because vendors are reluctant to discuss the specifics of the attack. In this case, if the attack involves extracting credit card details, you can create an output patch that drops any connection transmitting card data to an unknown IP address. This type of virtual patch both prevents the attack from succeeding, while simultaneously implementing rules that define trusted behavior, thereby adding an extra layer of security to your application.

However, altering an application's code can introduce new risks like programming errors that lead to more security flaws or application instability; it requires very skilled coders to mitigate those risks successfully. A more common technique is to place some type of proxy in front of the application to control its inputs and outputs to prevent or eliminate the vulnerable actions. This can be as straightforward as matching inputs against a new firewall or proxy rule to detect attempted exploits and terminating the suspicious session.

For IT departments short on manpower, the easiest virtual patching method is to use intrusion prevention systems (IPS) and vulnerability management products to prevent known issues from being exploited. Synching your IPS with your vulnerability management system can update the configuration of IPS filters by mapping them to the vulnerability database and implementing appropriate changes to protect identified vulnerabilities.

Vendors Critical Watch and TippingPoint have created an integrated vulnerability management and IPS integration package that does just that. Blocking potentially malicious network traffic from reaching vulnerable applications provides a network-based or virtual patch which doesn't require downtime or extensive application testing. The integration package is a great time-saver, but if such a product is beyond your budget, you can of course manually sync your existing IPS and vulnerability management systems, as discussed above.

But how can it be determined if a virtual patch is working? Ideally it requires getting a hold of the exploit code to test how the virtual patch handles a simulated attack. If this isn't possible, you will need to understand in some detail how the attack works. This will require researching vendor and AV reports for insight into the workings of the attack. A filter or proxy should trigger an alert if it detects a potential attack, such as a probe for the existence of a vulnerable application. Test that your application still works when the virtual patch is in place, and document the changes you've made, along with what the patch fixes or does not fix.

Virtual patching is not a "set it and forget it" solution. Any sort of change to the topology of the network, or even minor configuration changes, can render a virtual patch ineffective, exposing an application all over again. It's important to follow up with a plan to fix the root problem, including deploying the vendor's patch whenever possible and practical. Ideally, virtual patching gives short-staffed IT teams more time to follow through with proper patch management procedures, including assessment and deployment.

There is no doubt that virtual patching is an extremely valuable technique that can be used to reduce the risk created by intervals between vendor patches or for companies lacking the manpower required to test and roll out patches on a regular basis. In no way should virtual patching replace standard patch management procedures, but if you keep up to date with vendor and public vulnerability disclosures, it can provide a quick fix and close the window of opportunity for attackers looking to exploit systems waiting on an official patch.

This was last published in May 2010

Dig Deeper on Network intrusion detection and prevention (IDS-IPS)

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.