When considering the security of virtual environments, it helps to point out where in the virtual stack the discussion alludes to. There are two basic levels: the virtual platform itself and the virtual machines (VM) and associated applications deployed on such platforms. This is the first of two Quocirca blog posts intended to provide some high-level clarity regarding security in a virtual world, starting with the platform itself.
Virtual platforms can be privately owned or procured from cloud service providers. Those organizations that rely 100% on the use of public platforms or who outsource 100% of the management of their virtual and/or private cloud infrastructure need read little further through this first post. They have outsourced the responsibility for platform security to their provider and should refer to their service level agreement (SLA).
As Amazon Web Services (AWS) puts it: “AWS takes responsibly for securing its facilities, server infrastructure, network infrastructure and virtualization infrastructure, whilst customers choose their operating environment, how it should be configured and set up its own security groups and access control lists”.
The AWS statement points out the areas those deploying their own virtual platforms and private clouds need to address, to ensure base security. The risk is in three areas:
- Security of the virtualization infrastructure (the hypervisor)
- Security of the resources that the hypervisor allocates to VMs
- Virtualization management tools and the access rights they provide to the virtual infrastructure
The third point includes the use of cloud orchestration tools such as OpenStack and VMware’s vCloud Director, which can be used for managing private clouds or moving VMs between compatible private and public clouds (hybrid cloud).
Hypervisor Security
All hypervisors can, and do, contain errors in their software which lead to vulnerabilities which can be exploited by hackers. So, as with any software, there needs to be a rigorous patching regime for a given organization’s chosen hypervisor and the management tools that support it. That said, hypervisor vulnerabilities are of little use unless they open access either to the hypervisor’s management environment or resources it has access to. Most press reports reflect this, for example, picking on the most widely used hypervisor, VMware’s ESX:
A ThreatPost report from December 2013 reads: “VMware has patched a vulnerability in its ESX and ESXi hypervisors that could allow unauthorised local access to files.” The article goes on to report that the vulnerability has the effect of extending privilege, something hackers are always seeking.
Network World, meanwhile, ran an Oct 2013 report on an ESX vulnerability which said: “To exploit the vulnerability an attacker would have to intercept and modify management traffic. If successful, the hacker would compromise the hosted-VMDBs, which would lead to a denial of service for parts of the program.”
In both cases, VMware went on to issue a patch ensuring that fast-acting customers were protected before hackers had much time to act.
Security of Resources Allocated by Hypervisors
Both of the above examples underline the need to address the basic security of underlying resources: networking, storage, access controls and so on. For those that do everything in house, that includes physical access to the data center. The considerations are pretty much the same for non-virtual deployments with one big caveat. In the virtual world many of these resources are themselves software files that are easy to create, change and move, so compromise of a file server may provide access to more than just confidential data, it may allow the virtual environment itself to be manipulated.
Securing Use of Virtual Management Tools
As with all IT management there are two dangers here: the outsider finding their way in with privilege or the privileged insider who behaves carelessly or maliciously. A virtual administrator, however their privileges are obtained, can change the virtual environment as they see fit without needing physical access. That may include changing the configuration and/or security settings of virtual components and/or deploying unauthorized VMs for nefarious use.
When it comes to access control, the management of privilege, who has it, when they have it and auditing what they do with it is similar to that for physical environments. However, there are other considerations that apply in a virtual world over and above those in a physical one. Principally this is about being able to monitor hypervisor-level events; control and audit access to key files; the copying and movement of VMs; capturing hypervisor event streams; and feeding all this to security information and event management (SIEM) tools. There is also the need to define hypervisor-level security and take actions when it is breached, for example closing VMs or blocking traffic to and from VMs.
Specialist Vendors
There are certain specialist vendors that are focused purely on the security of virtual infrastructure layer. For example, Catbird, which specializes in reporting on and controlling security of VMware-related deployments, and GroundWork, which focuses on monitoring data flows in open source-based virtual environments. The suppliers of virtual platforms and tools provide support too, not least access to urgent patching advice.
When many mainstream IT security vendors talk about virtual security they refer to the security of deploying VMs and associated applications. Security at this level is of course important to address and has its own special considerations which will be covered in the second blog post. For those that have outsourced the virtual platform and/or the management of it, and are confident in their supplier, the focus will already be at this higher level.