With the sonic boom of Cloud, Today’s CIOs are tripping over themselves to hastily push as many of their technology initiatives as possible into the Cloud. Cloud computing has become the modern day penicillin for technology challenges allowing the Enterprise CIO to mitigate CAPEX, leverage performance driven offerings and transfer the operation, management and maintenance of infrastructure to a Cloud services provider. While on the surface this sounds like motherhood and apple pie, it is imperative that IT leaders peel back the layers and ensure they know exactly what they are, and aren’t, buying and understand the underlying platforms supporting their IT systems and how they are delivered. Virtualization, especially on shared platforms, inherently has a breadth of security concerns that require on-going management, regardless of whether systems are insourced or outsourced. Most importantly, as security professionals, it is our job to ensure our companies aren’t sacrificing security principles while migrating into this modern day consumption model.
Exploring Some Basic Virtualization Concerns
The vast majority of Cloud products are built on a layer of clustered physical hardware running a hypervisor that enables virtualization, or support for multiple virtual machines (VMs), on a single physical chassis. Thus, the hypervisor abstracts the hardware and software layers allowing the underlying server infrastructure to provide the processing power and memory while, in many cases, the VMs cohabitate on both (Vasudevan, McCune and Qu). Due to the structure and interaction of the VMs with the hypervisor and then the hypervisor with the common hardware elements of the server’s computing architecture, there is constant concern around the potential vulnerabilities that this common binding can create. Some of the key areas of concern rooted in the virtualization hierarchy include: 1) Trojaned virtual machines, 2) improperly configured security, 3) improperly configured hypervisors and 4) data leakage through offline images (Cox). A brief outline each of these potential vulnerabilities will be provided so a better understanding of the risk can be gained.
A key concern for any virtualized Cloud consumer should be Trojan machines. A Trojan machine can take one of many different forms, but for the purposes of this blog include an infected VM image file, a VM image file that contains malicious code or a VM sharing a common physical platform for the purposes of reconnaissance and/or attacking another VM. A recent Trojan, Crisis, discovered by Kapersky Labs in July 2012, is able to replicate itself into a VM instance (Rashid). While this was the first known Trojan that specifically attacks virtual machines, it is a reasonable assumption that this will be a lucrative target moving forward (Rashid). Additionally, attacks aren’t always malicious or intentional. It was reported that Amazon Cloud customers determined that one of the Amazon Machine Images (AMIs) that are part of their community image library, used as base images for their Cloud service, was compromised (Cox). In this case, the image was not intentionally being distributed, yet, customers were using a compromised machine from their initial installation. Lastly, it is conceivable that a virtual machine running on a common hypervisor and physical platform could allow a malicious operator to gain knowledge about a target VM, or even gain access to its contents. Further, a post doctoral researcher in MIT’s Computer Science and Artificial Intelligence lab, and three of his colleagues, claimed that a snooper could land on the same VM host on Amazon’s cloud service by launching their VM at the same time as the target (Babcock). In order to ensure proper VM behavior and optimize security, it is critical that VMs are built from known good source images, monitored for proper behavior and that shared platform exposures and understood.
While VMs create a separation between the hardware and software layers of the server infrastructure, they have also blurred the long standing boundaries between the Server Administrator and Network Engineer. Traditionally, the network engineer has been more focused on the proper movement of data across the corporate network and, in many cases, many of the associated security functions; on the other hand, the System Administrator has simply cared for the operation and maintenance of the server hardware. Due to the full stack integration brought about by virtual machines and hypervisors, ranging from the server down through the network, many of the functions that have traditionally fallen to the Network Engineer, such as VLAN tagging, QoS, routing and access-lists, have now fallen to the administrators of the virtual environment – who may or may not possess the qualifications to properly secure the environment (Cox). The result is a gap requiring a “super IT administrator” in order to have the breadth and depth in skills in order to fulfill all of the skill requirements to deliver virtual services using best practices. Alternatively, the hypervisor itself needs to allow for multiple Administrators and Engineers collaborating together to optimally build and deliver a virtual machine. Without ensuring the right skills are performing the right tasks, the same integration of functions that make VMs and Cloud an ideal environment can also convolute the management and security of the infrastructure.
While the hypervisor performs the “magic” that allows our VMs to share a common set of physical platforms, it is also a core and obvious area of exposure if not properly configured and secured. Because the hypervisor management platform authorizes who can create, delete and change virtual machines, as well as, the accessibility between various VMs and common resources, it is critical that the hypervisor and the management platform are properly secured within a Cloud environment (Scarfone, Souppaya and Hoffman). The first level of securing the hypervisor should address user management and access control; the ability to authenticate should provide a front line of defense to ensure scalable and tiered levels of access to Cloud administrators. Further, authorization should restrict administrator’s access to only the resources they directly administer to reduce insider threat, mitigate risk of misconfigurations and prevent unnecessary access. Secondly, while there are some communication functions that that are required for the basic operation of the VM, it is important that policies exist to define the rules for intra-customer VM to VM access, as well as, inter-customer VM interactions. Further it is critical that the policies are established and followed and then reviewed and maintained regularly.
The last concern to review is the snapshot and VM image management exposure posed by VMs and the hypervisor. Since VMs are hardware independent, Cloud administrators have the ability to pause, stop and even take snapshots, a real-time image of the entire VM – including the contents of the memory – and store it in a file (Cox). Since these files can be stored, moved, duplicated, etc., if the VM or memory contained sensitive or confidential data, it could create a significant risk for an organization. If a Cloud provider is taking regular snapshots for a customer, the handling and storage of this information could pose a greater threat than the active VM itself. Also, it is critical that VMs are properly monitored and/or decommissioned after use, as well as, VM image files are diligently secured commensurate with the level of sensitivity of the data contained within the VM (Bateman). Ironically, the greatest expose created by the VM may not be the active VM itself, but instead the offline data that also requires full lifecycle security considerations.
So Should I Cloud?
Now that some of the primary security concerns for virtualized Cloud computing have been established and discussed, the key question is – now what? Can Cloud computing even be trusted? The answer is — whether a Cloud provider is used, or an Enterprise builds and hosts their own virtualized infrastructure, similar risks will exist and need to be managed. The primary difference lies in the level of control that you, as a customer of the Cloud provider, posses to ensure that your IT resources are being managed, maintained and secured using best practices and within your policy and compliancy requirements. No different than the enterprise, Cloud providers need to define policies, procedures and controls to manage and mitigate risks that exist with a delivering a virtualized solution. Further, these initiatives should be clearly documented and systematically communicated to their customers.
IT leadership considering Cloud outsourcing solutions need to understand the resources they are considering shifting to the Cloud. This includes an awareness of all aspects of the systems including the type(and sensitivity) of the data, specific compliance requirements that might exist (e.g. PCI), recovery time and recovery point targets, the impact of downtime, the providers security practices, etc. From there, a thorough review of the available Cloud solutions should also be conducted. The review should include and align the critical elements identified when reviewing the systems to be outsourced. Additionally, an understanding of how the provider sets policies, what their standard policies are and whether any customer specific flexibility exists should also be determined. Finally, the criteria and requirements can be aligned with the potential scope of Cloud providers. It is only from this perspective that educated decisions can be made and needs can be aligned with offerings.
Cloud is not the enemy, but more an inevitable shift in how IT resources are consumed by the Enterprise. Awareness of what the cloud is, and isn’t, is essential; Cloud shouldn’t be a black box where you put all of your systems and data and then believe that all of your risk and exposure is gone. Security concerns don’t dissolve into the ether by moving your systems to the Cloud. Arguably, they are greater as the Enterprise’s focus should shift to validation and verification of the security posture of their Cloud environment. After all, you never know who may be sharing the same virtual plane with you on the physical device hosting your VMs.
Babcock, Charles. Information Week. 27 April 2012. <http://www.informationweek.com/cloud-computing/infrastructure/vmware-breach-time-to-assume-hypervisor/232901071>.
Bateman, Kayleigh. Don’t Let Dormant Virtual Machines Threaten Data Centre Security. n.d. <http://www.computerweekly.com/news/1370369/Dont-let-dormant-virtual-machines-threaten-data-centre-security>.
Cox, Philip. Top Security Virtualization Risks and How to Prevent Them. Islandia, 2011.
Rashid, Fahmida Y. Security Watch. 21 August 2012. <http://securitywatch.pcmag.com/none/301770-crisis-trojan-first-malware-to-target-virtual-machines>.
Scarfone, Karen, Murungia Souppaya and Paul Hoffman. Guide to Security for Full Virtualization Technolgies. Gaithersburg: NIST, 2011.
Vasudevan, Amit, et al. Requirements for an Integrity-Protected Hypervisor on the X86 Hardware Virtualized Architecture. n.d.