Real approaches to virtual security
Published: 09 Jun 2008 15:47 BST
...either in the system itself, or in a virtual machine which then acts as a security enforcer for the hypervisor.
Some experts even claim security software embedded in the hypervisor could be more efficient than traditional antivirus installed on separate physical machines. However, there is still the necessity for the hypervisor to be as compact as possible for information assurance purposes, as the bigger the system is, the more code there is to exploit.
It's also possible to embed security in virtual systems by using platform integration mechanisms, which work by scanning systems on start-up to detect changes. When booting up, the systems hardware itself checks for any systems changes, which would detect whether any malicious code had been installed. This isn't used very often, as systems can legitimately change too: for example, if you patch them. However, Mayers argues that platform integration can work for hypervisors as the code doesn't change very often.
"With platform integration, you can tell if you get a hyperjacking attack," says Mayers. If you do suffer such an attack, you can tell when the system reboots. To overcome the issue for systems that are not rebooted very often, Mayers said security should run in a separate virtual machine, with the caution that virtual machines cannot provide physical enforcement.
The problem of how to provide physical as well as virtual enforcement can be partially overcome by keeping networks separate. Experts agree that different types of network, such as LAN, iSCSI and VLAN, should be kept apart.
Virtual local area networks (VLANs) use virtual switches to route data, and these virtual switches are also potentially open to attack, according to analyst Buss. For example, one server with a hypervisor running five virtual operating systems, will communicate over a virtual network interface, and connect to a virtual switch acting as an ethernet port. A firewall or intrusion prevention system between the hypervisor and the virtual switch protect the applications in the virtual environment from being compromised.
Avoid single points of failure
After setting up a virtualised system, a disaster-recovery test is a good way to check that the security implementation hasn't introduced single points of failure into systems, advises Mayers. Hypervisors should be installed in more than one place, so if one part of the system goes down the whole edifice doesn't topple.
Read this
An open approach to virtualisation management
Nick Carr, product director at Red Hat, discusses the open-source alternatives to the virtualisation- management tools touted by Microsoft and others
To test for single points of failure in virtualised systems, Mayers recommends live disaster-recovery tests. "A test will discern if you have any single points of failure. Look at the impact of concentration: how many virtual machines you have on a single physical machine. If that fails, what load does that place on other machines?"
Static security policies — basically pre-defined rules of how to secure a fixed network — might be de rigueur for networks composed of physical devices with fixed software, but they are practically no use when it comes to virtualised systems. "When you have a static policy, you need to think that this machine will communicate with one over there," says Mayers. "If a physical system fails you need to think where a virtual can be moved, and still be secure. If this virtual machine moves, does this break the security policy?"
Beware 'vmsprawl'
And the idea that too much of good thing can be bad for you also holds true for virtualisation. Avoiding 'vmsprawl' — basically deploying new virtual machines unchecked — is a must according to experts. "They'll [virtual machines] proliferate if you're not careful," says Mayers. "You can control vmsprawl proactively, by controlling who produces virtual machines, or you can use discovery to detect virtual machines."
Organisations with tighter security needs often control who can create virtual machines, whereas businesses that need more flexibility monitor their virtual network to discover when virtual machines have been created. However, companies using the latter method have to decide about the risk to their business of rogue virtual machines that have been taken over by malicious controllers.
"What do you do about rogue virtual machines? You need to be able to take those down quickly. IDS [intrusion detection system] relies on being able to see all of the communications in a network — you can still have rogue machines communicating outside the network," says Mayers.
Virtualisation has had a disruptive effect on the whole area of server and network management, and is widely seen as a technology that rewards a brave and bold approach. However, when it comes to securing the systems, experts seem to agree that a measured and step-by-step approach is best and that virtualised systems face as many security issues as their physical forebears. Get the implementation of security for virtualised systems right first time, and you'll save yourself headaches further down the line.
- The server OS: Present and future trends
- Making sense of multicore pricing
- Living with Microsoft Windows Server 2008
- Not Linux? No point, other UNIXes
- What are the top five - even top three - most desired server OS features?
- Trying to map out what the server of the future will look like
- Blog: Microsoft in 'quite good' shocker..
- CPU roadmap: server processors
- The realities of server management: Part 1
- The realities of server management: Part 2
- The realities of server management: Part 3
- Microsoft finally launches Hyper-V





















