Securing vSphere is not just a technical challenge
A conversation I sometimes get involved in with customers is, "How should we secure vSphere?" The environment doesn't have to be VMware-based of course, it could be Xen, Microsoft, Red Hat or any other, but the question remains.
From a technical perspective, the set of risks is reasonably well understood and by and large appropriate mitigations exist. For example each virtual machine, and the network connections between VMs need to be as secure as their physical equivalents. Meanwhile security holes could exist in the hypervisor layer, as with any other software package. Protections such as defence in depth, intrusion detection and prevention, patch management and so on remain much the same as in the traditional, physical world.
However, the net-new of a virtualised environment lies in how VMs are provisioned and managed. It is clearly much easier to deploy a virtual machine than a physical server: with the right tools and pre-defined configuration or machine to be cloned, this can take place in seconds as compared to weeks. But this strength is also its weakness, in security terms: simplicity in deployment can hide a number of complexities, and leave the door open to laxity.
For an old-world equivalent, I'm reminded of when an order for servers was delayed by several weeks. By the time they arrived - several pallets worth - the business user was champing at the bit, wanting to know when everything could be installed, up and running. It would have been very easy to cut corners, miss out some basic checks and forget to close a few back-doors in the urgency to deliver.
In the more dynamic, virtualised IT environment, expectations have also increased as stakeholders become less accepting of delivery delays. The customer is always right of course, and we all need to learn how to act more as service providers. However, certain delays are essential when it comes to doing the right thing and keeping risk levels down, both for IT and the business. The last thing any organisation wants is a free-for-all, particularly when it comes to creating virtual machines. We can so easily end up with many more virtual servers than we expect, due to how easy it is to create and provision them - in the worst case, causing virtualisation sprawl and its associated management and security headaches.
A relatively new tool in the toolbox for virtualisation managers is the ability to create policy-based templates, for example using vCenter Orchestrator. As with any automation technology there's going to be a trade-off: while time can be saved for frequently repeated provisioning tasks, it may appear too much of an overhead for one-off deployments. However, this may be before security is taken into account, particularly as automation can reduce some of the risks of manual deployment. Equally, clones and snapshots enable configurations to be tested, either before or even once a system is taken live.
The bottom line is, for vSphere as for any other platform, the tools are there. The question is how to keep focused on ensuring risks are minimised, even against the background of increasing agitation from the user base. Processes will help, but only if you can keep security as a central priority from the outset. In virtual environments as much as physical environments, security never works quite as well when it is retrofitted.