Over the past few years, virtualisation has become a viable option for both large and small organisations. By allowing a single physical computer to act as two or more independent computers, each with its own view of the processor, memory and devices, virtualisation brings many business benefits, the most important generally being cost savings and flexibility.
It has become the technology of choice for shared services such as cloud computing, and system administrators are using it to create virtual test labs and provide centrally managed, locked-down images for their users’ machines. Organisations with large numbers of servers are using virtualisation to consolidate several physical servers onto one machine to make better use of their hardware and reduce rack space and energy costs.
Although attacks against hypervisors have been mainly hypothetical so far, once any popular technology reaches a sufficiently large user base, attacks against it tend to become more frequent and more sophisticated.
Many people are under the assumption that another benefit of virtualisation is it will improve the overall security of their infrastructure. It can certainly increase the availability of applications, as virtual machines can be migrated live to allow maintenance of the physical server without user or service disruption. Virtualisation can also simplify the backup and recovery of data and systems, making disaster recovery and contingency plans easier and cheaper.
But the primary role of virtualisation products is not to provide security. In fact, the hypervisor gives hackers an additional attack surface to exploit. Although attacks against hypervisors have been mainly hypothetical so far, once any popular technology reaches a sufficiently large user base, attacks against it tend to become more frequent and more sophisticated.
The security pros and cons of virtualisation will likely be argued for a long time to come, but one area where it can definitely cause problems is data separation. A virtualised single machine cannot be more secure than physically separate machines.
It is therefore essential to ensure applications handling one classification of data do not reside on the same physical machine as applications that handle data with a lower classification. Data with a higher classification obviously needs more robust protection and, by physically as well as virtually separating the data, it means a breach in one virtual machine doesn't lead to a cross-domain compromise. A low-level system virtualised with another system of more interest may be attacked as a possible route into the more interesting system, even though it has been assessed as being of little interest to hackers.
Each physical machine must be classified as high as the highest classification of any of its virtual machines. In fact, it may require a higher overall classification due to data aggregation, because the hypervisor has access to and control of all its virtual machines; thus, compromising the hypervisor provides access to all the virtual machines it runs.
Keeping virtualisation within a single security domain can also avoid a situation known as a cascade. The following is an example of what a cascade is and how it could occur.
Machine A runs two virtual machines. One of these machines, let’s call it VMA1, handles unclassified data and is connected to the Internet; the other, VMA2, handles confidential data. Machine B also runs two virtual machines; VMB1 handles confidential data and VMB2 handles top-secret data. Neither is connected to the Internet. The two virtual machines handling confidential data, VMA2 and VMB1, are both part of the same network. This creates a cascade from the Internet-connected VMA1 to VMB2 by way of the network between VMA2 and VMB1. This is the equivalent of virtualising VMA1 and VMB2 together on the same machine, a dangerous lack of data separation. For similar reasons, firewalls and other perimeter defences should not be virtualised with the systems and applications they're configured to protect.
Data transfers between virtual machines in different security domains should be handled in the same way as data transfers between physical machines in different security domains. Although it may be inconvenient, cut and paste between virtual machines should be disabled, as the shared buffer provides a potential route for one virtual machine to spy on all cut-and-paste operations in the other virtual machines. The existence of any permitted data path between security domains will reduce the effectiveness of the separation provided by virtualisation.
Another reason for not sharing security domains on a single physical host machine is that all the virtual machines will use the same peripherals, such as USB ports and DVD writers. Such shared peripherals not only provide a potential attack vector, but could easily create a bridge between virtual machines. Certainly, each guest operating system should have the automatic mounting, reading or playing of removable media disabled to prevent a compromised virtual machine writing malware to removable media so the next virtual machine to mount it automatically would be infected.
The access and control a hypervisor has over its virtual guests means the administrative interface should be treated as the most security-sensitive interface on the system. It should only be used for administration of the hypervisor, and should not be used for the normal administration of services provided by the virtual machines. For the same reason, it should only be remotely accessible through its own dedicated network.
As you can see, setting up a virtual environment requires careful thought, particularly when transferring existing systems. Security controls should be reviewed to ensure they are still valid and appropriate in the ‘virtual world,’ particularly where they protect connections between security domains. Virtualisation can provide businesses with huge benefits and savings, but, in the rush to deploy this technology, take the time to ensure you are implementing secure virtual machines, and keep data separation at the top of your list.
About the author:
Michael Cobb, CISSP-ISSAP, CLAS is a renowned security author with more than 15 years of experience in the IT industry. He is the founder and managing director of Cobweb Applications, a consultancy that provides data security services delivering ISO 27001 solutions. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications.Cobb serves as SearchSecurity.com’s contributing expert for application and platform security topics, and has been a featured guest instructor for several of SearchSecurity.com’s Security School lessons.