From Secure Virtualization to
Secure Private Clouds
Gartner RAS Core Research Note G00208057, Neil MacDonald, Thomas J. Bittman, 13 October 2010, RV2A108222011
As enterprises move beyond virtualizing their data centers to
build private cloud-computing infrastructures, security must
evolve to support this. While the fundamental principles of
information security don’t change, how enterprises provision and
deliver security services must change. This research outlines the
foundational capabilities that will be required from enterprise
security infrastructure to secure private cloud computing.
Key Findings
• Policies tied to physical attributes, security policy enforcement points embedded within physical appliances, and the usage of air gaps for security will inhibit private cloud adoption. • Virtualization of security controls is an important step in enabling secure private clouds, but other capabilities are required. • Context enablement, including application, identity and content awareness, will be critical to supporting secure private cloud computing. • Securing a private cloud can’t be just about technology, or it will fail. Changes to processes and a shift in mind-set will also be required. • The need for security must not be overlooked or “bolted on” later during the transition to private cloud computing.Recommendations
• Change your mind-set about information security to think of it as a set of adaptive services that are delivered via programmable infrastructure and controlled by contextual policies based on logical attributes to create adaptive zones of trust, using a separately configurable control plane. • Pressure incumbent security vendors to deliver their security controls in a virtualized form to more easily address secure private cloud-computing requirements. • In evaluations, heavily weight the ability to use a consistent way of expressing security policy across physical, virtualized and private cloud-computing environments as compared to using different vendors and solutions to address each separately.• Maintain separation of duties between security policy enforcement and IT operations in the transition to virtualized data centers and then to private cloud-computing environments. • Begin the transformation to context-aware and adaptive security infrastructure now as you upgrade and replace legacy static security infrastructure, such as network and application firewalls, intrusion detection systems (IDSs)/intrusion prevention systems (IPSs) and Web security platforms.
STRATEGIC PLANNING ASSUMPTIONS
By 2015, 40% of the security controls used within enterprise data centers will be virtualized, up from less than 5% in 2010. By 2015, 70% of enterprises will allow server workloads of different trust levels to share the same physical hardware within their own data center, except where explicitly prohibited by a regulatory or auditor compliance concern.
ANALYSIS
Gartner defines “cloud computing” (including both private and public clouds) as a style of computing where scalable and elastic IT-enabled capabilities are delivered as a service to customers using Internet technologies. Often, the term “cloud” is used as a shorthand to talk about the attributes that enterprises believe cloud-based computing architectures will offer. Consumers of cloud-based services want usage-based consumption of the services via standard Internet technologies and self-service interfaces. Providers of cloud-based services want the ability to deliver scalable, shareable, automated and elastic services. We discuss these attributes in “Five Refining Attributes of Public and Private Cloud Computing.” At its core, private cloud computing is built on the same concepts, and clients indicate their desire to bring these same attributes into the enterprise data center. Here, the IT department becomes the cloud service provider to deliver IT as an elastic service to multiple internal customers. While the focus may shift slightly (for example, self-service provisioning for IT customers is more important, chargeback capabilities are typically less so), the desired attributes are the same. For most organizations, virtualization will provide the foundation and the steppingstone for the evolution to private cloud computing. However, the need for security must not be overlooked or “bolted on” later during the transition to private cloud computing.Private Clouds: Same Security Needs, New
Capabilities Required
Whether securing physical data centers, virtualized data centers or private clouds, the fundamental tenets of information security don’t change — ensuring the confidentiality, integrity, authenticity, access, and audit of our information and workloads. These objectives translate into traditional security controls and policy enforcement points (PEPs) — for example, firewalling, IPS, IDS, encryption, digital signatures, authentication and authorization. However, there will be significant changes required in how security is delivered. Whether supporting private cloud computing, public cloud computing, or both, security must become adaptive to support a paradigm where workloads are decoupled from the physical hardware underneath and dynamically allocated to a fabric of computing resources. Policies tied to physical attributes, such as the server, Internet Protocol (IP) address, Media Access Control (MAC) address or where physical host separation is used to provide isolation, break down with private cloud computing. For many organizations, the virtualization of security controls will provide the foundation to secure private cloud infrastructures, but alone, it will not be enough to create a secure private cloud. To support secure private cloud computing, security must be an integral, but separately configurable, part of the private cloud fabric, designed as a set of on-demand, elastic and programmable services, configured by policies tied to logical attributes to create adaptive trust zones capable of separating multiple tenants (see Figure 1). © 2010 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. Reproduction and distribution of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Although Gartner’s research may discuss legal issues related to the information technology business, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein are subject to change without notice.Figure 1. Evolving to Secure Private Clouds
Ideally, the security models used to support private clouds would enable multidimensional hybrid environments — spanning physical to virtual workloads within the same data center and spanning between on-premises and public cloud-based computing environments. In this research, we outline six necessary attributes of private cloud security infrastructure and describe how security must change to support the construction of secure private clouds.
A Set of On-Demand and Elastic Services
Rather than security being delivered as a set of siloed security product offerings embodied within physical appliances, it needs to be delivered as a set of services available “on demand” to protect workloads and information when and where they are needed. These services need to be integrated into the private cloud provisioning and management processes (not bolted on as an afterthought) and be made available to any type of workload — server or desktop (see Note 1). As workloads are provisioned, moved, modified, cloned and ultimately retired, the appropriate security policy would be associated with the workload throughout its life cycle. Although it is possible this type of adaptive security protection could be accomplished solely with physical security infrastructure and complex virtual LAN (VLAN) overlays, we believe most enterprises will use a combination of physical and virtualized security controls to extend security policy into private cloud structures. There are a variety of reasons for this, including addressing the loss of visibility of inter-VM traffic within a virtualized data center, as well as the input/output overhead if traffic is routed out to physical hardware for security policy enforcement. Virtualized security controls can place policy enforcement within the physical host, closer to the workload and information it is protecting when and where it is needed, enabling dynamic data center infrastructures as well as the potential to leverage alternative computing sourcing options. Physical appliances will continue to be used for high-bandwidth applications at the physical boundaries of organizations. Virtualized security controls will be used throughout the private cloud fabric for inter-VM inspection and at logical boundaries to create zones of trust for workloads of different trust levels. Ideally, physical and virtual security controls will intelligently coordinate their inspection to avoid redundant inspection. By 2015, 40% of the security controls used within enterprise data centers will be virtualized up from less than 5% in 2010. The transition from security as a set of products to delivering security as a set of services is a significant mind-set shift for information security professionals. Virtualized security controls will help to enable this shift. In contrast to physical security controls, which scale up using larger and larger hardware-based appliances, virtualized security PEPs running within security VMs will support the simultaneous need to scale out with a larger number of security VMs running in parallel closer to the workloads and information they protect, and taking advantage of the high-availability and load-balancing capabilities available to all VMs.
Programmable Infrastructure
The security infrastructure that supplies the security services discussed in the prior section must become “programmable” — meaning that the services are exposed for programmatic access (see Note 2). By definition, private and public cloud-computing infrastructure is consumable using Internet-based standards. In the case of programmable security infrastructure, the services are typically exposed using RESTful APIs, which are programming language and framework independent. By exposing security services via APIs, the security policy enforcement point infrastructure becomes programmable from policy administration and policy decision points (such as operational and security management consoles or from other security intelligence systems such as security information and event management systems). There are multiple benefits to this shift in capability. This enables significantly higher levels of automation than are possible with traditional security infrastructure. As new workloads are introduced into the private cloud, security infrastructure can be automatically configured via “self-service interfaces” (where the “user” is a provisioning system, not an end user) to protect the new workload based on predefined security policies without requiring manual programming of the security controls. This shift will enable information security professionals to focus their attention on managing policies, not programming infrastructure. Programmable security infrastructure can be modified in real time so that security services can adapt to workloads as they move dynamically within a private cloud or adapt as a workload’s behavior changes. Longer term, as application infrastructure evolves within private clouds, applications will come prepackaged with models of deployment, topology, management and security policies for policy-driven automation. Policies consumed by management consoles and other security policy administration points will ultimately drive the configuration and programming of the security and management plane, not information technology professionals. By enabling security professionals to focus on policies, this capability has the added benefit of reducing the chance for human error in the programming of the security infrastructure underneath. Note 2Programmatic API Access
These APIs will become a target for attack. To reduce the threat of attacks, the best practice will remain the isolation and separation of security and management control traffic to a separate physical network. Note 1 Workloads Workloads, in this sense, are the set of applications and services that support a given process, which may span more than one VM and one physical machine. This includes server and desktop workloads.
Policies That Are Based on Logical, Not Physical,
Attributes and Are Capable of Incorporating
Runtime Context Into Real-Time Security Decisions
The nature of the security policies that drive the automated configuration of the programmable infrastructure needs to change as well. As we move to virtualized data centers and then to private cloud infrastructure, increasingly, security policies need to be tied to logical, not physical, attributes. The decoupling and abstraction of the entire IT stack and movement to private and public cloud-computing models mean that workloads and information (even entire data centers with the notion of a virtual data center) will no longer be tied to specific devices, fixed IP or MAC addresses, breaking static security policies based on physical attributes. Security policies need to shift “up the stack” to logical attributes, such as the identity, group or role of the VM being protected; the identity, group or role of the application; the identity, group or role of the users; and the sensitivity of the workload and information being processed. The shift to identity, application and content awareness is part of a broader shift in information security to become context aware and adaptive. To enable faster and more-accurate assessments of whether a given action should be allowed or denied, we must incorporate more real-time context information at the time a security decision is made. Context is not limited to identity, application and content awareness. It will expand to include environmental context (such as the time of day and geographic location of the server), trust of the device, integrity of the virtualization platform underneath, reputation of the VM being loaded, behavior the user or VM is exhibiting, and so on. Context should also include virtualization awareness so that, as a workload is live migrated or cloned, the associated security automatically moves with the workload throughout its life cycle, without requiring manual intervention. There are multiple benefits to decoupling security policies from the workloads and information they protect. Powerful compound security policies can be delivered independent of network topology, avoiding complexity in VLAN configurations and network-cabling infrastructure. Also, by moving up the stack, security policies can be expressed in more business-friendly terms. For example, identifying which users and groups should access which applications is a straightforward policy to compose and attest to by the business process, information and application owners. Finally, by incorporating runtime context into security decisions, organizations can implement adaptive security policy based on the behavior of the user or of the workload (for example, if a workload is behaving oddly, place a stronger auditing control on it or limit its network access).
Adaptive Trust Zones That Are Capable of
High-Assurance Separation of Differing Trust Levels
Instead of administering security policies on a VM-by-VM basis, security policies based on logical attributes as described in the previous section will be used to create zones of trust — logical groups of workloads with similar security requirements and levels of trust (for example, all Payment Card Industry [PCI]-related workloads are assigned a specified level of security policy). As the policies are linked to groups of VMs and not physical infrastructure, the zones adapt throughout the life cycle of the VM as individual VMs move and as new workloads are introduced and assigned to the trust zone. In today’s virtualized data center, workloads of different trust levels are not typically combined onto the same physical server. However, this breaks the fluidity of private cloud-computing models. Increasingly, this capability will be desired for higher levels of efficiency and effectiveness of the resource fabric being shared. Leveraging emerging root of trust measurements for hypervisors and embedded hypervisors, secure private clouds need to be able to support workloads of different trust levels on the same physical hardware, without requiring the use of separate physical servers. By 2015, 70% of enterprises will allow server workloads of different trust levels to share the same physical hardware within their own data center, except where explicitly prohibited by a regulatory or auditor compliance concern. Adaptive trust zones will become the basis for trust, audit and compliance policies. Security policies will vary between trust zones, and security controls will be placed at the logical perimeters between key trust boundaries. For example, a trust zone of PCI-related workloads may require encryption of all data between virtual machines within the trust zone. It may also be restricted to access from only users associated with the PCI group; it may have all inter-VM traffic monitored with an intrusion detection system; and it may be separated from all other trust zones with stateful firewall inspection, as required by PCI. In contrast, a trust zone of virtual desktop infrastructure (VDI)-related workloads may be treated as untrusted with firewalling and in-line IPS-based inspection of all traffic to and from the zone, as well as blocking of any direct peer-to-peer traffic within the zone. Trust zones may be nested so that what was a single, physical data center can now be managed and secured as multiple, virtual data centers, each composed of multiple logical, not physical, perimeters around trust zones. Security policy may then be applied as needed within and between zones. In most cases, multiple trust zones will be allowed to reside on a single physical host with the enterprise able to define how much separation is sufficient for security and compliance purposes. For example, storage and backup can be isolated, and network traffic can be separated using IPS and firewalling enforcement, as internal or external compliance policies dictate. Private cloud infrastructure will require security services that are designed to provide high-assurance separation of workloads of different trust levels as a core capability. This is exactly the same type of separation capability required by public cloud providers to separate and isolate tenants from different organizations. For enterprises building private clouds, the concepts are identical — although instead of tenants from different organizations, they will routinely be responsible for separating workloads of different trust levels, including different business units and divisions sharing the same underlying physical infrastructure.
Separately Configurable Security Policy
Management and Control
Security must not be weakened as it is virtualized and incorporated into cloud-based computing infrastructures. The security controls and policies discussed previously must not be able to be arbitrarily disabled by operational staff and should fail open or closed as enterprise policies dictate. Strong separation of duties/concerns between IT operations and security needs to be enforceable within a private cloud infrastructure, just as within physical infrastructure and virtualized infrastructure today. This separation occurs at multiple levels. If software controls are virtualized, we should not lose the separation of duties we had in the physical world. This requires that virtualization and private cloud-computing platform vendors provide the ability to separate security policy formation and the operation of security VMs from management policy formation and the operation of the other data center VMs. Typically, this will be enabled by integrating and controlling access to security operations at a granular level, using role-based access control within the management system controlled by integration with organizational and group information located in enterprise directories (typically Active Directory or an LDAP-enabled repository) along with delegated administration capabilities. Likewise, all security policy changes and operations to security VMs must be fully audited in tamper-resistant logs that are inaccessible to security administrators. A security policy manager will enable the orchestration and definition of security policies and the assignment of policies to the logical attributes of the workloads and groups of workloads, as described previously with an emphasis on policy integrity and testing. As a given, VMs may be assigned multiple security policies and may be members of more than one trust zone. The policy management system should support multiple, overlapping security policies to be assigned and be able to identify the resultant least-privilege policy and provide for policy resolution in the event of a conflict. Ideally, the system will support proactive modeling of “what if” scenarios before policy changes are implemented.
“Federatable” Security Policy and Identity
Private clouds will be deployed incrementally, not all at once. Private clouds will be carved out of existing data centers, where only a portion has been converted to a private cloud model. In addition, many enterprises will have a percentage of workloads that haven’t been virtualized for years to come. Ideally, private cloud security infrastructure would be able to exchange and share policies with other data center security infrastructure — virtualized and physical. There are no clear standards for the sharing of security policy. Spanning physical to virtualized infrastructure will require using the same vendor the enterprise has chosen to provide security in both environments, or using different vendors in each environment. Ideally, security controls placed across physical and virtualized infrastructure will be able to intelligently cooperate for workload inspection — for example, data going to and from the data center inspected by hardware-based physical security appliances. Organizations will also begin experimentation with public cloud infrastructure as a service (IaaS) providers creating hybrid private/ public cloud-computing environments. Ideally, security policies designed to protect workloads, when on premises, would also be able to be federated (along with user identity-related information) to public cloud providers. There are no established standards for this either. However, the VMware vCloud API is a start, as is work within the Distributed Management Task Force (DMTF) to extend Open Virtualization Format (OVF) to express security policy. Absent clear standards and APIs, capabilities for extending enterprise security policy will remain fragmented, relying on a combination of controls bundled within workloads, virtual private network-based extension of network security policies, remote console-based policy management, remote API-based programming of service provider policies, and written commitments for security service levels.
