In many cases when you start to discuss security of virtualization, you soon drop into a discussion of virtual networking, and management network security. In other words you are laying out the traditional security zones that exist within the networking world. Network security, virtual and physical, is extremely important however there is more to virtualization security than just your network. Here are some new ways to consider virtualization security.
Now our Virtualization host is a container for other security zones — There are multiple security zones, but these security zones exist within the same physical box that in more traditional senses generally only exists within a single security zone. The multiple security zones within the virtualization host are hypervisor, virtual machine hardware, storage, management, production, DMZ, etc. (the list is endless). While most of these reflect more traditional definitions there are a few that do not.
- Hypervisor — The hypervisor is its own security zone. It is the controlling agent for everything within the virtualization host and can touch and affect ALL aspects of the virtual machines running within the virtualizaiton host
- Virtual Hardware — In the traditional security model, the physical hardware had few if any controls that applied to security outside of password protecting the BIOS or disallowing USB devices. With virtualization however each Virtual Machine has a rich set of options that control how the virtual hardware works from picking specific hardware types (networking and storage), passing through SCSI and PCI cards to the virtual machine, and how the VM will talk out-of-band to the hypervisor (on VMware’s environemnt this is the VMware Backdoor).
One of the major virtualization security concerns is ‘escaping the VM’ or being able to reach the hypervisor from within the VM. This will be even more of a concern as more APIs are created for the virtualization platforms. As more APIs are created, so are compensating controls to disable the functionality within a VM.
VMware has 3 current APIs that could be used to possibly cross security zones.
- VIX — used to run items within a VM from a hypervisor via the vmrun facility
- VMCI — Out-of-Band communication band between VMs on the same virtualization host. A faster way to share data.
- VMsafe — Slow Path VMsafe moves data from the hypervisor into a VM for perusal
Any and all of these can cross any security zones within a virtualization host and the network need not be involved.
We also mention management as a security zone, and this is often a TRUST zone as you are trusting that the administrators will do what they can to do things properly. However, when we talk about management security, we are talking about 3 things.
- Authentication — Have you authenticated your account properly using the appropriate, standard mechanisms available.
- Authorization — Are you authorized to do this. Is this your Role, and have you been granted the permissions for that Role.
- Networking — Are you using secure mechanisms to talk to the management appliance that most likely lives in a different security zone (SSL, VPN, etc.).
Authentication and Authorization are some of the most interesting aspects of management because there are so many ways to manage a virtualization host that authentication and authorization could become split-brained. Where your role could change on the management tool in use. In addition, the account you use could have different roles based on the location of the login.
In short there is much more to virtualization security than just networking. Yes, networking plays a critical part, but it is just as important to understand the APIs and basic concepts of your hypervisor and virtual machines and how your management tools work. If you can address Authentication, Authorization, and Virtual Hardware and hypervisor security as well as your networking security you are well on the way to a comprehensive policy. If you do not and just depend on network security to do the job then your virtual environment is at risk.