Threat Analysis: Layers upon layers

When we think of the threat to a virtual environment or the cloud, what do we think about? First it is important to understand how the cloud is layered on top of the virtual environment. Given a cloud stack, where are the entry points for SaaS, PaaS, IaaS, and Cloud management? At the recent Minneapolis VMUG, I attempted to relay that information to the attendees. Once we understood the layers we could then concentrate on the threat vectors to the cloud and virtual environment.
First we layout the virtual environment as the cloud is almost always built upon some form of virtualization. Not always but almost always. Many SaaS plays do not require virtualization to work, but they do augment and improve availability and reliability. Figure 1, The Virtual Environment, show the layers within a typical virtual environment.

As you can see the hypervisor is really a small part of this stack and only comprised of the virtual machine manager, kernel layer, and the driver or module layer. For all hypervisors, this comprises the kernel and user tools necessary to run virtual machines. But outside of the Hypervisor we have the hardware layer (blade enclosures, etc.), hardware that is used across all hypervisors such as physical switches and storage devices.
Above the hypervisor we have the Guest Operating System in which Applications are run. A Guest OS is necessary to run a VM, even for those items that contain Just Enough OS (JeOS) such as SpringSource and other platform tools and applications. In general, I find that the Guest OS in use is either Windows (the majority) or Linux (the minority) with a scattering of other Guest Operating Systems in use.
Outside of all these layers (and perhaps as a participating virtual appliance) is the management tools to manage the entire environment. The management tools include hypervisor management appliances: ESX Service Console, ESXi Management Appliance, Hyper-V Server Core Parent Partition, Xen Dom-0, as well as all devices that communicate to these components. In addition, you may find management servers such as SCVMM, XenConsole, and VMware vCenter. Lastly we include all those management tools necessary to run all aspects of the virtual environment such as storage, physical switches, blade management tools, etc. If it directly or indirectly touches the hypervisor, it is in scope for any threat analysis.
So where is the Cloud in all this? Figure 2, Cloud Layers, show the most common aspect of the cloud as presented to users of the cloud. That is a portal into which the tenant log’s in and deploys their applications, Guest Operating Systems, and controls their cloud environment. As such the Portal is largely an automation layer that interacts with the management layer.

Now that we know how the tenant communicates with a cloud, where are the entry points for each aspect of the cloud? Figure 3, Cloud Entry Points, outlines where each SaaS, PaaS, and IaaS enter the cloud. Each have their own unique entry points regardless of the Portal in use.

The SaaS entry point is the Application in use, usually load balanced across many virtual machines. PaaS enters the cloud at the operating system or perhaps an application like an integrated development environment such as Eclipse. Which means the PaaS more resembles a SaaS for development purposes. The PaaS entry point could also be the Desktop as a Service entry point. The most interesting entry point is that for IaaS, usually a private cloud construct, but its entry point is most likely either directly into the management layer or a separate portal that interacts directly with the management layer. All in all, when you use a cloud, each layer has a different set of entry points unrelated to how the tenant manages the cloud.
The threat vectors for the cloud are at each one of these layers, plus a few more. Figure 4, Threat Vectors, lists out the threats at each layer of the stack and yes, every layer of the stack has its own threat vectors. But what comprises these attacks?

Many of these attacks are possible due to misconfiguration within the underlying layers. For example, vSwitch attacks could be due to misconfigured vSwitches, VMs on the wrong vSwitch, and other such configuration issues. Many attacks above the hypervisor layers are known attacks against operating systems and applications such as SSL MiTM attacks, Windows or Linux OS attacks, well known daemon attacks, etc. The list is endless for these layers.
The new layer however is the portal or tenant management layer and it has nearly the same threats as those for the Saas, PaaS, and Application layers. The Hypervisor layer is the one that many people feel is the most at risk and its threats really come from the management layer. VM Escape is one risk that keeps on popping up as an issue. I will discuss this in another article as it deserves a full explanation. However, needless to say, not many of these escapes produce results within type 1 hypervisors, yet nearly all do within type 2 hypervisors.
The last piece of the threat analysis is a discussion about secure multi-tenancy. Figure 5, Secure Multi-Tenancy Threat Vectors, shows two more threat vectors of the cloud stack. These vectors are the Cloud Administrator who has access to Tenant Data and the Service Catalog used by the Tenant Portal and the Virtualization Administrator who has access to the Hypervisor and therefore access to virtual disks, memory, networking, and virtual CPUs.

Are all these threats real? Yes they are. Some claim that in order to perpetrate an attack you have to be so far into the system that the attack would fail before it begins. Do not count on this being the case, there are at least 6 external avenues into any cloud environment (Tenant Portal, SaaS, PaaS, IaaS, Physical, Social). Which an attacker will use is unknown. It is very important that every virtual and cloud environment impose the proper mitigation for all these attacks. This includes all aspects of security: availability, confidentiality, and integrity. Note that while clouds and virtual environments usually need to be compliant to some regulatory compliance. Compliance does not imply secure, secure does not imply compliant.
But as we discussed within several Virtualization Security Podcasts, it is extremely difficult to audit a cloud environment as a tenant, but you do have control over your organizations virtual environments. Audit those for issues, bring in the proper tools to protect your investment as discussed within the whitepaper: End-to-End Virtualization Security.
Understanding the threats to the cloud and virtual environment layers is the first step to solving the problems.