Security guidance for critical areas of focus in cloud computing

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD

COMPUTING V3.0

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 1

INTRODUCTION

The guidance provided herein is the third version of the Cloud Security Alliance document, “Security Guidance for Critical Areas of Focus in Cloud Computing,” which was originally released in April 2009. The permanent archive locations for these documents are:

http://www.cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf (this document)

http://www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf (version 2 guidance)

http://www.cloudsecurityalliance.org/guidance/csaguide.v1.0.pdf (version 1 guidance)

In a departure from the second version of our guidance, each domain was assigned its own editor and peer reviewed by industry experts. The structure and numbering of the domains align with industry standards and best practices. We encourage the adoption of this guidance as a good operating practice in strategic management of cloud services. These white papers and their release schedule are located at:

http://www.cloudsecurityalliance.org/guidance/

In another change from the second version, there are some updated domain names. We have these changes: Domain 3: Legal Issues: Contracts and Electronic Discovery and Domain 5: Information Management and Data Security. We now have added another domain, which is Domain 14: Security as a Service.

© 2011 Cloud Security Alliance.

All rights reserved. You may download, store, display on your computer, view, print, and link to the Cloud Security Alliance Guidance at http://www.cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf subject to the following: (a) the Guidance may be used solely for your personal, informational, non-commercial use; (b) the Guidance may not be modified or altered in any way; (c) the Guidance may not be redistributed; and (d) the trademark, copyright or other notices may not be removed. You may quote portions of the Guidance as permitted by the Fair Use provisions of the United States Copyright Act, provided that you attribute the portions to the Cloud Security Alliance Guidance Version 3.0 (2011).

http://www.cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf
http://www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf
http://www.cloudsecurityalliance.org/guidance/csaguide.v1.0.pdf
http://www.cloudsecurityalliance.org/guidance/
http://www.cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf
SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 2

TABLE OF CONTENTS

Introduction ........................................................................................................................................................................... 1

Foreword ................................................................................................................................................................................ 3

Acknowledgments ................................................................................................................................................................. 4

Letter from the Editors .......................................................................................................................................................... 6

An Editorial Note on Risk ...................................................................................................................................................... 8

Section I. Cloud Architecture ............................................................................................................................................... 11

Domain 1: Cloud Computing Architectural Framework ....................................................................................................... 12

Section II. Governing in the Cloud ...................................................................................................................................... 29

Domain 2: Governance and Enterprise Risk Management .................................................................................................. 30

Domain 3: Legal Issues: Contracts and Electronic Discovery ............................................................................................... 35

Domain 4: Compliance and Audit Management .................................................................................................................. 45

Domain 5: Information Management and Data Security ..................................................................................................... 50

Domain 6: Interoperability and Portability .......................................................................................................................... 64

Section III. Operating in the Cloud ...................................................................................................................................... 73

Domain 7: Traditional Security, Business Continuity, and Disaster Recovery ..................................................................... 74

Domain 8: Data Center Operations ...................................................................................................................................... 89

Domain 9: Incident Response .............................................................................................................................................. 93

Domain 10: Application Security ........................................................................................................................................ 103

Domain 11: Encryption and Key Management .................................................................................................................. 129

Domain 12: Identity, Entitlement, and Access Management ............................................................................................ 136

Domain 13: Virtualization .................................................................................................................................................. 157

Domain 14: Security as a Service ....................................................................................................................................... 162

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 3

FOREWORD

Welcome to the third version of the Cloud Security Alliance’s “Security Guidance for Critical Areas of Focus in Cloud Computing.” As cloud computing begins to mature, managing the opportunities and security challenges becomes crucial to business development. We humbly hope to provide you with both guidance and inspiration to support your business needs while managing new risks.

The Cloud Security Alliance has delivered actionable, best practices based on previous versions of this guidance. As we continue to deliver tools to enable businesses to transition to cloud services while mitigating risk, this guidance will act as the compass for our future direction. In v3.0, you will find a collection of facts and opinions gathered from over seventy industry experts worldwide. We have compiled this information from a range of activities, including international chapters, partnerships, new research, and conference events geared towards furthering our mission. You can follow our activities at www.cloudsecurityalliance.org.

The path to secure cloud computing is surely a long one, requiring the participation of a broad set of stakeholders on a global basis. However, we should happily recognize the progress we are seeing: new cloud security solutions are regularly appearing, enterprises are using our guidance to engage with cloud providers, and a healthy public dialogue over compliance and trust issues has erupted around the world. The most important victory we have achieved is that security professionals are vigorously engaged in securing the future, rather than simply protecting the present.

Please stay engaged on this topic and continue to work with us to complete this important mission.

Best Regards,

Jerry Archer

Dave Cullinane

Nils Puhlmann

Alan Boehme

Paul Kurtz

Jim Reavis

The Cloud Security Alliance Board of Directors

http://www.cloudsecurityalliance.org/
SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 4

ACKNOWLEDGMENTS

Domain Authors/Contributors

Domain 1: Chris Hoff, Paul Simmonds

Domain 2: Marlin Pohlman, Becky Swain, Laura Posey, Bhavesh Bhagat

Domain 3: Francoise Gilbert, Pamela Jones Harbour, David Kessler, Sue Ross, Thomas Trappler

Domain 4: Marlin Pohlman, Said Tabet

Domain 5: Rich Mogull, Jesus Luna

Domain 6: Aradhna Chetal, Balaji Ramamoorthy, Jim Peterson, Joe Wallace, Michele Drgon, Tushar Bhavsar

Domain 7: Randolph Barr, Ram Kumar, Michael Machado, Marlin Pohlman

Domain 8: Liam Lynch

Domain 9: Michael Panico, Bernd Grobauer, Carlo Espiritu, Kathleen Moriarty, Lee Newcombe, Dominik Birk, Jeff Reed

Domain 10: Aradhna Chetal, Balaji Ramamoorthy, John Kinsella, Josey V. George, Sundararajan N., Devesh Bhatt, Tushar Bhavsar

Domain 11: Liam Lynch

Domain 12: Paul Simmonds, Andrew Yeomans, Ian Dobson, John Arnold, Adrian Secombe, Peter Johnson, Shane Tully, Balaji Ramamorthy, Subra Kumaraswamy, Rajiv Mishra, Ulrich Lang, Jens Laundrup, Yvonne Wilson

Domain 13: Dave Asprey, Richard Zhao, Kanchanna Ramasamy Balraj, Abhik Chaudhuri, Melvin M. Rodriguez

Domain 14: Jens Laundrup, Marlin Pohlman, Kevin Fielder

Peer Reviewers

Valmiki Mukherjee, Bernd Jaeger, Ulrich Lang, Hassan Takabi, Pw Carey, Xavier Guerin, Troy D. Casey, James Beadel, Anton Chuvakin, Tushar Jain, M S Prasad, Damir Savanovic, Eiji Sasahara, Chad Woolf, Stefan Pettersson, M S Prasad, Nrupak Shah, Kimberley Laris, Henry St. Andre, Jim Peterson, Ariel Litvin, Tatsuya Kamimura, George Ferguson, Andrew Hay, Danielito Vizcayno,

K.S. Abhiraj, Liam Lynch, Michael Marks, JP Morgenthal, Amol Godbole, Damu Kuttikrishnan, Rajiv Mishra, Dennis F. Poindexter, Neil Fryer, Andrea Bilobrk, Balaji Ramamoorthy, Damir Savanovic

Editorial Team

Archie Reed: Domains 3, 8, 9

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 5

Chris Rezek: Domains 2, 4, 5, 7, 13, 14

Paul Simmonds: Domains 1, 6, 10, 11, 12

CSA Staff

Technical Writer/Editor: Amy L. Van Antwerp

Graphic Designer: Kendall Scoboria

Research Director: J.R. Santos

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 6

LETTER FROM THE EDITORS

Over the past three years, the Cloud Security Alliance has attracted around 120 corporate members and has a broad remit to address all aspects of cloud security, including compliance, global security-related legislation and regulation, identity management, and the challenge of monitoring and auditing security across a cloud-based IT supply chain. CSA is becoming the focal point for security standards globally, aligning multiple, disparate government policies on cloud security and putting forward standards for ratification by international standards bodies.

CSA sees itself as a cloud security standards incubator, so its research projects use rapid development techniques to produce fast results. To this end, the CSA Guidance editorial team is proud to present the third version of its flagship “Security Guidance for Critical Areas of Focus in Cloud Computing.” This work is a set of best security practices CSA has put together for 14 domains involved in governing or operating the cloud (Cloud Architecture, Governance and Enterprise Risk Management, Legal: Contracts and Electronic Discovery, Compliance and Audit, Information Management and Data Security, Portability and Interoperability, Traditional Security, Business Continuity and Disaster Recovery, Data Center Operations, Incident Response, Notification and Remediation, Application Security, Encryption and Key Management, Identity and Access Management, Virtualization, and Security as a Service).

CSA guidance in its third edition seeks to establish a stable, secure baseline for cloud operations. This effort provides a practical, actionable road map to managers wanting to adopt the cloud paradigm safely and securely. Domains have been rewritten to emphasize security, stability, and privacy, ensuring corporate privacy in a multi-tenant environment.

Over the past two years, version 2.1 of the guidance has served as the foundation for research in multiple areas of cloud security. Deliverables now in use from the TCI Architecture to the GRC Stack were inspired by previous versions of the guidance, and it is our hope that this version will be no different. The guidance serves as a high level primer for chief executives, consumers, and implementers wishing to adopt cloud services as an alternative or supplement to traditional infrastructure. However, the guidance is designed with innovation in mind. Those with an entrepreneurial mindset should read this work with an eye toward the inferred services and approaches many of the authors have included in the domain creation. Investors and corporate decision makers will also find this work of interest, as it serves as a roadmap for innovation and development already in place in companies throughout the world. Security practitioners and educators will find elements of this book both authoritative and thought provoking, and as the industry evolves, the value the authors have included should prove influential and timely.

In the third edition, the guidance assumes a structural maturity in parallel with multinational cloud standards development in both structure and content. Version 3.0 extends the content included in previous versions with practical recommendations and requirements that can be measured and audited. Please note that different interpretations of the term "requirements" exist, which we use throughout the document. Our guidance does not represent a statutory obligation, but "requirements" was chosen to represent guidance appropriate for virtually all use cases we could envision, and also aligns our guidance with similar well-accepted documents. CSA industry expert authors have endeavored to present a working product that is measured and balanced between the interests of cloud providers and tenants. Controls focus on the preservation of tenant data ownership integrity while embracing the concept of a shared physical infrastructure. Guidance Version 3.0 incorporates the highly dynamic nature of cloud computing, industry learning curve, and new developments within other research projects such as Cloud Controls Matrix, Consensus Assessments Initiative, Trusted Cloud Initiative, and GRC Stack Initiative and ties in the various CSA activities into one comprehensive C-level best practice. The Security Guidance v3.0 will serve as the gateway to emerging standards being

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 7

developed in the world’s standards organization and is designed to serve as an executive-level primer to any organization seeking a secure, stable transition to hosting their business operations in the cloud.

On behalf of the Cloud Security Alliance, we would like to thank each and every volunteer for their time and effort in the development and editing of this new release of our flagship guidance document. While we believe this is our best, most widely reviewed work to date, the topic is still evolving and although our foremost intent is to guide, we also intend to inspire the readers to become involved in improving and commenting on the direction those composing the body of work have outlined. We humbly and respectfully submit this effort to the industry and await the most important component of any dialog, your opinion. We are eager to hear your feedback regarding this updated guidance. If you found this guidance helpful or would like to see it improved, please consider joining the Cloud Security Alliance as a member or contributor.

Best Regards,

Paul Simmonds

Chris Rezek

Archie Reed

Security Guidance v3.0 Editors

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 8

AN EDITORIAL NOTE ON RISK

Throughout this Guidance we make extensive recommendations on reducing your risk when adopting cloud computing, but not all the recommendations are necessary or even realistic for all cloud deployments. As we compiled information from the different working groups during the editorial process, we quickly realized there simply wasn’t enough space to provide fully nuanced recommendations for all possible risk scenarios. Just as a critical application might be too important to move to a public cloud provider, there might be little or no reason to apply extensive security controls to low-value data migrating to cloud-based storage.

With so many different cloud deployment options — including the SPI service models (SPI refers to Software as a Service, Platform as a Service, or Infrastructure as a Service, explained in depth in Domain 1); public vs. private deployments, internal vs. external hosting, and various hybrid permutations — no list of security controls can cover all circumstances. As with any security area, organizations should adopt a risk-based approach to moving to the cloud and selecting security options. The following is a simple framework to help evaluate initial cloud risks and inform security decisions.

This process is not a full risk assessment framework, nor a methodology for determining all your security requirements. It’s a quick method for evaluating your tolerance for moving an asset to various cloud computing models.

Identify the Asset for the Cloud Deployment

At the simplest, assets supported by the cloud fall into two general categories:

1. Data

2. Applications/Functions/Processes

We are either moving information into the cloud, or transactions/processing (from partial functions all the way up to full applications).

With cloud computing our data and applications don’t need to reside in the same location, and we can choose to shift only parts of functions to the cloud. For example, we can host our application and data in our own data center, while still outsourcing a portion of its functionality to the cloud through a Platform as a Service.

The first step in evaluating risk for the cloud is to determine exactly what data or function is being considered for the cloud. This should include potential uses of the asset once it moves to the cloud to account for scope creep. Data and transaction volumes are often higher than expected.

Evaluate the Asset

The next step is to determine how important the data or function is to the organization. You don’t need to perform a detailed valuation exercise unless your organization has a process for that, but you do need at least a rough assessment of how sensitive an asset is, and how important an application/function/process is.

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 9

For each asset, ask the following questions:

1. How would we be harmed if the asset became widely public and widely distributed?

2. How would we be harmed if an employee of our cloud provider accessed the asset?

3. How would we be harmed if the process or function were manipulated by an outsider?

4. How would we be harmed if the process or function failed to provide expected results?

5. How would we be harmed if the information/data were unexpectedly changed?

6. How would we be harmed if the asset were unavailable for a period of time?

Essentially we are assessing confidentiality, integrity, and availability requirements for the asset; and how the risk changes if all or part of the asset is handled in the cloud. It’s very similar to assessing a potential outsourcing project, except that with cloud computing we have a wider array of deployment options, including internal models.

Map the Asset to Potential Cloud Deployment Models

Now we should have an understanding of the asset’s importance. Our next step is to determine which deployment models we are comfortable with. Before we start looking at potential providers, we should know if we can accept the risks implicit to the various deployment models: private, public, community, or hybrid; and hosting scenarios: internal, external, or combined.

For the asset, determine if you are willing to accept the following options:

1. Public.

2. Private, internal/on-premises.

3. Private, external (including dedicated or shared infrastructure).

4. Community; taking into account the hosting location, potential service provider, and identification of other community members.

5. Hybrid. To effectively evaluate a potential hybrid deployment, you must have in mind at least a rough architecture of where components, functions, and data will reside.

At this stage you should have a good idea of your comfort level for transitioning to the cloud, and which deployment models and locations fit your security and risk requirements.

Evaluate Potential Cloud Service Models and Providers

In this step focus on the degree of control you’ll have at each SPI tier to implement any required risk management. If you are evaluating a specific offering, at this point you might switch to a fuller risk assessment.

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 10

Your focus will be on the degree of control you have to implement risk mitigations in the different SPI tiers. If you already have specific requirements (e.g., for handling of regulated data) you can include them in the evaluation.

Map Out the Potential Data Flow

If you are evaluating a specific deployment option, map out the data flow between your organization, the cloud service, and any customers/other nodes. While most of these steps have been high-level, before making a final decision it’s absolutely essential to understand whether, and how, data can move in and out of the cloud.

If you have yet to decide on a particular offering, you’ll want to sketch out the rough data flow for any options on your acceptable list. This is to insure that as you make final decisions, you’ll be able to identify risk exposure points.

Conclusions

You should now understand the importance of what you are considering moving to the cloud, your risk tolerance (at least at a high level), and which combinations of deployment and service models are acceptable. You should also have a good idea of potential exposure points for sensitive information and operations.

These together should give you sufficient context to evaluate any other security controls in this Guidance. For low-value assets you don’t need the same level of security controls and can skip many of the recommendations — such as on-site inspections, discoverability, and complex encryption schemes. A high-value regulated asset might entail audit and data retention requirements. For another high-value asset not subject to regulatory restrictions, you might focus more on technical security controls.

Due to our limited space, as well as the depth and breadth of material to cover, this document contains extensive lists of security recommendations. Not all cloud deployments need every possible security and risk control. Spending a little time up front evaluating your risk tolerance and potential exposures will provide the context you need to pick and choose the best options for your organization and deployment.

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 11

SECTION I // CLOUD

ARCHITECTURE

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 12

DOMAIN 1 // CLOUD COMPUTING ARCHITECTURAL FRAMEWORK

This domain, the Cloud Computing Architectural Framework, provides a conceptual framework for the rest of the Cloud Security Alliance’s guidance. The contents of this domain focus on a description of cloud computing that is specifically tailored to the unique perspective of IT network and security professionals.

The final section of this domain provides a brief introduction to each of the other domains.

Understanding the architectural framework described in this domain is an important first step in understanding the remainder of the Cloud Security Alliance guidance. The framework defines many of the concepts and terms used throughout the other domains.

Overview. The following three sections define this architectural perspective in terms of:

 The terminology used throughout the guidance, to provide a consistent lexicon

 The architectural requirements and challenges for securing cloud applications and services

 A reference model that describes a taxonomy of cloud services and architectures

1.1 What Is Cloud Computing?

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). Cloud computing is a disruptive technology that has the potential to enhance collaboration, agility, scaling, and availability, and provides the opportunities for cost reduction through optimized and efficient computing. The cloud model envisages a world where components can be rapidly orchestrated, provisioned, implemented and decommissioned, and scaled up or down to provide an on-demand utility-like model of allocation and consumption.

From an architectural perspective, there is much confusion surrounding how cloud is both similar to and different from existing models of computing and how these similarities and differences impact the organizational, operational, and technological approaches to network and information security practices. There is a thin line between conventional computing and cloud computing. However, cloud computing will impact the organizational, operational, and technological approaches to data security, network security, and information security good practice.

There are many definitions today that attempt to address cloud from the perspective of academicians, architects, engineers, developers, managers, and consumers. This document focuses on a definition that is specifically tailored to the unique perspectives of IT network and security professionals.

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 13

1.2 What Comprises Cloud Computing?

This version of the Cloud Security Alliance’s Guidance features definitions that are based on published work of the scientists at the U.S. National Institute of Standards and Technology (NIST)1 and their efforts around defining cloud computing.

NIST’s publication is generally well accepted, and the Guidance aligns with the NIST Working Definition of Cloud Computing (NIST 800-145 as of this writing) to bring coherence and consensus around a common language to focus on use cases rather than semantic nuances.

It is important to note that this guide is intended to be broadly usable and applicable to organizations globally. While NIST is a U.S. government organization, the selection of this reference model should not be interpreted to suggest the exclusion of other points of view or geographies.

NIST defines cloud computing by describing five essential characteristics, three cloud service models, and four cloud deployment models. They are summarized in visual form in Figure 1 and explained in detail below.

Figure 1—NIST Visual Model of Cloud Computing Definition2

1 NIST - National Institute of Standards and Technology

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 14

1.3 The Characteristics of Cloud Computing

It is important to recognize that cloud services are often but not always utilized in conjunction with, and enabled by, virtualization technologies. There is no requirement, however, that ties the abstraction of resources to virtualization technologies, and in many offerings virtualization by hypervisor or operating system container is not utilized.

Further, it should be noted that multi-tenancy is not called out as an essential cloud characteristic by NIST but is often discussed as such. Although not an essential characteristic of cloud computing in the NIST model, CSA has identified multi-tenancy as an important element of cloud.

1.4 Multi-Tenancy

For this document multi tenancy is considered an important element, and the following section will outline the CSA’s understanding/definition as an important element of cloud computing.

Multi-tenancy in its simplest form implies use of same resources or application by multiple consumers that may belong to same organization or different organization. The impact of multi-tenancy is visibility of residual data or trace of operations by other user or tenant.

Multi-tenancy in cloud service models implies a need for policy-driven enforcement, segmentation, isolation, governance, service levels, and chargeback/billing models for different consumer constituencies.

Consumers may choose to utilize a public cloud providers’ service offering on an individual user basis or, in the instance

Figure 2—Multi-Tenancy

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 15

of private cloud hosting, an organization may segment users as different business units sharing a common infrastructure.

From a provider’s perspective, multi-tenancy suggests an architectural and design approach to enable economies of scale, availability, management, segmentation, isolation, and operational efficiency. These services leverage shared infrastructure, data, metadata, services, and applications across many different consumers.

Multi-tenancy can also take on different definitions depending upon the cloud service model of the provider; inasmuch as it may entail enabling the capabilities described above at the infrastructure, database, or application levels. An example would be the difference between an Infrastructure-as-a-Service (IaaS)2, Software-as-a-Service (SaaS)3, and (PaaS)4 multi-tenant implementation.

Cloud deployment models place different importance on multi-tenancy. However, even in the case of a private cloud, a single organization may have a multitude of third party consultants and contractors, as well as a desire for a high degree of logical separation between business units. Thus, multi-tenancy concerns should always be considered.

1.5 Cloud Reference Model

Understanding the relationships and dependencies between cloud computing models is critical to understanding cloud computing security risks. IaaS is the foundation of all cloud services, with PaaS building upon IaaS, and SaaS in turn building upon PaaS as described in the Cloud Reference Model diagram. In this way, just as capabilities are inherited, so are information security issues and risk. It is important to note that commercial cloud providers may not neatly fit into the layered service models. Nevertheless, the reference model is important for relating real-world services to an architectural framework and understanding that the resources and services require security analysis.

IaaS includes the entire infrastructure resource stack from the facilities to the hardware platforms that reside in them. It incorporates the capability to abstract resources (or not), as well as deliver physical and logical connectivity to those resources. Ultimately, IaaS provides a set of API’s5, which allows management and other forms of interaction with the infrastructure by consumers.

2 IaaS - Infrastructure as a Service 3 SaaS - Software as a Service 4 PaaS - Platform as a Service 5 API - Application Programming Interface

Software as a service (SaaS), sometimes referred to as "on-demand software," is a software delivery model in which software and its associated data are hosted centrally (typically in the (Internet) cloud) and are typically accessed by users using a thin client, normally using a web browser over the Internet.

Platform as a service (PaaS), is the delivery of a computing platform and solution stack as a service. PaaS offerings facilitate deployment of applications without the cost and complexity of buying and managing the underlying hardware and software and provisioning hosting capabilities. This provides all of the facilities required to support the complete life cycle of building and delivering web applications and services entirely available from the Internet.

Infrastructure as a Service (IaaS), delivers computer infrastructure (typically a platform virtualization environment) as a service, along with raw storage and networking. Rather than purchasing servers, software, data-center space, or network equipment, clients instead buy those resources as a fully outsourced service.

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 16

PaaS sits on top of IaaS and adds an additional layer of integration with application development frameworks, middleware capabilities, and functions such as database, messaging, and queuing. These services allow developers to build applications on the platform with programming languages and tools that are supported by the stack.

SaaS in turn is built upon the underlying IaaS and PaaS stacks and provides a self-contained operating environment that is used to deliver the entire user experience, including the content, its presentation, the application(s), and management capabilities.

It should therefore be clear that there are significant trade-offs to each model in terms of integrated features, complexity versus openness (extensibility), and security. Generally, SaaS provides the most integrated functionality built directly into the offering, with the least consumer extensibility, and a relatively high level of integrated security (at least the provider bears a responsibility for security).

PaaS is intended to enable developers to build their own applications on top of the platform. As a result, it tends to be more extensible than SaaS, at the expense of customer-ready features. This tradeoff extends to security features and capabilities, where the built-in capabilities are less complete, but there is more flexibility to layer on additional security.

IaaS provides few if any application-like features, but enormous extensibility. This generally means less integrated security capabilities and functionality beyond protecting the infrastructure itself. This model requires that operating systems, applications, and content be managed and secured by the cloud consumer.

The key takeaway for security architecture is that the lower down the stack the cloud service provider stops, the more security capabilities and management consumers are responsible for implementing and managing themselves.

Service levels, security, governance, compliance, and liability expectations of the service and provider are contractually stipulated, managed to, and enforced, when a service level agreement (SLA’s)6, is offered to the consumer. There are two types of SLA’s, negotiable and non-negotiable. In the absence of an SLA, the consumer administers all aspects of the cloud under its control. When a non-negotiable SLA is offered, the provider administers those portions stipulated in the agreement. In the case of PaaS or IaaS, it is usually the responsibility of the consumer’s system administrators to effectively manage the residual services specified in the SLA, with some offset expected by the provider for securing the underlying platform and infrastructure components to ensure basic service availability and security. It should be clear in all cases that one can assign/transfer responsibility but not necessarily accountability.

Narrowing the scope or specific capabilities and functionality within each of the cloud delivery models, or employing the functional coupling of services and capabilities across them, may yield derivative classifications. For example “Storage as a Service” is a specific sub-offering within the IaaS ‘family’.

While a broader review of the growing set of cloud computing solutions is outside the scope of this document, the OpenCrowd Cloud Solutions taxonomy in the figure below provides an excellent starting point, however the CSA does not specifically endorse any of the solutions or companies shown below. It provides the below diagram to demonstrate the diversity of offerings available today.

6 SLA - Service Level Agreement

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 17

Figure 3 – OpenCrowd Taxonomy7

For an excellent overview of the many cloud computing use cases, the Cloud Computing Use Case Group produced a collaborative work to describe and define common cases and demonstrate the benefits of cloud, with their goal being to “...bring together cloud consumers and cloud vendors to define common use cases for cloud computing...and highlight

7 http://www.opencrowd.com/assets/images/views/views_cloud-tax-lrg.png

http://www.opencrowd.com/assets/images/views/views_cloud-tax-lrg.png
SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 18

the capabilities and requirements that need to be standardized in a cloud environment to ensure interoperability, ease of integration, and portability.”

1.5.1 Cloud Security Reference Model

The cloud security reference model addresses the relationships of these classes and places them in context with their relevant security controls and concerns. For organizations and individuals grappling with cloud computing for the first time, it is important to note the following to avoid potential pitfalls and confusion:

 The notion of how cloud services are deployed is often used interchangeably with where they are provided, which can lead to confusion. Public or private clouds may be described as external or internal, which may not be accurate in all situations.

 The manner in which cloud services are consumed is often described relative to the location of an organization’s management or security perimeter (usually defined by the presence of a known demarc). While it is still important to understand where security boundaries lie in terms of cloud computing, the notion of a well- demarcated perimeter is an anachronistic concept for most organizations.

 The re-perimeterization and the erosion of trust boundaries already happening in the enterprise is amplified and accelerated by cloud computing. Ubiquitous connectivity, the amorphous nature of information interchange, and the ineffectiveness of traditional static security controls which cannot deal with the dynamic nature of cloud services, all require new thinking with regard to cloud computing. The Jericho Forum8 has produced a considerable amount of material on the re- perimeterization of enterprise networks, including many case studies.

The deployment and consumption modalities of cloud should be thought of not only within the context of ‘internal’ versus ‘external’ as they relate to the physical location of assets, resources, and information; but also by whom they are being consumed; and who is responsible for their governance, security, and compliance with policies and standards.

This is not to suggest that the on- or off-premise location of an asset, a resource, or information does not affect the security and risk posture of an organization because they do — but to underscore that risk also depends upon:

 The types of assets, resources, and information being managed

 Who manages them and how

 Which controls are selected and how they are integrated

 Compliance issues

For example, a LAMP9 stack deployed on Amazon’s AWS EC2 would be classified as a public, off-premise, third-party managed IaaS solution, even if the instances and applications/data contained within them were managed by the consumer or a third party. A custom application stack serving multiple business units, deployed on Eucalyptus under a

8 http://www.jerichoforum.org 9 LAMP-Linux (operating system), Apache HTTP Server, MySQL (database software) and Perl/PHP/Python, the principal components to build a viable general purpose web server

http://www.jerichoforum.org/
http://en.wikipedia.org/wiki/Apache_HTTP_Server
http://en.wikipedia.org/wiki/MySQL
http://en.wikipedia.org/wiki/Database_software
http://en.wikipedia.org/wiki/Perl
http://en.wikipedia.org/wiki/PHP
http://en.wikipedia.org/wiki/Python_(programming_language)
http://en.wikipedia.org/wiki/Web_server
SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 19

corporation’s control, management, and ownership, could be described as a private, on-premise, self-managed SaaS solution. Both examples utilize the elastic scaling and self-service capabilities of cloud.

The following table summarizes these points:

Table 1—Cloud Computing Deployment Models

Another way of visualizing how combinations of cloud service models, deployment models, physical locations of resources, and attribution of management and ownership, is the Jericho Forum’s Cloud Cube Model10, shown in the figure to the right:

The Cloud Cube Model illustrates the many permutations available in cloud offerings today and presents four criteria/dimensions in order to differentiate cloud “formations” from one another and the manner of their provision, in order to understand how cloud computing affects the way in which security might be approached.

The Cloud Cube Model also highlights the challenges of understanding and mapping cloud models to control frameworks and standards such as ISO/IEC 27002, which provides “...a series of guidelines and general principles for initiating,

10 http://www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf

Figure 4—Jericho Cloud Cube Model

http://www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf
SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 20

implementing, maintaining, and improving information security management within an organization.”

The ISO/IEC 27002, section 6.2, “External Parties” control objective states: “…the security of the organization’s information and information processing facilities should not be reduced by the introduction of external party products or services…”

As such, the differences in methods and responsibility for securing the three cloud service models mean that consumers of cloud services are faced with a challenging endeavor. Unless cloud providers can readily disclose their security controls and the extent to which they are implemented to the consumer and the consumer knows which controls are needed to maintain the security of their information, there is tremendous potential for misguided risk management decisions and detrimental outcomes.

First, one classifies a cloud service against the cloud architecture model. Then it is possible to map its security architecture as well as business, regulatory, and other compliance requirements against it as a gap-analysis exercise. The result determines the general “security” posture of a service and how it relates to an asset’s assurance and protection requirements.

The figure below shows an example of how a cloud service mapping can be compared against a catalogue of compensating controls to determine which controls exist and which do not — as provided by the consumer, the cloud service provider, or a third party. This can in turn be compared to a compliance framework or set of requirements such as PCI DSS, as shown.

Figure 5—Mapping the Cloud Model to the Security Control & Compliance

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 21

Once this gap analysis is complete, per the requirements of any regulatory or other compliance mandates, it becomes much easier to determine what needs to be done in order to feed back into a risk assessment framework. This, in turn, helps to determine how the gaps and ultimately risks should be addressed: accepted, transferred, or mitigated.

It is important to note that the use of cloud computing as an operational model does not inherently provide for or prevent achieving compliance. The ability to comply with any requirement is a direct result of the service and deployment model utilized and the design, deployment, and management of the resources in scope.

For an excellent overview of control frameworks which provides good illustrations of the generic control framework alluded to above, see the Open Security Architecture Group’s11 “landscape” of security architecture patterns documentation, or the always useful and recently updated NIST 800-53 revision 3 Recommended Security Controls for Federal Information Systems and Organizations security control catalogue.

1.5.2 What Is Security for Cloud Computing?

Security controls in cloud computing are, for the most part, no different than security controls in any IT environment. However, because of the cloud service models employed, the operational models, and the technologies used to enable cloud services, cloud computing may present different risks to an organization than traditional IT solutions.

An organization’s security posture is characterized by the maturity, effectiveness, and completeness of the risk-adjusted security controls implemented. These controls are implemented in one or more layers ranging from the facilities (physical security), to the network infrastructure (network security), to the IT systems (system security), all the way to the information and applications (application security). Additionally, controls are implemented at the people and process levels, such as separation of duties and change management, respectively.

As described earlier in this document, the security responsibilities of both the provider and the consumer greatly differ between cloud service models. Amazon’s AWS EC2 infrastructure as a service offering, as an example, includes vendor responsibility for security up to the hypervisor, meaning they can only address security controls such as physical security, environmental security, and virtualization security. The consumer, in turn, is responsible for security controls that relate to the IT system (instance) including the operating system, applications, and data.

The inverse is true for Salesforce.com’s customer resource management (CRM) SaaS offering. Because Salesforce.com provides the entire “stack,” the provider is not only responsible for the physical and environmental security controls, but it must also address the security controls on the infrastructure, the applications, and the data. This alleviates much of the consumer’s direct operational responsibility.

There is currently no way for a naive consumer of cloud services to simply understand what exactly he/she is responsible for [though reading this guidance document should help], but there are efforts underway by the CSA and other bodies to define standards around cloud audit.

One of the attractions of cloud computing is the cost efficiencies afforded by economies of scale, reuse, and standardization. To bring these efficiencies to bear, cloud providers have to provide services that are flexible enough to serve the largest customer base possible, maximizing their addressable market. Unfortunately, integrating security into these solutions is often perceived as making them more rigid.

11 www.opensecurityarchitecture.org

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 22

This rigidity often manifests in the inability to gain parity in security control deployment in cloud environments compared to traditional IT. This stems mostly from the abstraction of infrastructure, and the lack of visibility and capability to integrate many familiar security controls, especially at the network layer.

The figure below illustrates these issues: in SaaS environments the security controls and their scope are negotiated into the contracts for service; service levels, privacy, and compliance are all issues to be dealt with legally in contracts. In an IaaS offering, while the responsibility for securing the underlying infrastructure and abstraction layers belongs to the provider, the remainder of the stack is the consumer’s responsibility. PaaS offers a balance somewhere in between, where securing the platform falls onto the provider, but both securing the applications developed against the platform and developing them securely, belong to the consumer.

Figure 6—How Security Gets Integrated

Understanding the impact of these differences between service models and how they are deployed is critical to managing the risk posture of an organization.

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 23

1.5.3 Beyond Architecture: The Areas of Critical Focus

The thirteen other domains which comprise the remainder of the CSA guidance highlight areas of concern for cloud computing and are tuned to address both the strategic and tactical security ‘pain points’ within a cloud environment and can be applied to any combination of cloud service and deployment model.

The domains are divided into two broad categories: governance and operations. The governance domains are broad and address strategic and policy issues within a cloud computing environment, while the operational domains focus on more tactical security concerns and implementation within the architecture.

Table 2a— Governance Domains

DOMAIN GUIDANCE DEALING WITH…

Governance and Enterprise Risk Management

The ability of an organization to govern and measure enterprise risk introduced by cloud computing. Items such as legal precedence for agreement breaches, ability of user organizations to adequately assess risk of a cloud provider, responsibility to protect sensitive data when both user and provider may be at fault, and how international boundaries may affect these issues.

Legal Issues: Contracts and Electronic Discovery

Potential legal issues when using cloud computing. Issues touched on in this section include protection requirements for information and computer systems, security breach disclosure laws, regulatory requirements, privacy requirements, international laws, etc.

Compliance and Audit

Maintaining and proving compliance when using cloud computing. Issues dealing with evaluating how cloud computing affects compliance with internal security policies, as well as various compliance requirements (regulatory, legislative, and otherwise) are discussed here. This domain includes some direction on proving compliance during an audit.

Information Management and Data Security

Managing data that is placed in the cloud. Items surrounding the identification and control of data in the cloud, as well as compensating controls that can be used to deal with the loss of physical control when moving data to the cloud, are discussed here. Other items, such as who is responsible for data confidentiality, integrity, and availability are mentioned.

Portability and Interoperability

The ability to move data/services from one provider to another, or bring it entirely back in-house. Together with issues surrounding interoperability between providers.

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 24

Table 2b - Operational Domains

DOMAIN GUIDANCE DEALING WITH…

Traditional Security, Business Continuity and Disaster Recovery

How cloud computing affects the operational processes and procedures currently used to implement security, business continuity, and disaster recovery. The focus is to discuss and examine possible risks of cloud computing, in hopes of increasing dialogue and debate on the overwhelming demand for better enterprise risk management models. Further, the section touches on helping people to identify where cloud computing may assist in diminishing certain security risks, or entails increases in other areas.

Data Center Operations

How to evaluate a provider’s data center architecture and operations. This is primarily focused on helping users identify common data center characteristics that could be detrimental to on-going services, as well as characteristics that are fundamental to long-term stability.

Incident Response, Notification and Remediation

Proper and adequate incident detection, response, notification, and remediation. This attempts to address items that should be in place at both provider and user levels to enable proper incident handling and forensics. This domain will help you understand the complexities the cloud brings to your current incident-handling program.

Application Security

Securing application software that is running on or being developed in the cloud. This includes items such as whether it’s appropriate to migrate or design an application to run in the cloud, and if so, what type of cloud platform is most appropriate (SaaS, PaaS, or IaaS).

Encryption and Key Management

Identifying proper encryption usage and scalable key management. This section is not prescriptive, but is more informational in discussing why they are needed and identifying issues that arise in use, both for protecting access to resources as well as for protecting data.

Identity and Access Management

Managing identities and leveraging directory services to provide access control. The focus is on issues encountered when extending an organization’s identity into the cloud. This section provides insight into assessing an organization’s readiness to conduct cloud-based Identity, Entitlement, and Access Management (IdEA).

Virtualization

The use of virtualization technology in cloud computing. The domain addresses items such as risks associated with multi-tenancy, VM isolation, VM co- residence, hypervisor vulnerabilities, etc. This domain focuses on the security issues surrounding system/hardware virtualization, rather than a more general survey of all forms of virtualization.

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 25

Security as a Service

Providing third party facilitated security assurance, incident management, compliance attestation, and identity and access oversight. Security as a service is the delegation of detection, remediation, and governance of security infrastructure to a trusted third party with the proper tools and expertise. Users of this service gain the benefit of dedicated expertise and cutting edge technology in the fight to secure and harden sensitive business operations.

1.6 Cloud Deployment Models

Regardless of the service model utilized (SaaS, PaaS, or IaaS), there are four deployment models for cloud services with derivative variations that address specific requirements.

It is important to note that there are derivative cloud deployment models emerging due to the maturation of market offerings and customer demand. An example of such is virtual private clouds — a way of utilizing public cloud infrastructure in a private or semi-private manner and interconnecting these resources to the internal resources of a consumer’s datacenter, usually via virtual private network (VPN) connectivity.

The architectural mind-set used when designing “solutions” has clear implications on the future flexibility, security, and mobility of the resultant solution, as well as its collaborative capabilities. As a rule of thumb, perimeterized solutions are less effective than de-perimeterized solutions in each of the four areas. Careful consideration should also be given to the choice between proprietary and open solutions for similar reasons.

Deployment models

 Public Cloud. The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.

 Private Cloud. The cloud infrastructure is operated solely for a single organization. It may be managed by the organization or by a third party and may be located on-premise or off-premise.

 Community Cloud. The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, or compliance considerations). It may be managed by the organizations or by a third party and may be located on-premise or off-premise.

 Hybrid Cloud. The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load-balancing between clouds).

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 26

1.7 Recommendations

Cloud service delivery is divided among three archetypal models and various derivative combinations. The three fundamental classifications are often referred to as the “SPI Model,” where “SPI” refers to Software, Platform or Infrastructure (as a Service), respectively.

o Cloud Software as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities with the possible exception of limited user-specific application configuration settings.

o Cloud Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.

o Cloud Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which could include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

The NIST model and this document do not directly address the emerging service model definitions associated with cloud service brokers, those providers that offer intermediation, monitoring, transformation/portability, governance, provisioning, and integration services and negotiate relationships between various cloud providers and consumers.

In the short term, as innovation drives rapid solution development, consumers and providers of cloud services will enjoy varied methods of interacting with cloud services in the form of developing API’s and interfaces and so cloud service brokers will emerge as an important component in the overall cloud ecosystem.

Cloud service brokers will abstract these possibly incompatible capabilities and interfaces on behalf of consumers to provide proxy in advance of the arrival of common, open, and standardized ways of solving the problem longer term with a semantic capability that allows the consumer a fluidity and agility in being able to take advantage of the model that works best for their particular needs.

It is also important to note the emergence of many efforts centered on the development of both open and proprietary API’s, which seek to enable things such as management, security, and interoperability for cloud. Some of these efforts include the Open Cloud Computing Interface Working Group, Amazon EC2 API, VMware’s DMTF-submitted vCloud API, Sun’s Open Cloud API, Rackspace API, and GoGrid’s API, to name just a few. Open, standard API’s will play a key role in cloud portability and interoperability as well as common container formats such as the DMTF’s Open Virtualization Format (OVF).

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 27

While there are many working groups, drafts, and published specifications under consideration at this time, it is natural that consolidation will take effect as market forces, consumer demand, and economics pare down this landscape to a more manageable and interoperable set of players.

1.8 Requirements

Cloud services exhibit five essential characteristics that demonstrate their relation to, and differences from, traditional computing approaches.

 On-demand self-service. A consumer can unilaterally provision computing capabilities such as server time and network storage as needed automatically without requiring human interaction with a service provider.

 Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDA’s)12 as well as other traditional or cloud-based software services.

 Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi- tenant model with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a degree of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources, but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines. Even private clouds tend to pool resources between different parts of the same organization.

 Rapid elasticity. Capabilities can be rapidly and elastically provisioned — in some cases automatically — to quickly scale out; and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.

 Measured service. Cloud systems automatically control and optimize resource usage by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, or active user accounts). Resource usage can be monitored, controlled, and reported — providing transparency for both the provider and consumer of the service.

The keys to understanding how cloud architecture impacts security architecture are a common and concise lexicon coupled with a consistent taxonomy of offerings by which cloud services and architecture can be deconstructed, mapped to a model of compensating security and operational controls, risk assessment frameworks, and management frameworks; and in turn to compliance standards.

Understanding how architecture, technology, process, and human capital requirements change or remain the same when deploying cloud-computing services is critical. Without a clear understanding of the higher-level architectural implications, it is impossible to address more detailed issues rationally. This architectural overview, along with the thirteen other areas of critical focus, will provide the reader with a solid foundation for assessing, operationalizing, managing, and governing security in cloud computing environments.

12 PDA - Personal Digital Assistant

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 28

REFERENCES

[1] NIST definition of Cloud. NIST 500-292 “NIST Cloud Computing Reference Architecture”

[2] NIST definitions and API homepages. www.cloud-standards.org

[3] Jericho Forum Cloud Cube Model. www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf

http://www.cloud-standards.org/
http://www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf
SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 29

SECTION II // GOVERNING IN

THE CLOUD

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 30

DOMAIN 2 // GOVERNANCE & ENTERPRISE RISK MANAGEMENT

The fundamental issues of governance and enterprise risk management in cloud computing concern the identification and implementation of the appropriate organizational structures, processes, and controls to maintain effective information security governance, risk management, and compliance. Organizations should also assure reasonable information security across the information supply chain, encompassing providers and customers of cloud computing services and their supporting third party vendors, in any cloud deployment model.

An effective governance and enterprise risk management cloud computing program flows from well-developed information security governance processes as part of the organization’s overall corporate governance obligations of due care. Well-developed information security governance processes result in information security management programs that are scalable with the business, repeatable across the organization, measurable, sustainable, defensible, continually improving, and cost-effective on an ongoing basis.

For many cloud deployments, a major element of governance will be the agreement between provider and customer. For custom environments, detailed care can be taken, and negotiated, for each provision. For larger scale customer or providers, there will be a decision whether to trade off attention to detail vs. scalability of effort. Attention can be prioritized base on criticality or value at risk for the particular workload (e.g., up-time and availability may be more important for email than for HR systems). As the space continues to mature, projects like Cloud Audit or STAR will provide more standardized governance methods, therefore greater scalability.

Overview. This domain addresses:

 Governance

 Enterprise Risk Management

2.1 Corporate Governance

Corporate governance is the set of processes, technologies, customs, policies, laws, and institutions affecting the way an enterprise is directed, administered or controlled. Corporate governance also includes the relationship among the many stakeholders involved and the goals of the company involved. Good governance is based on the acceptance of the rights of shareholders, as the true owners of the corporation, and the role of senior management as trustees. There are many models of corporate governance; however, all follow five basic principles:

 Auditing supply chains

 Board and management structure and process

 Corporate responsibility and compliance

 Financial transparency and information disclosure

This section maps to the Cloud Control Matrix Controls DG-01, IS-02 and the use of GRC-XML and CloudAudit to establish solvency.

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 31

 Ownership structure and exercise of control rights

A key factor in a customer decision to engage a corporation is the confidence that expectations will be met. For cloud services, the interdependencies among multiple services make it more difficult for a customer to sort out the responsible party. If that results in less confidence in a particular vendor, then further engagement with that vendor is less likely. If this becomes a systemic feature, the loss of confidence in one actor will rollover to others, and the market failure will increase the likelihood of both external action and alternative participants.

Stakeholders should carefully consider the monitoring mechanisms that are appropriate and necessary for the company’s consistent performance and growth.

2.2 Enterprise Risk Management

Enterprise risk management (ERM) is rooted in the commitment by every organization to provide value for its stakeholders. All businesses face uncertainty and one of management’s challenges is to determine how one organization can measure, manage, and mitigate that uncertainty. Uncertainty presents both opportunity and risk with potential to increase or decrease the value of the organization and its strategies.

Information risk management is the process of identifying and understanding exposure to risk and capability of managing it, aligned with the risk appetite and tolerance of the data owner. Hence, it is the primary means of decision support for IT resources dedicated to delivering the confidentiality, integrity, and availability of information assets.

Enterprise risk management in business includes the methods and processes used by organizations to manage risks and seize opportunities related to the achievement of their objectives. In a cloud environment, management selects a risk response strategy for specific risks identified and analyzed, which may include:

 Avoidance—exiting the activities giving rise to risk

 Reduction—taking action to reduce the likelihood or impact related to the risk

 Share or insure—transferring or sharing a portion of the risk to finance it

 Accept—no action is taken due to a cost/benefit decision

Risk management is naturally a balancing process with the goal not necessarily to minimize uncertainty or variation, but rather the goal of maximizing value in line with risk appetite and strategy.

There are many variables, values, and risk in any cloud opportunity or program that affect the decision whether a cloud service should be adopted from a risk or business value standpoint. Each enterprise has to weigh those variables to decide whether the cloud is an appropriate solution.

Cloud computing offers enterprises many possible benefits, some of these benefits include:

 Optimized resource utilization

This section maps to the Cloud Control Matrix Controls DG-08 and the use of ISO31000, ISF and ISACA guidelines to establish solvency.

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 32

 Cost savings for cloud computing tenants

 Transitioning of capital expenses

 (CAPEX) to operating expenses (OPEX)

 Dynamic scalability of IT power for clients

 Shortened life cycle development of new applications or deployments

 Shortened time requirements for new business implementation

Customers should view cloud services and security as supply chain security issues. This means examining and assessing the provider’s supply chain (service provider relationships and dependencies) to the extent possible. This also means examining the provider’s own third party management. Assessment of third party service providers should specifically target the provider’s incident management, business continuity and disaster recovery policies, and processes and procedures; and should include review of co-location and back-up facilities. This should include review of the provider’s internal assessments of conformance to its own policies and procedures and assessment of the provider’s metrics to provide reasonable information regarding the performance and effectiveness of its controls in these areas. Incident information can be specified in contracts, SLAs, or other joint agreements, and can be communicated automatically or periodically, directly into reporting systems or delivered to key personnel. The level of attention and scrutiny should be connected to the value at risk – if the third party will not directly access enterprise data, then the level of risk drops significantly and vice versa.

Customers should review the risk management processes and governance of their providers, and ensure that practices are consistent and aligned.

2.3 Permissions

Permissions

 Adopt an established risk framework for monitoring and measuring corporate risk

 Adopt metrics to measure risk management performance (e.g., Security Content Automation Protocol (SCAP) 13, Cybersecurity Information Exchange Framework (CYBEX)14, or GRC-XML15).

 Adopt a risk centric viewpoint of corporate governance with senior management taking the role of trustee for both the shareholders and the stakeholders in the supply chain.

 Adopt a framework from legal perspective to account for differences across jurisdictions.

13 SCAP - Security Content Automation Protocol 14 CYBEX - Cybersecurity Information Exchange Framework 15 GRC-XML - technology standards to enable and enhance the sharing of information between various technologies that support GRC efforts

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 33

2.4 Recommendations

o Reinvest the cost savings obtained by cloud computing services into increased scrutiny of the security capabilities of the provider, application of security controls, and ongoing detailed assessments and audits to ensure requirements are continuously met.

o User organizations should include review of specific information security governance structure and processes, as well as specific security controls, as part of their due diligence for prospective provider organizations. The provider’s security governance processes and capabilities should be assessed for sufficiency, maturity, and consistency with the user’s information security management processes. The provider’s information security controls should be demonstrably risk-based and clearly support these management processes.

o Collaborative governance structures and processes between customers and providers should be identified as necessary, both as part of the design and development of service delivery, and as service risk assessment and risk management protocols, and then incorporated into service agreements.

o Security departments should be engaged during the establishment of Service Level Agreements (SLA’s) 16 and contractual obligations to ensure that security requirements are contractually enforceable.

o Metrics and standards for measuring performance and effectiveness of information security management should be established prior to moving into the cloud. At a minimum, organizations should understand and document their current metrics and how they will change when operations are moved into the cloud and where a provider may use different (potentially incompatible) metrics.

o Due to the lack of physical control over infrastructure by customers, in many Cloud Computing deployments, SLA’s, contract requirements, and provider documentation play a larger role in risk management than with traditional, enterprise owned infrastructure.

o Due to the on-demand provisioning and multi-tenant aspects of cloud computing, traditional forms of audit and assessment may not be available or may be modified. For example, some providers restrict vulnerability assessments and penetration testing, while others limit availability of audit logs and activity monitoring. If these are required per your internal policies, you may need to seek alternative assessment options, specific contractual exceptions, or an alternative provider better aligned with your risk management requirements.

o If the services provided in the cloud are essential to corporate operations a risk management approach should include identification and valuation of assets, identification and analysis of threats and vulnerabilities and their potential impact on assets (risk and incident scenarios), analysis of the likelihoods of events/scenarios, management-approved risk acceptance levels and criteria, and the development of risk treatment plans with multiple options (control, avoid, transfer, accept). The outcomes of risk treatment plans should be incorporated into service agreements.

o Risk assessment approaches between provider and user should be consistent with consistency in impact analysis criteria and definition of likelihood. The user and provider should jointly develop risk scenarios for the cloud service; this should be intrinsic to the provider’s design of service for the user, and to the user’s assessment of cloud service risk.

16 SLA - Service Level Agreement

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 34

o Due to the evolving nature of cloud and its providers, care should be taken to include vendor risk, e.g., business survivability of providers, portability of data and applications, and interoperability of services.

o Asset inventories should account for assets supporting cloud services and under the control of the provider. Asset classification and valuation schemes should be consistent between user and provider.

o The service, and not just the vendor, should be the subject of risk assessment. The use of cloud services, and the particular service and deployment models to be utilized, should be consistent with the risk management objectives of the organization, as well as with its business objectives.

o Cloud Computing service customers and providers should develop robust information security governance, regardless of the service or deployment model. Information security governance should be collaboration between customers and providers to achieve agreed-upon goals that support the business mission and information security program. Governance should include periodic review, and the service model may adjust the defined roles and responsibilities in collaborative information security governance and risk management (based on the respective scope of control for user and provider), while the deployment model may define accountability and expectations (based on risk assessment).

o Customers of cloud services should ask whether their own management has defined risk tolerances with respect to cloud services and accepted any residual risk of utilizing cloud services.

o Where a provider cannot demonstrate comprehensive and effective risk management processes in association with its services, customers should carefully evaluate use of the vendor as well as the user’s own abilities to compensate for the potential risk management gaps.

o Organizations should define risk metrics for engaging providers based on business and technical exposures. These metrics could include the type of data covered, the variety of user types relating to the information, and the vendors and other counterparties involved.

2.5 Requirements

 Provide transparency to stakeholders and shareholders demonstrating fiscal solvency and organizational transparency.

 Respect the interdependency of the risks inherent in the cloud supply chain and communicate the corporate risk posture and readiness to consumers and dependant parties.

 Inspect and account for risks inherited from other members of the cloud supply chain and take active measures to mitigate and contain risks through operational resiliency.

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 35

DOMAIN 3 // LEGAL ISSUES: CONTRACTS AND ELECTRONIC DISCOVERY

This domain highlights some of the legal aspects raised by cloud computing. It provides general background on legal issues that can be raised by moving data to the cloud, some issues for consideration in a cloud services agreement, and the special issues presented by electronic discovery under Western litigation.

This domain provides an overview of selected issues and it is not a substitute for obtaining legal advice.

Overview. This domain will address the following topics:

 Summary of specific legal issues raised by moving data to the cloud  Considerations for a cloud services agreement  Special issues raised by e-discovery

3.1 Legal Issues

In many countries throughout the world, numerous laws, regulations, and other mandates require public and private organizations to protect the privacy of personal data and the security of information and computer systems. For example, in the Asia Pacific region, Japan, Australia, New Zealand, and many others have adopted data protection laws that require the data controller to adopt reasonable technical, physical, and administrative measures in order to protect personal data from loss, misuse, or alteration, based on the Privacy and Security Guidelines of the Organization for Economic Cooperation and Development (OECD) 17, and the Asia Pacific Economic Cooperation’s (APEC)18 Privacy Framework.

In Europe, the European Economic Area (EEA)19 Member States have enacted data protection laws that follow the principles set forth in the 1995 European Union (EU) Data Protection Directive20 and the 2002 ePrivacy Directive (as amended in 2009). These laws include a security component, and the obligation to provide adequate security must be passed down to subcontractors. Other countries that have close ties with the EEA, such as Morocco and Tunisia in Africa, Israel and Dubai in the Middle East have also adopted similar laws that follow the same principles.

North, Central, and South America countries are also adopting data protection laws at a rapid pace. Each of these laws includes a security requirement and places on the data custodian the burden of ensuring the protection and security of personal data wherever the data are located, and especially when transferring to a third party. For example, in addition to the data protection laws of Canada, Argentina and Colombia, which have been in existence for several years, Mexico, Uruguay, and Peru have recently passed data protection laws that are inspired mainly from the European model and may include references to the APEC Privacy Framework as well.

17 OECD - Organization for Economic Cooperation and Development 18 APEC - Asia Pacific Economic Cooperation 19 EEA - European Economic Area 20 EU Directive 95/46/EC

SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0

©2011 CLOUD SECURITY ALLIANCE | 36

In Japan, the Personal Information Protection Act requires the private sectors to protect personal information and data securely. In the healthcare industry, profession-specific laws, such as the Medical Practitioners' Act, the Act on Public Health Nurses, Midwives and Nurses, and the Pharmacist Act, require registered health professionals for confidentiality of patient information.

Organizations that do business in the United States may be subject to one or more data protection laws. The laws hold organizations responsible for the acts of their subcontractors. For example, the security and privacy rules under the Gramm-Leach-Bliley Act (GLBA) 21 or the Health Insurance Portability and Accountability Act of 1996 (HIPAA) require that organizations compel their subcontractors, in written contracts, to use reasonable security measures and comply with data privacy provisions. Government agencies, such as the Federal Trade Commission (FTC) or the State Attorneys General have consistently held organizations liable for the activities of their subcontractors. The Payment Card Industry (PCI) Data Security Standards (DSS), which apply to credit card data anywhere in the world, including data processed by subcontractors has similar requirements.

The following sections provide examples of legal issues that may arise in connection with the transfer of personal data to the cloud or the processing of personal data in the cloud.

Table 1 — Obligatory Predicates

ISSUE DESCRIPTION

U.S. Federal Laws

Numerous federal laws and their related regulations, such as GLBA, HIPAA, Children’s Online Privacy Protection Act of 1998 (“COPPA”), together with orders issued by the FTC, require companies to adopt specific privacy and security measures when processing data, to require similar precautions in their contracts with the third party service provider.