Remember the first time you drove a car on your own, and you’d get a kick from the sensation of sheer speed? Unfortunately, you also have to learn the mundane stuff like how to turn, stop and reverse safely. The same is true in organizations that deploy virtualization.

Compared with deploying physical servers and apps, virtualization is like driving a new sports car. It’s so easy to move quickly. But just like when you were learning to drive, you’ve got to find out how to do it safely. It’s easy to be seduced by the performance and ease of virtual machines (VMs), and overlook the more mundane aspects – like security.

Analyst Gartner predicted that in the coming year, 60% of VMs will be less secure than the equivalent physical servers. This makes VMs the target of choice for potential malware or hacking exploits. How do you go about narrowing the security gap between virtual and physical deployments, and what techniques will help mitigate the risks?


History lessons

The first step is to be realistic about the actual security risks to VMs. There’s a lot of theorising and discussion of potential risks, such as new types of malware that targets hypervisors, or other vulnerabilities. Certainly, malware attacks specifically targeting VMs will appear as usage continues to grow.

However, the more pressing and important issue is ensuring your virtual environment is designed and built as robustly as your physical network. Remember that we’ve all had to go through 15 years of painful experience in securing servers and data against constantly-evolving threats, and in developing robust network architectures to give the right security framework. It’s vital that this isn’t overlooked when deploying a virtualized environment. In fact, this hard-won security knowledge stands you in very good stead when it comes to securing the virtual world.

VM hygiene

This means going back to basics, and looking at which applications are being moved from physical servers to VMs – and to audit what VMs may already be in use in the organization. It’s easy to get carried away with the performance benefits, and overlook the fact that the applications running on the VMs need to be segregated – for example, a public e-commerce application (that may have sat in the organization's demilitarized zone) and an internal CRM system. You wouldn’t want these apps to have a physical link between their servers without firewalling, so the same applies with VMs running on a single server. They need segregating too, to maintain security.