May 13, 2014
Three ways to protect virtual machines.
To protect or not to protect virtual machines – that was the question, asked by many. But the answer’s been the same all along: to protect.
The more crucial question is how to protect.
I’ve already written on these here cyber-pages a fair bit about the concept of agentless antivirus for VMware. But technologies don’t stand still; they keep moving forward. As virtualization develops and more and more organizations see its obvious advantages, more varied applications for its use appear, bringing greater and more specific demands in terms of protection.
Obviously there’s a dedicated security approach specifically for virtual desktops, another type of protection tailored for databases, and yet another for websites, and so on. Then there’s the fact that agentless antivirus is not the only way to go as regards protection, and also that VMware is not the only virtualization platform, even though it’s the most popular.
So what are the alternatives for virtualization security?
Agentless
So, just briefly, a bit of ‘previously, on… EK’s blog‘, since this has all been gone into in sufficient detail before (here)…
This approach entails having a dedicated virtual machine with the antivirus engine installed on it. This machine does the malware scanning on the rest of the virtual infrastructure by connecting to the rest of the virtual machines using native VMware vShield technology. vShield also interacts with the antivirus’s system management so it knows the settings and applied policies, when to turn protection on and off, how to optimize, and so on.
Security Virtual Appliance protecting all the other virtual machines
It sounds like a panacea, but the agentless concept has one principle deficiency nuance – limited antivirus functionality, i.e., the vShield interface permits only basic file scanning. That is, it foregoes all the following progressive protection technologies: Application Control, System Watcher, whitelisting, heuristics, device control and web control. In fact, it turns out the file scanning is also restricted: no quarantine for suspicious files, and access neither to memory nor computing processes.
But vShield wasn’t designed to be a complete interface permitting all protective functions. It can still be used (more about that later), but, there is another way, where all the different protective functions can be applied…
… Enter Light Agent
With this approach, a light (i.e., light on resources, small) agent (aptly called Light Agent:) is installed on every protected virtual machine. This agent replaces vShield and connects the virtual machine to the antivirus engine that resides on the Security Virtual Appliance.
We thereby remove the limitations of the VMware interface by adding the full arsenal of our defensive technologies. At the same time we keep the advantages of the agentless approach: a moderate appetite for resources, manageability, and stability against ‘storms’ (bottlenecks caused by simultaneous antivirus database updates or malware scanning across many machines).
Security Virtual Appliance protects all the other virtual machines (like above, with Agentless)
+
A small – ‘light’ – application on every virtual machine giving full access to all security technologies
Despite the name, Light Agent will still always be ‘heavier’ than an agentless solution, for it requires some memory on every virtual machine, processor power, and other resources. Nevertheless, with today’s computers’ mega-horsepower, Light Agent’s appetite is relatively meager. There’s also a bonus: some standard AV tasks using this approach can be performed quicker than Agentless. But the main thing is that, given the increase in the quality of protection when it has all bells and whistles on – Light Agent clearly becomes quite the contender.
But what happens if you want to protect data on non-Windows virtual machines and take advantage of the full range of protection technologies, including cryptography? That’s when…
… Traditional endpoint security is needed.
Sure, it will be problematic on the whole to fine tune such a setup given a sprawling virtual infrastructure, and maintenance and upkeep of such a solution will sure take up more human resources, but sometimes there are situations when such an approach is appropriate.
Each VM has its own dedicated endpoint protection installed
Ok, theory over; now for this tech in practice…
// At the same time I’ll modestly promote the new version of our product for virtual environments ).
Recently we released KSV 3.0. And we really do have something to be pleased overjoyed about.
First, in addition to VMware we now support Citrix XenServer and Microsoft Hyper-V.
Second, in addition to the agentless solution for VMware, now there’s also a solution with Light Agent for all three platforms!
Moreover, all products are managed and controlled from a single console, which is especially important for multi-hypervisor environments – so as not to create a messy hodge-podge of consoles.
So, what are the above three approaches each best suited to?
Well, generally speaking the reasoning that goes into the choice of protection goes like this:
For maximum, high-performance protection of a Windows guest OS a light agent is needed. On other operating systems (Linux, OS X) – a product for endpoints is better; however, alas, application is limited by considerations of productivity and the antivirus’s interaction with features of the virtual environment itself.
We are currently working on support of light agent approaches for other OS . In the meantime, if productivity is critical, data value and service value are not high, and access to data from outside the organization is limited – then an agentless solution is suitable.
We analyzed typical application tasks using virtualization and came up with this curious table:
| Role | External Access | Data* Value | Service** Value | Ext. conditions | Solution (Why certain solution is to be used) |
| Backend database servers | No | Low to Med | Medium to High | Regular backups | KSV | Agentless (short-living data, less attack vectors) |
| Frontend web servers | Yes | Low | High | Have trusting relationships with several backends | KSV | Light Agent (Exposed to dangers of public access, after successful attack exploitation of trust is possible) |
| Limited purpose VDI or virtualized application | No | Med to High | Med | Highly restricted, no apps installation, no use of removable storage | KSV | Agentless (predictable environment, less attack vectors) |
| Desktop replacement VDI | Yes | Medium | Medium | Personal removable storage in use, privileged users with installation rights | KSV | Light Agent (The need for higher security is bigger than the need for faster response. More attack vectors due to exposure to the Internet) |
| Intranet servers | Yes | Low to Med | Low to Medium | External access only from authorized users using hardware tokens | KSV | Agentless (Low business value of data, very limited exposure to the Internet ) |
| Client data processing | Yes | High | High | Need for stable, unchanging environment; Application Control with Default Deny recommended | KSV | Light Agent (Need for compliance makes additional protection layers an absolute necessity) |
| Web developers test environment | Yes | Low to Med | Med | Linux-based hypervisor and heterogeneous guest VMs | KESB for Linux, KESB for Windows (constantly renewed short-living data, variety of OSs) |
* – Data Value – Dependent on the amount of personal, financial, commercial or other critically important data
** – Service Value – Assessed as per the importance of uninterrupted service for the business
The above table is neither an exhaustive nor unambiguous presentation of how the three different approaches to virtualization security are suited to different environments. Organizations change, priorities change, IT configurations change, budgets change… The aim of the table is to convey the pattern of threats and the methodology for assessing tasks and priorities. More details are available here and here (PDF).
