Security Considerations for Cloud Computing (Part 1) – Virtualization Platform

If you would like to read the other parts in this article series please go to:

In a previous article, Microsoft Private Cloud: Overview of Hypervisor Security, we talked about hypervisor security in the Microsoft private cloud. But cloud computing – both public and private – is a complex topic, and in this series, we’re going to delve into some of those complexities. A cloud computing environment offers a multitude of advantages. However, you need to understand that while the hypervisor is an important component, cloud computing is more than just virtualization. Remember that a cloud has the following characteristics, according to NIST:

  • Self-service
  • Broad network access
  • Elasticity
  • Chargeback
  • Resource pooling

You might have noticed that virtualization is not one of the five core tenants. Of course, virtualization makes it a lot easier to attain the capabilities enabled by each of these tenants. And since we are likely to be using one or more virtualization platforms in our cloud datacenters (whether public or private or hybrid cloud), we’re going to need to consider some of the security issues related to virtualization in the cloud.

Before you can intelligently think about the security concerns related to virtualization and cloud computing, however, you have tounderstand how virtualization is used in a cloud environment. A virtual machine (typically referred to as a “VM”) is usually a commodity operating system instance that is contained in a configured and running OS image. The OS image is a snapshot of a server and includes space for virtual disk storage. You need some form of technology to support the virtual machines and this is done using a hypervisor. The Hypervisor presents to the VM the hardware environment that it can work with.

Different virtualization platforms will use different approaches. Regardless of the vendor, there are two standard types of virtualization platforms that are in use today:

  • Type 1 hypervisors run directly on bare hardware. Guest operating systems run on top of the hypervisor. Examples include Microsoft Hyper-Vand VMware ESX.
  • Type 2 hypervisors are also called “hosted hypervisors” where the hypervisor runs as a program in the host OS. VMs run on top of the Type 2 hypervisor. Examples of Type 2 hypervisors include Oracle VirtualBox, Parallels, Virtual PC, VMware Fusion, VMware Server, Xen, and XenServer.

An in depth discussion of how virtualization works is beyond the scope of this article. There are a number of good resources on the Microsoft and VMware web sites where you can learn more about virtualization platforms. What we’re going to focus on here are some important security issues related to hypervisors, and these security issues become even more important when we think about using virtualization in the cloud. Let’s look at some of them:

  • The first consideration is that when you create a new virtual machine and turn it on, you’ll be adding a new operating system to your production environment. Regardless of the operating system, each running operating system has its own security risks. That means you need to be very careful that each operating system running in your virtual environment be patched, maintained, and monitored as appropriate per its intended use, just like any non-virtual operating system on your network.
  • Next, you need to be aware that the common network intrusion detection systems that are used on enterprise networks today do not necessarily work as well in a virtualized infrastructure. This is especially the case when the traffic you want to monitor is taking place between virtual machines hosted on the same virtual server or a member of a virtual server cluster or array. The result is that methods used to monitor traffic between VMs will need to use alternative methods or entirely forego network based intrusion detection system and move the detection back to the host.
  • Another important is that when you move virtual machines from one physical server to another, such as when you employ dynamic resource scheduling or PRO – network monitoring, systems may not know that these virtual machines and the services they run have moved, and thus may generate alarms that are false (false positives). The situation is even more problematic when you use clustering in conjunction with virtualization.
  • Finally, virtualization requires that you adopt different management practices across the entire solution for the services that you’re delivering. Issues such as desired configuration management (DCM), virtual machine mobility and capacity planning and management need to be reexamined. In addition, you may run into problems with resource allocation that can lead to significant slowing of the entire infrastructure. For these reasons, you need to pay particular attention to performance management when running applications and services in a virtualized environment.

Cloud Computing and Virtualization Platform Security

So now we know that the cloud is about much more than server virtualization. When you move from server consolidation to using virtualization to create a public, private or hybrid cloud computing environment, you move from a traditional datacenter to a dynamic, service oriented and focused cloud deployment. When virtualization is used in cloud computing, you will see that the management infrastructure you used for your physical server-based deployment will fall short virtualization based cloud infrastructure.

In a traditional datacenter, automation is not usually such a major component unless the number of client or server operating systems to be deployed and the administrative overhead would be overwhelming without some method of automation. In general, in today’s LAN based datacenter, setting up new physical servers includes at least some manual steps performed by the admin. In contrast, in a cloud environment, the OS must be highly automated to support several of the key tenets of cloud computing itself.

Another thing to keep in mind is that virtualization changes the relationship between the operating system and the hardware on which it runs. In itself, this will change your perspective from a security standpoint as it challenges the comfort you’ve felt in the past when you deploy an operating system and applications on a server that you can physically touch and feel. However, this belief that something you can touch and feel is inherently more secure isn’t necessarily valid. Think about the typical user and how that user thinks about security in regard to a laptop connected to the Internet. The abstractions that are imposed by virtualization make the security tableau of the operating system even muddier.

You need to consider several important security concerns when thinking about the role of virtualization in cloud computing. Perhaps the most important of these concerns, which you do not see in a non-virtualized environment, is what can happen if the hypervisor itself is compromised. The hypervisor has access to all the guest workloads running in the cloud infrastructure. When you think about cloud deployments, which can run literally thousands or tens of thousands of virtual machines, compromise of the hypervisor could have broad and devastating impact if not otherwise mitigated by using network isolation.

This means that it’s important that you consider your hypervisor platform before adopting one based on marketing messages or market share. The hypervisor is a small piece of software with some very specific duties. A hypervisor is much smaller and more targeted than an operating system designed to provide an interface and development environment for applications. The hypervisor should have no externally accessible network ports that can be leveraged by an attacker. The hypervisor should rarely if ever require patching. Another very important requirement is that the guest operating systems must not have direct access to the hypervisor.

The hypervisor should be invisible to the network, with the possible exception of traffic destined to the hypervisor management interface. The probability is low that the hypervisor will be attacked in the near future because both the vulnerability of the hypervisor and the probability of an attack are low at this time. However, there is a good chance that this will change in the future as hackers begin to focus their efforts on hypervisors.

Another security issue that’s related to virtualization deals with the allocating and deallocating of resources in an elastic environment, which might include things such as local storage associated with VMs. If data is written to physical media-or to memory-and it is not cleared before that storage is reallocated to another VM, then there is a chance for data leakage. Of course, these problems are not unique to cloud environments and there are well-defined mitigations enabled by all commonly used operating systems.

There are a couple of important points to consider regarding how operating systems handle reallocation:

  • The operating system may stop or crash before resources are zeroed out.
  • Not all operating systems manage the clearing data in the same way; some may clear it on release, whereas others may do so on allocation.

Therefore, it is possible for different operating systems to handle reallocation in different ways. Because of this, you need to take control over your storage and memory when using a public cloud and to the same extent, the private cloud. You do this by clearing the data yourself and setting policies for clearing sensitive data that includes special handling. You need to have processes in place that confirm that a released resource was in fact cleared. When sensitive data is handled in any situation where bits (located in places such as memory buffers or temp files) may be exposed to others, you must put more effort into securely handling this data.

For example, when some code obtains a clear text password from a user (this can be over an encrypted or unencrypted network link), the memory buffers used to capture the password and transmit the clear text password for authentication must be removed as part of the authentication process. If you don’t do this, you extend the risk of exposure. You can do this as as an “atomic operation”, which is one that is completed or not performed at all. That is to say, if the operation fails, it rolls back to the previous state.

What about network attacks between guests that are hosted on the same server in a virtual server array or cluster? Can you detect them? The problem is that unless you can see the traffic from each VM, you can’t confirm that traffic is not possible between the VMs, even if you have put these security controls in place. There are several possible solutions you can employ. One is that the VM user can simply invoke OS-based traffic filtering or firewalling, and another is that you can deploy new virtual instances of traditional network management and monitoring solutions, such as the Cisco 1000V.

What if you have multiple communicating and interoperating VMs that need to be dynamically moved around to load balance your cloud? If the VM’s IP addresses change when they are moved from host to host and static addressing is used for firewall rules, then firewall filtering might fail. Network virtualization will need to provide a network interface to the VM. The interface might be a multiplexed virtual NIC with all of the switching and routing handled in the network fabric.

Most enterprise grade hypervisors (for example, Microsoft Hyper-V) have virtual switches (as well assupport for virtual firewalls) that are situated between the server’s physical NICs and the virtual NICs used by the VMs. The cloud fabric must adapt to changes as they are made to the VM locations and enabled or at least address allowable and disallowable communication paths between them.

Another method that you can use for limiting traffic between VMs would be to use physical location to associate and isolate different security zones that are represented by VMs. VMs should be traceable to their owners throughout the life cycle of the VM and would only be co-located on host servers with other VMs that meet the requirements for co-location, such as being members of the same security zone.

In order for this to work, we need support for VLANs beyond the core physical network infrastructure to push it down to host virtual servers. The good news is that enterprise solutions like Hyper-V and ESX support this today. However, the solution also needs to scale VLAN capabilities to support large dynamic clouds. Again, with the introduction of System Center Virtual Machine Manager 2012, you will have that support and it can be tied in with your current network management systems and choice of hypervisor (SCVMM supports Hyper-V, ESX and Xen).

The bottom line from a security standpoint is that vendors are being diligent in obtaining security certifications of their solutions. They (and now you) recognize that virtualization makes infrastructure management more complex, and when you introduce the other key aspects of cloud computing, massive automation is used to support enormous scale, elasticity and on-demand self-service requirements. Because of this automation and scale, you need to manage risk in virtualized cloud environments by architecting, planning and managing with greater diligence than ever before. Management automation enables your virtualized cloud environment to have better security, because it will be integrated from inception to deployment.

 

If you would like to read the other parts in this article series please go to:

 

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top