Antimalware and Virtual Machines: square peg, round hole problems

As endpoints are virtualized, it is tempting to assume that everything within the endpoint is virtualized, and the job is done. Of course, performing a physical-to-virtual migration is the first step in an ongoing process of optimizing applications, the underlying infrastructure, and of course, security.

AV Storms and all the nastiness

If you have virtualized most of your servers, and are starting to optimize by raising consolidation ratios, you will have noticed that traditional antivirus software creates some nasty headaches in virtualized environments. If you have virtualized desktops, you’ll have encountered “AV storms” from the start of the project.

The “AV storm” problem is pretty straightforward. Traditional antivirus is built to work on isolated systems that run on dedicated hardware. In that context, each operating system instance has more-or-less direct access to hardware that no other instance has access to; each system is an island. When those endpoints are virtualized, they share hardware, and access to it is negotiated by the hypervisor.

Operating system instances tend to have a lot in common; same files, same memory footprints, and so on. Hypervisors understand that and deduplicate as much of each instance footprint as possible. Essentially, one “shared” copy of memory pages is kept if it is the same across every instance running on that hypervisor.

Virtualization_Virtual_Machines

Getting around the duplication problem

The problem lies in the applications, and traditional antivirus is really just another application. While hypervisors are great at deduplicating many of the elements of VMs, antivirus software doesn’t play nice. Instead of keeping a central copy of everything, traditional antivirus still operates as though each VM is on an isolated hardware island. Scanning results, databases of signatures, heuristics, and whatever else, are maintained within each VM. If full-system scans are scheduled, they kick-off simultaneously. That’s not a problem in traditional environments, but when many VMs share hardware, the result is a copy of antivirus software in each VM fighting for host resources, thereby saturating the resources.

To centralize and deduplicate information and resources, traditional antivirus software has to be re-architected to work in virtualized environments. A true virtualization-friendly antimalware solution will therefore use dedicated virtual appliances to house much of the antimalware functionality. The antimalware resources and information are then shared across many VMs. The result is a much decreased performance impact across the environment, freeing-up resources so that more VMs can be run on the hardware, rather than more antivirus instances.

In some cases, vendors have built virtualization-friendly antimalware from the ground-up. In other cases (or within the same solution), vendors have used functionality created by VMware (specifically, vShield Endpoint) to make their solutions virtualization-friendly. Other vendors haven’t done either, and instead rely on workaround-as-a-feature functionality to temporarily appease angry customers.

While it’s tempting to declare one approach as “the best”, I recognize that the best approach for each customer is, simply, the approach that is best suited for that customer’s environment.

So, rather than making such a bold declaration, I’ve created a Solution Paper that explains some of the differences between two approaches that Bitdefender has created in our Security for Virtualized Environments solution.