Security Compliance for your Virtual Server
While virtual servers remove many constraints caused by tying operating systems and applications to hardware, they are still subject to the same risks and issues associated with their physical equivalents. A server is a server, with processing, memory and I/O, after all. But just because it shares the same facets as a tin-and-silicon machine, does this mean it should be secured in the same way? To answer this, it’s worth thinking about the architecture that results from server virtualization. You will still have physical servers (it’s a bit hard to do without them) each of which will be running several virtual servers. As such and from a security perspective, you’ve actually added a layer – which can be both a benefit and a constraint.
Advantages & Disadvantages
First, the advantages. In principle, a virtualized environment can benefit from all the security measures already in place in the physical world. If physical servers are in a locked data centre (they should be), using a restricted subnetwork and running security event monitoring, for example, then so will the virtual servers. All well and good so far: in addition and for the record, each server will need to be “security hardened” at an appropriate level for whatever workloads it is running. This is no different to traditional security best practice of course, so it’s business as usual once again. What about the downsides? In general, these are more “gotchas” based on the virtualized server architecture, than anything intrinsic about virtualization software. Some have pointed out that the hypervisor layer could be a security risk: yes indeed, like any other executable software package, so it could. The advice is, don’t just trust the hypervisor but keep an eye for announcements about security holes and patches. This leads to a second class of risks. The very nature of virtualized environments is that multiple virtual machines are running on the same server: if the server is compromised, then so might be the VM’s. As well as issues caused by a dodgy hypervisor, the server may be more open to a denial of service attack caused by any number of methods such as deliberate overloading of the network it connects to; or using a rogue VM to max out the processor and fill the RAM; or simply a disgruntled sysadmin switching off the power. Having all the eggs in one, physical basket focuses the mind on how virtual servers are managed. Most virtualization environments are run from a centralised management console, which can be used to power on (and off), configure and move virtual machines at will. The password to the virtual machine management console is tantamount to the key to the virtual city – lose it and you might as well open the gates wide open. Speaking of moving VM’s, this is one place where the virtual world extends way beyond the confines of the physical world. Yes, it is possible to create a virtual machine and run it on a server in a data centre, on a desktop, in the cloud… the possibilities are legion, but so are the risks. Downloading an already-infected virtual machine from the Web; stealing a VM by taking a clone copy, without the knowledge of the operator; running a machine in an insecure environment; all are ways that the flexibility of virtualization can come back to bite.
How to Approach Virtualization Security
So, what to do? The answer lies in keeping control. Virtualization brings operational flexibility and increased efficiency but it also brings complexity, and complexity breeds risk. Adopting virtualization without due consideration for management processes and tools is a road to virtual machine sprawl and considerably increased risks such as those highlighted here. Adopt virtualization and enjoy the benefits by all means, but ignore the dangers of uncontrolled use at your peril. What do you think? How do you stay compliant in the face of all the challenges associated with virtualization security? Leave us a comment and let us know, or click here if you’d like to know more.