icetray - Fotolia


Virtual patching trades convenience for increased risk

Performance might not suffer too much when using a virtual patch, but there are reliability, quality and support concerns associated with this technology.

Inline or virtual patching is unique to virtualization technology, as it simply wouldn't be possible from a cost or performance perspective to implement with physical hardware, But just because you can use virtual patching doesn't necessarily mean you should.

A traditional patch corrects a flaw in the software -- by altering the software's code -- however, a virtual patch is a dedicated piece of software that's similar to a firewall, with rules or features designed to correct a software issue or exploit without altering the software's code. This inline patching is applied to the host and does not add new features, but it is possible to remove features.

Performance implications

Let's first take a look at virtual patching from a performance perspective. Trying to put what could be called a proxy server in front of another server in a physical environment has network traffic and hardware performance implications, but you can avoid that contention in a virtual environment. You can assign the virtual patch to the VMs you're protecting, ensuring limited network congestion or even no network congestion if you use a host-based patch. This helps maintain a high rate of performance for guests but does require additional configuration management, as some virtual infrastructure resources have to be used for virtual patching features or appliances. It's also worth noting that, at some point, too many inline patches could create an unstable environment.

Quality and reliability concerns

In general, virtual patching corrects an exploit or vulnerability in an OS without going through the manufacturer. Let's put aside the support aspect for a moment and talk about quality and reliability. This type of inline patching isn't correcting the issue; it's preventing it from occurring further up in the stack. This means that, if the virtual patch crashes, fails or is breached in any way, you not only risk exposing your VM but also your hosts and ultimately your entire virtual infrastructure. Now, as far as quality is concerned, you're depending on a third party to prevent an issue from occurring, which could mean more overhead, licensing and complexity.

Benefits of virtual patching

One key benefit of virtual patching that simply can't be overlooked is speed. Because you aren't touching the base OS, much of the testing and risk normally associated with patching is removed and put on the hosts or inline appliance instead. The end customer doesn't interact with this part of the virtual infrastructure, so you're typically able to upgrade it without interruptions. As such, implementing a virtual patch is something you're willing to do on a Friday before a holiday weekend, and that's almost magical in IT. While that's a significant reason to use a virtual patch, it's important to take your OS vendor into account before implementing it.

Most likely, once you go down this path, you relinquish any vendor support for your base product. But if your product is already end of life, it doesn't really matter. To be clear, virtual patching and mitigation can allow your data center to avoid very nasty upgrade cycles when critical issues occur by using your virtual infrastructure. This technology can also extend the life of OSes, but it's important to realize that virtual patching shouldn't be looked at as a permanent solution. It's designed to give you additional breathing room to schedule and do upgrades on your time frame, but it has its limits and risks.

Next Steps

Adapt to Microsoft patching changes

Understand patch management software

Navigate hot patching restrictions

Dig Deeper on Virtualization security and patch management