At one time, it was only feasible to run a virtual machine (VM) on mainframe class hardware. However, increased performance has made virtual computing a reality on standard servers and even desktops. In addition to software support for virtual computing, both Intel and AMD have begun adding special instructions on to their processors to help support VMs. Advancements such as these can only lead to more opportunities for the utilization of virtual computing.

 

Virtualization may be something as simple as running a guest operating system on a personal computer’s host operating system, or as complex as maintaining a virtualized infrastructure with multiple production virtual machines acting as servers. In the non-mainframe world, virtual computing has been widely used for testing, support, and experimentation. It is steadily gaining more ground in the provision of production services, due to its unique advantages. Among these advantages are rapid deployment, highly configurable virtual networking, flexible resource allocation, and unique disaster recovery options.

 

As departments begin to use virtual computing in more critical deployments, the Information Security Office is being asked for guidance on the security of virtual computing on campus.

Treat a VM as you would any physical computing resource you own. This is the fundamental way to think about virtual computing. Ultimately, a virtual machine is logically identical to a physical server, and it should meet the same standards of security and reliability that are maintained on all other servers.

 

The host operating system and physical hardware should be considered as important as the most important virtual machine/guest operating system on it. If a guest operating system holds Category-I data (Cat-I), then the host operating system and physical hardware running that operating system should be maintained to Cat-I standards.

 

The other guest operating systems on shared physical hardware should be configured and managed to the standards of the most sensitive data on that hardware. If one guest operating system stores Cat-I data, then other guest operating systems should be configured to meet the Minimum Security Standards for Systems which host Cat-I data. Any additional methods capable of further isolating Cat-I data from Cat-II and –III data should also be used. Ideally, Cat-I virtual machines should be on separate physical hardware from Cat-II and Cat-III machines.

Network Topology and Filtering Considerations

 

Some host operating systems provide virtualized network resources. These may allow for specialized network topologies without the addition of physical networking hardware. These options can be used to provide a more secure environment for guest operating systems. For example, the guest operating system may only need limited network access. The virtualization software may be used to limit both inbound and outbound network connectivity to the guest perating system.

 

There are some potential drawbacks to using certain virtual network configurations. Hosts that misbehave on the network are frequently filtered by their IP address. If a set of virtual machines share an IP address, they may all be filtered if even just one of them behaves unacceptably.

 

Local technical support often traces a misbehaving host back to a physical network switch port, and will disable that port until the host is secured. On a physical server running multiple virtual machines, turning off the network port may take multiple VMs off of the network instead of just the single VM that was intended to be removed.

 

Of course, these situations are no different than those that exist when physical hardware is configured in a similar way. What does set them apart is that it is much easier to deploy these types of configurations in a virtualized environment. Make sure that your network and security administrators are aware of the virtual infrastructure and its general configuration, so that any incident response can be handled in a way that will minimize unintended consequences.

 

Potential Threats Specific to Virtual Computing

 

Malware already exists that can detect whether or not it is running on a virtual machine. When the malware detects a virtualized environment, it modifies its behavior accordingly. In some cases, it will deactivate itself. In others, the software attempts specific attacks to which the virtualized environment is uniquely susceptible. Thanks to the increasing use of virtual computing, vulnerability researchers and malware writers are dedicating more of their resources to this area.

 

Physical servers have obvious physical boundaries which separate them. Virtual machines are usually isolated from each other by the virtualization software on the host operating system. Unfortunately, software isn’t perfect, and the containment of the guest operating systems may be compromised by a bug in the virtualization software. In addition, it may be possible to compromise the host operating system. In both cases, compromise may give an attacker the ability to monitor traffic of multiple VMs that it hosts, or give the attacker the ability to access virtual machines running on that hardware. This sort of attack has not been successfully accomplished yet, but it is a very active area of research.

 

The virtualization software has a significant role in managing resource utilization and sharing among virtual machines. A VM that uses excessive resources may result in a denial of service for other VMs sharing physical resources with it. Virtualization software provides numerous controls for resource allocation and throttling. These should be used to ensure that performance and availability remains adequate.

 

Disaster Recovery Considerations

 

For disaster recovery purposes, it is important to remember that all virtual machines depending on a single piece of physical hardware will be affected if that hardware fails. For example, running two separate virtualized Web servers may provide redundancy in case one of the services fails. However, if they are both running on the same physical machine, they will both fail if the hardware fails. 

Guest operating systems may be totally oblivious to the true physical hardware they are running on. The virtual software presents the guest operating system with a set of virtual hardware that mimics actual physical hardware. This abstraction between the guest operating system and the physical hardware can allow a virtual machine to be moved to radically different hardware with little or no reconfiguration of the guest operating system. In the event of hardware failures or the need for increased or decreased physical resources, the move could be much easier and less time-consuming than it might be in a non-virtualized environment.

Parallels

 

VMWare

 

Microsoft VirtualPC and Virtual Server - missing

 

Xen