Back to Basics: Virtualization as a Security Enabler (part 2)

In my last post, I explored the idea of improving information security with virtualization technology, namely in the areas of inventory and configuration management. These are likely the most visible and applicable places for “crossover” improvement, affecting both security and IT operations.

However, there are many other ways that virtualization can benefit security efforts today, some more practical than others. The first is in vulnerability management overall, which usually includes patching, configuration management, and vulnerability scanning. I briefly touched on the idea of virtual desktop imaging and configuration control in the last post, with the idea that we could define a template, keep it updated, and then spawn systems from the template. There’s more to vulnerability management, however.

Virtualization gives us the ability to control system state much more readily. We can perform patch testing rapidly, applying patches to numerous image builds and then rolling-back as needed, or updating the image once tested. For organizations trying desperately to keep up with the monthly deluge of software patches, this is a real lifesaver.

Another aspect of vulnerability management that is greatly facilitated by virtualization is the ability to compare existing systems against a virtual image on a regular basis. While this is not always natively available in virtualization and cloud solutions, many operations and security teams have created scripted approaches to comparing production systems against virtual images and templates. Doing so gives you a much better idea of “shift and drift” in the environment, or how far off you are from a baseline configuration standard.

Virtualization as a Security Enabler

While virtualization doesn't necessarily help with vulnerability scanning, per se, there may be efficiencies to using a virtual appliance model for scanning tools, getting them closer to the systems being scanned and potentially minimizing performance impacts often felt from scans. This is really an evolution of security tools than a true virtualization-specific benefit.

Another area that virtualization can significantly enable security research is in malware reverse engineering and analysis. Malware reverse engineers need an isolated environment in which to execute malware, analyze effects, and observe behavior, potentially for some length of time. Virtualization technologies are perfect for this, as entire virtual networks can be created that are isolated from the rest of the normal production environment.

Attackers and malware authors have become more sophisticated at detecting the presence of virtualization technology, but given the prevalence of virtual systems versus physical ones, most malware is more likely to find itself in a virtual system anyway. Malware analysts do need to be cognizant of virtualization detection routines in malware they’re analyzing, as the effects of the malware may be somewhat different, and most thorough malware reverse engineering teams will want to account for all possible use-cases when evaluating samples.

Forensic analysis of malware also involves the memory image, which is easily available in a VM using traditional forensic tools. What’s also available is the .vmem file, which is an image of running memory created by VMware Workstation or ESX/ESXi when a host is suspended. Comparison of memory before and after introduction of malware is an important step in analyzing just what it does, and the sequence of events that got it there. Changes to the file system are also analyzed.

Honeypots are machines created to entice attackers, allowing security analysts to observe attacker behavior and potentially capture malicious code. Generally, honeypots are put on a network without the protection of a firewall. Their operating systems or applications may be missing critical patches, or are of an older vintage

As research has matured, a honeypot is often a dedicated Linux or Windows machine, written specifically to emulate an older machine, appearing vulnerable but in fact hardened. No matter the OS and platform the honeypot is written on, virtualization gives us a great environment to host it. Multiple honeypots can be deployed on a single hardware platform, and presented to different networks as required. In addition, the out-of-band performance measurement available on virtual platforms allows researchers to measure key metrics such as CPU and network utilization without the knowledge of the attacker. Finally, if an attacker gains console access, the console is also available to the owner of the honeypot, so that not only can we monitor attacking activity from logs and specific honeypot functions, we can also actually watch them stumble around in their isolated cell.

Just as in malware analysis, if a VM with a real operating system is offered up as a honeypot, once it is compromised the entire VM can be taken offline for analysis, front to back, memory, and file system. While this is done, a fresh VM can be spun up, just as vulnerable and unsullied as the day it was built, ready for the next attacker!

Over the years, there have also been interesting use-cases for virtualization that take host-based security to another level - not only optimized anti-malware, which I’ve already had some discussions on - but even full encapsulation of the OS and/or applications to create isolated “containers” that policy can be assigned to.

A great example of a project that implements this concept is Qubes, which is maintained by Joanna Rutkowska and her team at Invisible Things Labs. Qubes uses a modified Xen kernel to “wrap” the OS and apps running within it in a virtual layer that can be isolated and controlled at a deep and granular level.

More solutions that take advantage of virtualization will certainly emerge, and we’re likely to see virtualization playing a more and more critical role in securing everything from endpoints to networks and datacenter infrastructure in the future.