Security Considerations Cloud Computing WHP Eng 0912

1
2 Security Considerations for Cloud Computing
About ISACA®
With more than 100,000 constituents in 180 countries, ISACA (www.isaca.org) is a leading global
provider of knowledge, certifications, community, advocacy and education on information systems
(IS) assurance and security, enterprise governance and management of IT, and IT-related risk and
compliance. Founded in 1969, the nonprofit, independent ISACA hosts international conferences,
publishes the ISACA® Journal, and develops international IS auditing and control standards,
which help its constituents ensure trust in, and value from, information systems. It also advances
and attests IT skills and knowledge through the globally respected Certified Information Systems
Auditor® (CISA®), Certified Information Security Manager® (CISM®), Certified in the Governance
of Enterprise IT® (CGEIT®) and Certified in Risk and Information Systems ControlTM (CRISCTM)
designations.
ISACA continually updates and expands the practical guidance and product family based on the
COBIT® framework. COBIT helps IT professionals and enterprise leaders fulfill their IT governance
and management responsibilities, particularly in the areas of assurance, security, risk and control, and
deliver value to the business.
Disclaimer
ISACA has designed and created Security Considerations for Cloud Computing (the “Work”)
primarily as an educational resource for governance and assurance professionals. ISACA makes
no claim that use of any of the Work will assure a successful outcome. The Work should not
be considered inclusive of all proper information, procedures and tests or exclusive of other
information, procedures and tests that are reasonably directed to obtaining the same results. In
determining the propriety of any specific information, procedure or test, governance and assurance
professionals should apply their own professional judgment to the specific circumstances presented
by the particular systems or information technology environment.
Reservation of Rights
© 2012 ISACA. All rights reserved. No part of this publication may be used, copied, reproduced,
modified, distributed, displayed, stored in a retrieval system or transmitted in any form by any
means (electronic, mechanical, photocopying, recording or otherwise) without the prior written
authorization of ISACA. Reproduction and use of all or portions of this publication are permitted
solely for academic, internal and noncommercial use and for consulting/advisory engagements, and
must include full attribution of the material’s source. No other right or permission is granted with
respect to this work.
ISACA
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Phone: +1.847.253.1545
Fax: +1.847.253.1443
Email: info@isaca.org
Web site: www.isaca.org
Feedback: www.isaca.org/cloud-security
Participate in the ISACA Knowledge Center: www.isaca.org/knowledge-center
Follow ISACA on Twitter: https://twitter.com/ISACANews
Join ISACA on LinkedIn: ISACA (Official), http://linkd.in/ISACAOfficial
Like ISACA on Facebook: www.facebook.com/ISACAHQ
ISBN 978-60420-263-2
Security Considerations for Cloud Computing
Acknowledgments 3
Acknowledgments
ISACA wishes to recognize:
Development Team
Stefanie Grijp, PwC, Belgium
Chris Kappler, PwC, Belgium
Bart Peeters, CISA, PwC, Belgium
Tomas Clemente Sanchez, PwC, Belgium
Work Group
Yves Marcel Le Roux, CISM, CISSP, CA Technologies, France
Alan Mayer, USA
Perry Menezes, CISM, CRISC, CIPP, CISSP, Deutsche Bank, USA
Yogendra Rajput, India
Paras Shah, CISA, CGEIT, CRISC, CA, Transpire Pty Ltd., Australia
Brett Smith, CISSP, ISSAP, Deutsche Bank, USA
Expert Reviewers
Muhammad Amir, CISA, CISM, CRISC, CEH, CISSP, MCSE Security, Security+,
NetSol Technologies Ltd., Pakistan
Mark E.S. Bernard, CISA, CSIM, CGEIT, CRISC, CISSP, PM, ISO 27001, SABSA-F2,
TechSecure Holdings Inc., Canada
Roberta Donaldson Caraglia, EMCIS, ITIL V3, EMC Consulting, USA
Christos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., Greece
Meenu Gupta, CISA, CISM, CBP, CIPP, CISPP, Mittal Technologies, USA
Masatoshi Kajimoto, CISA, CRISC, Independent Consultant, Japan
Hesham Moussa, CISM, Lumension Security, USA
Jo Stewart-Rattray, CISA, CISM, CGEIT, CRISC, CSEPS, RSM Bird Cameron, Australia
Lou Tinto, CISA, CRISC, CFE, CIA, NYLB, USA
Sukhwinder Wadhwa, ITIL V3, Infosys Ltd, India
Justin Williams, CA (SA), Transnet, South Africa
ISACA Board of Directors

Gregory T. Grocholski, CISA, The Dow Chemical Co., USA, International President
Allan Boardman, CISA, CISM, CGEIT, CRISC, ACA, CA (SA), CISSP, Morgan Stanley, UK,
Vice President
Juan Luis Carselle, CISA, CGEIT, CRISC, Wal-Mart, Mexico, Vice President
Christos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., Greece, Vice President
Ramses Gallego, CISM, CGEIT, CCSK, CISSP, SCPM, 6 Sigma, Quest Software, Spain,
Vice President
Tony Hayes, CGEIT, AFCHSE, CHE, FACS, FCPA, FIIA, Queensland Government, Australia,
Vice President
Jeff Spivey, CRISC, CPP, PSP, Security Risk Management Inc., USA, Vice President
Marc Vael, Ph.D., CISA, CISM, CGEIT, CRISC, CISSP, Valuendo, Belgium, Vice President
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Past International President
Emil D’Angelo, CISA, CISM, Bank of Tokyo-Mitsubishi UFJ Ltd., (retired), USA,
Past International President
John Ho Chi, CISA, CISM, CRISC, CBCP, CFE, Ernst & Young LLP, Singapore, Director
Krysten McCabe, CISA, The Home Depot, USA, Director
Jo Stewart-Rattray, CISA, CISM, CGEIT, CRISC, CSEPS, RSM Bird Cameron, Australia, Director
Knowledge Board
Marc Vael, Ph.D., CISA, CISM, CGEIT, CRISC, CISSP, Valuendo, Belgium, Chairman
Steven A. Babb, CGEIT, CRISC, Betfair, UK
Thomas E. Borton, CISA, CISM, CRISC, CISSP, Cost Plus, USA
Phillip J. Lageschulte, CGEIT, CPA, KPMG LLP, USA
Salomon Rico, CISA, CISM, CGEIT, Deloitte, Mexico
Steven E. Sizemore, CISA, CIA, CGAP, Texas Health and Human Services Commission, USA
Acknowledgments (cont.)
Guidance and Practices Committee
Phillip J. Lageschulte, CGEIT, CPA, KPMG LLP, USA, Chairman
Dan Haley, CISA, CGEIT, CRISC, MCP, Johnson & Johnson, USA
Yves Marcel Le Roux, CISM, CISSP, CA Technologies, France
Aureo Monteiro Tavares Da Silva, CISM, CGEIT, Pelissari, Brazil
Jotham Nyamari, CISA, Deloitte, USA
Connie Lynn Spinelli, CISA, CRISC, CFE, CGMA, CIA, CISSP, CMA, CPA, GRC Solutions LLC, USA
John William Walker, CISM, CRISC, FBCS CITP, ITPC Secure Bastion Limited, UK
Siang Jun Julia Yeo, CISA, CPA (Australia), Visa Worldwide Pte. Limited, Singapore
Nikolaos Zacharopoulos, CISA, CISSP, DeutschePost–DHL, Germany
ISACA and IT Governance Institute® (ITGI®) Affiliates and Sponsors

Information Security Forum
Institute of Management Accountants Inc.
ISACA chapters
ITGI France
ITGI Japan
Norwich University
Socitum Performance Management Group
Solvay Brussels School of Economics and Management
Strategic Technology Management Institute (STMI) of the National University of Singapore
University of Antwerp Management School
ASIS International
Hewlett-Packard
IBM
Symantec Corp.
TruArx Inc.
Table of Contents 5
Table of Contents
1. Introduction................................................................................................................. 7
Background.................................................................................................................... 7
Purpose of This Document........................................................................................... 7
Who Should Use This Guide?..................................................................................... 7
Scope and Approach..................................................................................................... 7
2. Cloud Computing........................................................................................................ 9
Essential Characteristics............................................................................................... 9
Cloud Service Models.................................................................................................. 9
Cloud Deployment Models........................................................................................ 10
The Key Element of Trust.......................................................................................... 10
3. Overview of Security Risk and Threats Related to

Operating in the Cloud............................................................................................ 13
Visibility as a Critical Factor..................................................................................... 13
Information Assets and Risk...................................................................................... 14
Cost Considerations (or Cost as a Risk Event)................................................. 15
Privacy Considerations...................................................................................... 15
Risk Assessment When Migrating to the Cloud............................................... 16
Risk Factors by Service Model.................................................................................. 17
S1. IaaS.............................................................................................................. 17
S2. PaaS............................................................................................................. 19
S3. SaaS............................................................................................................. 20
Risk Factors by Deployment Model.......................................................................... 21
D1. Public Cloud............................................................................................... 22
D2. Community Cloud...................................................................................... 22
D3. Private Cloud.............................................................................................. 23
D4. Hybrid Cloud.............................................................................................. 24
Overview of Threats and Mitigating Actions........................................................... 24
Technical........................................................................................................... 25
Regulatory ......................................................................................................... 29
Information Security Governance..................................................................... 30
4. The Path to the Decision and Beyond................................................................... 35

Step 1. Preparation of the Internal Environment...................................................... 35
Step 2. Selection of the Cloud Service Model......................................................... 36
Breakdown of Cloud Service Model Decision Tree......................................... 38
Step 3. Selection of the Cloud Deployment Model................................................. 40
Breakdown of Cloud Deployment Decision Tree............................................. 42
Step 4. Selection of the Cloud Service Provider...................................................... 51
Appendix A. The Path to the Decision and Beyond—Checklist.......................... 53
Appendix B. O
verview of Different Risk Factors per Service
and Deployment Model ....................................................................... 55
Appendix C. M
apping Threats and Mitigating Actions to
COBIT 5 for Information Security...................................................... 65
Abbreviations................................................................................................................. 77
References....................................................................................................................... 79
1. Introduction 7
1. Introduction
Background
In recent years cloud computing has become more than a just another IT buzzword.
It refers to a business trend that is expected to have—and for some enterprises
already has—a significant impact on the way enterprises operate. It is likely that
cloud computing will gain even more importance as both the cloud and cloud
service provider markets mature. In times of cost optimization and economic
downturn the cloud can be perceived as a way to realize a more cost-effective
approach to technological support of the enterprise. However, security and data
privacy concerns are frequently seen as critical issues or even barriers for adopting
cloud computing services.
Purpose of This Document
This publication is not intended to provide yet another detailed, theoretical

description of the concept of “cloud” and the different alternatives of cloud
computing. Instead, it is designed to present practical guidance and facilitate the
decision process for IT and business professionals concerning the decision to move
to the cloud. This guide aims to enable effective analysis and measurement of risk
using items such as decision trees and checklists outlining the security factors to be
considered when evaluating the cloud as a potential solution.
Who Should Use This Guide?
Just as cloud computing is about more than just IT infrastructures, platforms and
applications, the decision to operate in the cloud should not be taken solely by IT
organizations. The use of cloud services might entail high risk for the business
and should therefore be evaluated by responsible parties from the different control
functions within an enterprise. This guide is meant for all current and potential
cloud users who need to ensure protection of information assets.
Scope and Approach
This publication provides practical guidance regarding the decision process

surrounding the adoption of cloud services. This requires a short theoretical
description of cloud concepts before presenting the most common risk areas and
threats in the cloud landscape. This guide also provides an approach to cope with
these risk areas and threats. (To avoid scope creep, this publication’s discussion of
risk and threats is limited to cloud-specific elements.)
Consequently, this guide is structured as follows:

• Chapter 2—Cloud computing in a nutshell: What is cloud computing and how
can it be implemented? This section provides a short description of the different
service and deployment models used in cloud operations.
• Chapter 3—Overview of security risk and threats related to operating in the cloud,
structured by service and deployment model
• Chapter 4—The path to the decision and beyond: guidance on how to evaluate
the cloud as a potential solution by means of practical tools (decision trees
and checklists)
2. Cloud Computing 9
2. Cloud Computing
Cloud computing is defined by the US National Institute of Standards and
Technology (NIST) as “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) that can be rapidly provisioned and
released with minimal management effort or service provider interaction.”1
There are five essential characteristics, three types of service models and four major
deployment models to be taken into account relative to cloud computing. To ensure
a common understanding of these models, the characteristics of each are described
in the following sections.
Essential Characteristics
The essential characteristics of cloud computing are:

• On-demand self-service—Computing capabilities can be provisioned without
human interaction from the service provider.
• Broad network access—Computing capabilities are available over the network
and can be accessed by diverse client platforms.
• Resource pooling—Computer resources are pooled to support a multitenant model.
• Rapid elasticity—Resources can scale up or down rapidly and in some cases
automatically in response to business demands.
• Measured service—Resource utilization can be optimized by leveraging
charge-per-use capabilities.
Cloud Service Models

There are three main service models and each represents a different level of
involvement of an outsourcing partner or cloud service provider (CSP):
• Infrastructure as a Service (IaaS)—In an IaaS solution, the CSP provides cloud
users with processing, storage, networks and other fundamental computing resources.
Operating systems and applications, however, are the responsibility of the user and
are not included in the service offering of the CSP. Examples are: Rackspace®,
Equinix®, Softlayer®, iomart Group plc, Amazon Web Services LLC, etc.
• Platforms as a Service (PaaS)—PaaS entails the CSP making available
infrastructures and platforms on which cloud users deploy their own applications.
This requires the CSP to support programming languages, libraries, services
and tools. Examples are: Google App EngineTM, Microsoft® Windows AzureTM,
Heroku, OpenShift, Amazon Web Services LLC, etc.
• Software as a Service (SaaS)—When opting for SaaS, cloud users not only
hire infrastructure and platforms from the CSP, but also run CSP-provided
applications on them. Examples are: Computer Services Inc., Salesforce, New
Relic®, Logicworks, Apptix®, Google App Engine, Microsoft Windows Azure,
Amazon Web Services LLC, etc.
1
ell, Peter; Timothy Grance; The NIST Definition of Cloud Computing, US National Institute of
M
Standards and Technology (NIST) Special Publication (SP) 800-145, USA, 2011
In each of these models, cloud users do not own, operate or control the underlying
cloud infrastructure. They may, however, have (limited) control over operating
systems and applications.
Cloud Deployment Models
The cloud is most often deployed in one of three models—also frequently referred
to as cloud structures:
• Public cloud—The infrastructure is made available to the general public (e.g.,
Google Apps, Amazon Elastic Compute Cloud (EC2TM), Apple® iCloud). It is
deployed within the CSP infrastructure, offsite to the enterprise infrastructure.
• Community cloud—The cloud infrastructure is provisioned for exclusive use
by a specific community of consumers from enterprises or interest groups (e.g.,
vertical industries, schools, researchers, software developers) that have shared
concerns. It can be deployed onsite (within the enterprise infrastructure) or offsite
(within the CSP infrastructure, also called “outsourced”).
• Private cloud—The infrastructure can be used only by one single enterprise. As
for community clouds, it can be deployed onsite or offsite enterprise premises.
• Hybrid cloud—The cloud infrastructure is a composition of two or more distinct
cloud infrastructures (private, community or public) that remain unique entities.
The Key Element of Trust
Security and data privacy concerns are typically seen as critical barriers to the
adoption of cloud services. To mitigate identified risk, cloud users can opt to set in
place service level agreements (SLAs) or they can ask cloud service providers to
meet certain control objectives. In the end, however, the discussion comes down
to the key element of trust, which is a major component in the cloud computing
business model. There can never be sufficient controls and agreements to mitigate
all concerns if trust is a missing factor in the client-supplier relationship.
Therefore, in considering cloud adoption, it is important to know all the parties

involved and their physical locations. The parties involved are not limited to
the CSP and its employees, but also include all vendors that are in close contact
with the cloud service provider and that may come in contact with user data. It
is important to ensure that they are trustworthy (e.g., they are not involved in
fraudulent activities, they are economically solvent). A good rule of thumb is to
select CSPs that have significant history in the cloud services industry and can
provide solid business references.
2. Cloud Computing 11
The answer to the question “How can I rely on a CSP to protect my data?” will be
influenced by a number of aspects:
• The possibility for auditing and the verification of controls. Does the cloud user
have a view of the CSP’s mitigating controls to handle risk—controls related to
security, availability, processing integrity, confidentiality and privacy? In this
context, several standards or best practices are available for CSPs to report on
their security status. The American Institute of Certified Public Accountants
(AICPA) SOC 2 report or any security certification (International Organization
for Standardization [ISO 2700x]) can be used to evaluate the security practices
of a possible CSP. Guidance on how to fully understand and use AICPA SOC
2 reports can be found in ISACA’s SOC 2SM User Guide, scheduled to be
available by the end of September 2012. The enterprise must identify compliance
requirements or select a recognized security framework (e.g., ISO, Statements on
Standards for Attestation Agreements [SSAE] 16, Payment Card Industry Data
Security Standard [PCI DSS], Health Insurance Portability and Accountability Act
[HIPAA], US Sarbanes-OxleyAct [SOX]) and request proof of compliance from
the CSP.
• The CSP financial position and market recognition
• Is the CSP certified or recognized by one or more security standards authorities
(e.g., the National Information Assurance Partnership [NIAP], which is a
US government body operated by the National Security Agency [NSA], and NIST)?
• The availability of business continuity plans (BCPs), disaster recovery plans
(DRPs) and robust backup procedures, taking into account multifacility,
multicountry CSPs
• The quality of the user’s own data and data classification; policies, principles and
frameworks; processes; organizational structures; culture, ethics and behaviour;
services, infrastructure and applications; people, skills and competencies; and risk
appetite (see chapter 4)
• General negotiations and relationship with the service provider: contracts, SLAs,
communication processes, roles and responsibilities matrices, etc.
Page intentionally left blank

3. Overview of Security Risk and Threats 13
Related to Operating in the Cloud
3. Overview of Security Risk and Threats

Recent publications and media coverage have discussed the extensive benefits of
migrating to the cloud: better management and allocation of IT physical resources,
flexibility, high scalability, elasticity and cost savings. However, changing from one
environment to another entails some disadvantages as well, e.g., in the form of new
risk or new threats. Enterprises that are considering moving to the cloud must be
aware of the risk and threats involved to decide whether the cloud is an appropriate
solution and which service and deployment models entail a degree of risk that they
can manage and are willing to accept.
Once the enterprise is aware of the risk and threats, it can implement a series of
mitigating actions and controls to reduce or eliminate the threats related to the
service and delivery model it has chosen and to ensure that the benefits of moving
to the cloud are realized as expected.
Visibility as a Critical Factor
The decision to move to the cloud implies that the information assets of the
enterprise will be “managed” by the CSP. However, the enterprise—the owner
of the assets—is likely to have little knowledge or “visibility” into the people,
processes and technology supporting its information assets. The lack of visibility
is also known as “abstraction;” to counter the effects the CSP should provide to
customers full details on how its assets are managed.
The level of abstraction or visibility provided by the CSP becomes extremely

important when evaluating risk. In fact, each service model corresponds to an
abstraction level based on the number of layers in the Internet Protocol (IP) stack
being replaced by the cloud. For this reason, IaaS represents the lowest abstraction
level (infrastructure only) and SaaS the highest (application + middleware +
infrastructure).
The higher the abstraction level, the higher the risk or the number of threats to take
into account because risk is cumulative (figure 1). However, CSPs often offer only
visibility into the cloud stack corresponding to the service model chosen. Security
professionals must be aware of this factor when evaluating a move to the cloud. A
common mistake is to assume that SaaS will not also be subject to risk related to
infrastructure; however, risk and threats are there. They are on a layer that is less
visible because it is no longer under the operational responsibility of the enterprise,
but is under that of the CSP.
Figure 1—Cloud Service Models

Data and Application
Security Risk
Per SLA
SaaS
Software as a Service
Client Assumes Presentation Presentation
Modality Platform
All Data and Application
APIs
Security Risk
Applications
PaaS
Data Metadata Content
Platform as a Service
IaaS
Infrastructure as a Service Integration and Middleware Integration and Middleware
APIs APIs APIs

Infrastructure as a Service (IaaS)
Software as a Service (SaaS)

Platform as a Service (PaaS)
Platform as a Service (PaaS)

Core Connectivity Core Connectivity Core Connectivity
and Delivery and Delivery and Delivery
Abstraction Abstraction Abstraction
Hardware Hardware Hardware
Facilities Facilities Facilities
Source: Universal Model, © Cloud Security Alliance. Used with permission.
Information Assets and Risk
The first question to ask when evaluating cloud-related risk is: “Which information
assets are we considering moving to the cloud?”
Information assets can be roughly categorized as data, applications and processes.

These assets are commonly subject to the following risk events:2
• Unavailability—The asset is unavailable and cannot be used or accessed by the
enterprise. The cause can be accidental (failure of the infrastructure), intentional
(distributed denial-of-service [DDoS] attacks) or legal (subpoena of database
holding all data in a case of multitenancy architecture where one client’s data are
subject to legal investigation).
• Loss—The asset is lost or destroyed. The cause can be accidental (natural disaster,
wrong manipulation, etc.) or intentional (deliberate destruction of data).
• Theft—The asset has been intentionally stolen and is now in possession of another
individual/enterprise. Theft is a deliberate action that can involve data loss.
• Disclosure—The asset has been released to unauthorized staff/enterprises/
organizations or to the public. Disclosure can be accidental or deliberate. This
also includes the undesired, but legal, access to data due to different regulations
across international borders.
Data are commonly the most valuable assets and the most probable targets of
attacks in the cloud. However, it is important not to overlook the risk related to
applications and processes. The business impact of long DDoS attacks cannot
always be absorbed by an enterprise; although no data loss or disclosure is suffered,
2
I SACA’s Risk IT framework considers the following risk events: interruption, destruction, theft and
disclosure. However, the terms “unavailability” (interruption) and “loss” (destruction) are found to be
more suitable for the assets presented in this context.
paralyzing the systems has direct, negative effects on the data. Disclosure of details
about how applications handle critical information or about internal enterprise
processes could pave the way to more selective attacks with greater consequences.
Figure 2 explains at a high level the possible impact of the four risk events on assets.
Figure 2—Impact of Risk Events on Assets

Type Unavailability Loss Theft Disclosure
Data Disruption of Disruption of Business Damage to
activities; lack of activities; required competitive company
resources to keep activation of disadvantage; reputation or
on with “business backup restore possibility of image; possibility
as usual;” procedures (DRP); blackmail; loss of regulatory
possibility of data possibility of partial of credibility with sanctions;
poisoning loss of the asset customers/clients financial impact
(depending on
Applications/ Disruption of Higher risk/threat of more selective
the recovery point
processes activities; lack of attacks to data
objective [RPO]);
resources to keep
financial loss
on with “business
associated with
as usual”
recovery efforts
Cost Considerations (or Cost as a Risk Event)

Cost-benefit financial analysis is an additional factor to consider when evaluating
risk-related impacts of the cloud on enterprise assets. Technically speaking, cost is
not generally considered to be a risk to our information assets, but it can trigger one
or more of the risk events mentioned (unavailability, loss, theft or disclosure).
Consider the following case: an enterprise that neglects the cost impact of a
migration to a CSP can see its information assets seized by the CSP if proper
payment is not made. In this case, the asset could be effectively lost to the
enterprise, and possibly disclosed, although there is no technical reason or a
technical countermeasure to prevent it.
It is not the purpose of this document to explain financial analysis and risk.
However, as described, other technical risk areas can be triggered due to cost
considerations. Therefore, in some specific cases described in the document,
cost will be included as a risk event (in addition to unavailability, loss, theft
and disclosure).
Privacy Considerations
Privacy is one of the most common concerns when considering a move to the
cloud. In most cases, this concern arises when an information asset is composed
of personal or extremely sensitive data. There is, however, another component
to consider besides the content of the information asset: the difference between
privacy of data within the information asset and privacy of data outside the
information asset.
For example, an enterprise that has migrated to a CSP possesses a database of

customers and sends emails to these customers to advertise new products. Both
the database and the email content are considered sensitive information assets that
must be kept private, and have appropriate measures (encryption, e-signatures,
data access management, etc.) to protect them. However, the CSP (or an intruder)
can use the network logs to trace the destination of the emails and can, therefore,
rebuild the database, thus compromising asset privacy.
In the first case (privacy of data within information assets), the primary concern is
to ensure that the information asset is not disclosed. Such assets should be identified
through proper data classification prior to migration and should then be protected against
disclosure. (Factors that increase the risk of disclosure within cloud infrastructures and
appropriate prevention measures are explained later in this chapter.)
The second case (privacy of data outside information assets) is more complex because
it involves the collection, retention and processing of data that are not part of the
information assets of the enterprise. Such data are often collected by service providers
for benign purposes (like troubleshooting and incident analysis) or for legal reasons
(data retention policies, for example) so it can be very difficult to prevent disclosure
or theft. Often it is unavoidable; however, this specific problem is not particular to
CSPs as it can apply to any infrastructure that is not entirely under control of the
enterprise. Therefore, it is not discussed in detail in this publication.
Risk Assessment When Migrating to the Cloud

The chief information security officer (CISO) or the information security manager
(ISM) is responsible for being aware of the current risk affecting the assets of
the enterprise and for understanding how the migration to the cloud will affect
those assets and the current level of risk. In absence of a CISO or ISM, this is the
responsibility of a similar control organization/function within the enterprise.
The impact of a migration to the cloud depends on the cloud service model and
deployment model being considered. The combination of service model and
deployment model can help identify an appropriate balance for organizational assets
(e.g., choosing a private cloud deployment model can help balance the risk related
to multitenancy). In the previous section entitled, Information Assets and Risk, the
possible risk affecting information assets (unavailability, theft, loss and disclosure) were
enumerated. Following is a discussion of risk-decreasing and risk-increasing factors by
service model. These risk factors will then be linked to actual threats and mitigating
actions. (A table listing all risk factors can be found in the appendices section.)
As mentioned in chapter 1, the scope of this publication is to provide practical

guidance for the adoption of cloud computing. To facilitate a better understanding
of the issues specific to the cloud, common risk factors (increasing or decreasing)
that are not linked solely to cloud infrastructures, but apply to all types of
infrastructure, are not covered in this guide. Examples of such risk factors include
external hacking, malicious insiders, mobile computing vulnerabilities, virus and
malicious code and business impact due to provider inability.
Risk Factors by Service Model
S1. IaaS
With IaaS, the CSP provides the enterprise with fundamental computing
resources/equipment (storage, hardware, servers and network components) while the
enterprise remains in control of the operating system (OS) and applications installed.
Risk-decreasing factors:
S1.A Scalability and elasticity—Lack of physical resources is no longer an
issue. Due to the scalable nature of cloud technologies, the CSP can
provide capacity on demand at low cost to support peak loads (expected or
unexpected). Elasticity eliminates overprovisioning and underprovisioning
of IT resources, allowing better cost optimization. This becomes a great
advantage for resilience when defensive measures or resources need to be
expanded quickly (e.g., during DDoS attacks).
Risk affected—Unavailability
S1.B DRP and backup—CSPs should already have in place, as common practice,
disaster recovery and backup procedures. However, recovery point objective
(RPO), recovery time objective (RTO), and backup testing frequency and
procedures provided by the CSP should be consistent with the enterprise
security policy.
Risk affected—Unavailability, loss
S1.C Patch management—Cloud infrastructures are commonly based on
hypervisors and are controlled through a central hypervisor manager or
client. The hypervisor manager allows the necessary patches to be applied
across the infrastructure in a short time, reducing the time available for a new
vulnerability to be exploited.
Risk affected—Unavailability, loss, theft, disclosure
Risk-increasing factors:
S1.D Legal transborder requirements—CSPs are often transborder, and different
countries have different legal requirements, especially concerning personal
private information. The enterprise might be committing a violation of
regulations in other countries when storing, processing or transmitting data
within the CSP’s infrastructure without the necessary compliance controls.
Furthermore, government entities in the hosting country may require access
to the enterprise’s information with or without proper notification.
Risk affected—Disclosure
S1.E Multitenancy and isolation failure—One of the primary benefits of the
cloud is the ability to perform dynamic allocation of physical resources when
required. The most common approach is a multi-tenant environment (public
cloud), where different entities share a pool of resources, including storage,
hardware and network components. All resources allocated to a particular
tenant should be “isolated” and protected to avoid disclosure of information
to other tenants. For example, when allocated storage is no longer needed
by a client it can be freely reallocated to another enterprise. In that case,

sensitive data could be disclosed if the storage has not been scrubbed
thoroughly (e.g., using forensic software).
Risk affected—Theft, disclosure
S1.F Lack of visibility surrounding technical security measures in place—For any
infrastructure, intrusion detection systems (IDS)/intrusion prevention systems
(IPS) and security incident and event management (SIEM) capabilities must
be in place. It is the responsibility of the CSP to provide these capabilities to
its customers. To ensure that there are no security gaps, the security policy and
governance of the CSP should match those of the enterprise.
S1.G Absence of DRP and backup—The absence of a proper DRP or backup
procedures implies a high risk for any enterprise. CSPs should provide such
basic preventive measures aligned with the enterprise’s business needs (in
terms of RTO/RPO).
S1.H Physical security—In an IaaS model, physical computer resources are
shared with other entities in the cloud. If physical access to the CSP’s
infrastructure is granted to one entity, that entity could potentially access
information assets of other entities. The CSP is responsible for applying
physical security measures to protect assets against destruction or
unauthorized access.
S1.I Data disposal—Proper disposal of data is imperative to prevent
unauthorized disclosure. If appropriate measures are not taken by the CSP,
information assets could be sent (without approval) to countries where the
data can be legally disclosed due to different regulations concerning sensitive
data. Disks could be replaced, recycled or upgraded without proper cleaning
so that the information still remains within storage and can later be retrieved.
When a contract expires, CSPs should ensure the safe disposal or destruction
of any previous backups.
Risk affected—Disclosure
S1.J Offshoring infrastructure—Offshoring of key infrastructure expands the
attack surface area considerably. In practice this means that the information
assets in the cloud need to integrate back to other noncloud-based assets
within the boundaries of the enterprise. These communications (normally
done through border gateway devices) could be insecure, exposing both the
cloud and internal infrastructures.
S1.K Virtual machine (VM) security maintenance—IaaS providers allow
consumers to create VMs in various states (e.g., active, running, suspended
and off). Although the CSP could be involved, the maintenance of security
updates is generally the responsibility of the customer only. An inactive
VM could be easily overlooked and important security patches could be left
unapplied. This out-of-date VM could become compromised when activated.
Cloud provider authenticity—Although communications between the

S1.L
enterprise and the cloud provider can be secured with technical means
(encryption, virtual private network [VPN], mutual authentication, etc.) it is
the consumer’s responsibility to check the identity of the cloud provider to
ensure that it is not an imposter.
S2. PaaS
PaaS adds a layer to IaaS by providing the capability to deploy applications in
a cloud infrastructure. The applications are developed using the programming
languages and tools supported by the CSP. Thus, physical support, OS and
programming tools are the responsibility of the CSP, while the applications and the
data remain under the control of the enterprise. This service model entails the same
impacts on risk as IaaS, plus the following factors.
Risk-decreasing factor:
S2.A Short development time—Using the service oriented architecture (SOA)
library provided by the CSP, applications can be developed and tested within
a reduced time frame because SOA provides a common framework for
application development.
S2.B Application mapping—If current applications are not perfectly aligned with
the capabilities provided by the CSP, additional undesirable features (and
vulnerabilities) could be introduced.
S2.C SOA-related vulnerabilities—Security for SOA presents new challenges
because vulnerabilities arise not only from the individual elements, but
also from their mutual interaction. Because the SOA libraries are under the
responsibility of the CSP and are not completely visible to the enterprise,
there may exist unnoticed application vulnerabilities.
S2.D Application disposal—When applications are developed in a PaaS
environment, originals and backups should always be available. In the event
of a contract termination, the details of the application could be disclosed
and used to create more selective attacks on applications.
S3. SaaS
In a SaaS model, the CSP provides to the enterprise the capability to use
applications running on the cloud infrastructure. The enterprise, in turn, provides to
the CSP the data necessary to run the application. The physical infrastructure, OS,
applications and data are the responsibility of the CSP. The enterprise has only the
role of client/user. This service model entails the same impacts on risk as PaaS, plus
the following factors.
S3.A Improved security—CSPs depend on the good reputation of their software
capabilities to maintain their SaaS offering. Consequently, they introduce
additional features to improve the resilience of their software (e.g., security
testing or strict versioning) or to inform users about the exact state of their
business application (e.g., specific software logging and monitoring).
S3.B Application patch management—Due to the fact that the SaaS application
service is managed globally and only by the CSPs, application patch
management is more effective, allowing patches to be deployed in little time
with limited impact.
S3.C Data ownership—The CSP provides the applications and the customer
provides the data. If data ownership is not clearly defined, the CSP could
refuse access to data when required or even demand fees to return the data
once the service contracts are terminated.
Risk affected—Unavailability, loss, disclosure
S3.D Data disposal—In the event of a contract termination, the data fed into the
CSP’s application must be erased immediately using the necessary tools to
avoid disclosures and confidentiality breaches (forensic cleaning may be
required for sensitive data).
S3.E Lack of visibility into software systems development life cycle (SDLC)—
Enterprises that use cloud applications have little visibility into the software
SDLC. Customers do not know in detail how the applications were
developed and what security considerations were taken into account during
the SDLC. This could lead to an imbalance between the security provided by
the application and the security required by customers/users.
S3.F Identity and access management (IAM)—To maximize their revenues,
CSPs offer their services and applications to several customers concurrently.
Those customers share servers, applications and, eventually, data. If data
access is not properly managed by the CSP application, one customer could
obtain access to another customer’s data.
Risk affected—Loss, theft, disclosure
S3.G Exit strategy—Currently, there is very little available in terms of tools,

procedures or other offerings to facilitate data or service portability from
CSP to CSP. This can make it very difficult for the enterprise to migrate
from one CSP to another or to bring services back in-house. It can also result
in serious business disruption or failure should the CSP go bankrupt, face
legal action, or be the potential target for an acquisition (with the likelihood
of sudden changes in CSP policies and any agreements in place). If the
customer-CSP relationship goes sour and the enterprise wants to bring the
data back in-house, the question of how to securely render the data becomes
critical because the in-house applications may have been decommissioned or
“sunsetted” and there is no application available to render the data.
S3.H Broad exposure of applications—In a cloud environment, the applications
offered by the CSP have broader exposure which increases the attack space.
Additionally, it is quite common that those applications still need to integrate
back to other noncloud applications within the boundaries of the enterprise.
Standard network firewalls and access controls are sometimes insufficient to
protect the applications and their external interactions. Additional security
measures may be required.
Risk affected—Unavailability, loss, disclosure
S3.I Ease to contract SaaS—Business organizations may contract cloud
applications without proper procurement and approval oversight, thus
bypassing compliance with internal enterprise policies.
S3.J Lack of control of the release management process—As described before,
CSPs are able to introduce patches in their applications quickly. These
deployments are often done without the approval (or even the knowledge)
of the application users for practical reasons: if an application is used by
hundreds of different enterprises, it would take an extremely long time for
a CSP to look for the formal approval of every customer. In this case, the
enterprise could have no control (or no view) of the release management
process and could be subject to unexpected side effects.
S3.K Browser vulnerabilities—As a common practice, applications offered
by SaaS providers are accessible to customers via secure communication
through a web browser. Web browsers are a common target for malware
and attacks. If the customer’s browser becomes infected, the access to the
application can be compromised as well.
Risk Factors by Deployment Model
Cloud deployment models do not have the same abstraction as cloud service
models. That is, risk is not cumulative, but particular to each model. However,
“trust” among the different entities (CSP, customers, CSP’s third-party service
providers, etc.) is an important factor—not just trust between the CSP and the
customer, but enough trust in the other tenants sharing computing resources
hosting the enterprise’s information assets. If a user abuses the infrastructure and
services of the public cloud, the entire infrastructure might be at risk of failure,
theft or seizure (for forensics), including the services used by other enterprises. It
is important as part of the decision process to carefully consider which assets can
securely be hosted in a public cloud and which cannot.
D1. Public Cloud

In a public cloud, the CSP shares infrastructure and resources among various
unrelated enterprises and individuals.
D1.A Public reputation—Providers of public cloud services are aware that they are
generally perceived as more “risky.” It is critical for them to ensure a good
reputation as a secure provider or customers will simply move elsewhere.
D1.B Full sharing of the cloud (data pooling)—The cloud infrastructure is
shared by multiple tenants of the cloud service provider. These tenants have
no relation to the enterprise or other tenants in the same space, therefore no
common interest and concerns for security.
D1.C Collateral damage—If one tenant of a public cloud is attacked, there could
be an impact to the other tenants of the same CSP, even if they are not
the intended target (e.g., DDoS). Another possible scenario of collateral
damage could be a public cloud IaaS that is affected by an attack exploiting
vulnerabilities of software installed by one of the tenants.
D2. Community Cloud

In the community cloud, cloud services are deployed for the use of a group of
entities who share an inherent level of “trust.” In some cases, all the entities are
subject to a common security policy (thus making the trust factor stronger). In other
cases, there is no common security strategy or policy. As described previously,
there are on-site and off-site community clouds.
D2.A Same group of entities—The component of “trust” among the entities in
a community cloud makes the level of risk lower than in a public cloud.
(However, it remains higher than in a private cloud.)
D2.B Dedicated access for the community—Dedicated access can be configured
for authorized community users only.
Risk-increasing factor:
D2.C Sharing of the cloud—Different entities may have different security
measures or security requirements in place, even if they belong to the
same enterprise. This could render an entity at risk because of the faulty
procedures or SLAs of another entity, or simply because of differing security
levels for the same type of data.
Risk affected—Loss, theft, disclosure
D3. Private Cloud

In a private cloud, cloud services are deployed for the exclusive use of one
enterprise. No interaction with other entities is allowed within the cloud. As
described previously, there are on-site and off-site private clouds.
D3.A Can be built on-premises—Physical or location-related considerations can
be more closely controlled by the enterprise because the cloud infrastructure
can be located on the enterprise’s premises. Global enterprise security
policies would apply.
D3.B Performance—Affects on-site private clouds. Because the private cloud is
deployed inside the firewall on the enterprise’s intranet, transfer rates are
dramatically increased (fewer nodes to cross). Storage capacity can also be
higher; private clouds usually start with a few terabytes and can be increased
by adding disks.
D3.C Application compatibility—While applications that have already been confirmed
to be virtualization-friendly are likely to run well in a private cloud environment,
problems can occur with older and/or customized software that assumes direct
access to resources. Larger applications that currently run on dedicated specialized
clusters with hardwiring into proprietary runtime and management environments
may also be questionable candidates for migration, at least until standards settle
and vendors take steps to make their solutions private-cloud-compatible. In the
meantime, compatibility testing and remediation are critical.
D3.D Investments required—Making a business case for shared infrastructure
and the necessary training or recruitment to acquire associated skills is
notoriously hard at the best of times. Although the word “cloud” has a high
profile, messages from vendors and service providers are often confusing
and contradictory, making seeking support from senior stakeholders even
more of an issue. If the head of finance thinks cloud is all about getting rid
of infrastructure, it can be difficult to explain that investments are needed in
new equipment, software and tools. The enterprise must conduct a cost-benefit
analysis and prepare a business case to determine whether the cloud is a viable
solution to meet specific business requirements, and justify any expenses.
Risk affected—Cost
Cloud IT skills required—Affects on-site private clouds. Building a private

D3.E
cloud within the enterprise infrastructure seems the best option in terms of
security. However, the maintenance of cloud infrastructures requires specific
cloud IT skills in addition to the traditional IT skills, thus increasing the
required initial investment and maintenance costs.
Risk affected—Cost
D4. Hybrid Cloud

Hybrid cloud is a model that allows enterprises to create a mix of public,
community and private clouds, depending on the level of “trust” required for their
information assets. For example, an enterprise could decide that its web portals can
be migrated to a public cloud, but its main business application should be migrated
to a private cloud, this combination will create a hybrid cloud model.
Because hybrid clouds are a mix of the other three models, their risk-increasing or
risk-decreasing factors are the same as those models. There is, however, one
risk-increasing factor related mainly to this model:
D4.A Cloud-interdependency—If the enterprise mixes two or more different
types of clouds, strict identity controls and strong credentials will be needed
to allow one cloud to have access to another. This is similar to a common
network infrastructure problem: how to allow access from a low-level
security zone to a high-level security zone?
Overview of Threats and Mitigating Actions
When considering these implementation strategies, service models and related risk,
it is noteworthy that most of the risk-increasing factors affect theft and disclosure
while most of the risk-decreasing factors affect unavailability and loss. This could
be interpreted as a trade-off.
Risk-decreasing factors are exploited through the implementation of controls to

ensure that the enterprise receives the full benefits of the cloud. Control objectives
for cloud operations are covered extensively in ISACA’s publication IT Control
Objectives for Cloud Computing: Controls and Assurance in the Cloud.
This section addresses the possible threats that could exploit any of the risk-increasing
factors previously described. It also maps the threats to mitigating actions found in
COBIT 5 for Information Security, which explains in more detail selected terminology
and how to implement certain actions within the enterprise. (A table mapping threats
and mitigating actions can be found in the appendices section.)
With the implementation of these mitigation actions, the impact and probability of
a risk event are greatly reduced, depending on the level of severity of the controls
involved. But risk and threats still exist, although reduced. Specific risk assessments
must be conducted periodically to evaluate the risk situation of the assets specific to
the enterprise and identify improvement opportunities.
Technical 3
A. Vulnerable access management (infrastructure and application, public cloud):
• Related risk factors: S1.D, S3.F, D1.B, D2.C
• Description: Information assets could be accessed by unauthorized entities due
to faulty or vulnerable access management measures or processes. This could
result from a forgery/theft of legitimate credentials or a common technical
practice (e.g., administrator permissions override).
• Mitigation:
– A contractual agreement is necessary to officially clarify who is allowed to
access the enterprise’s information, naming specific roles for CSP employees
and external partners.
– Request that the CSP provide detailed technical specifications of its IAM
system for the enterprise’s CISO (or equivalent authority) to review and
approve. If necessary, include additional controls to ensure robustness of the
CSP’s IAM system. Most CSPs will not provide such details due to internal
security policies, but the enterprise can request controls and benchmarks as
an alternative (e.g., result of penetration testing on the CSP’s IAM systems).
– Use corporate IAM systems instead of CSP’s IAM systems. The IAM
remains the responsibility of the enterprise, so no access to assets can be
granted without the knowledge of the enterprise. It requires the approval
of the CSP and the establishment of a secure channel between the CSP
infrastructure and the corporate IAM system.
• Related guidance in COBIT 5 for Information Security:
– A ppendix A. Detailed Guidance: Principles, Policies and Frameworks Enabler
. A.2 Information Security Policy
– Appendix F. Detailed Guidance: Services, Infrastructure and Applications
Enabler
. F.6 User Access and Access Rights in Line With Business Requirements
. F.10 Monitoring and Alert Services for Security-related Events
B. Data visible to other tenants when resources are allocated dynamically
• Related risk factor: S1.E
• Description: This refers to data that have been stored in memory space or
disk space that can be recovered by other entities sharing the cloud by using
forensics techniques.
• Mitigation:
and external partners. All controls protecting the enterprise’s information
assets must be clearly documented in the contract agreement or SLA.
– Encrypt all sensitive assets that are being migrated to the CSP, and ensure
that proper key management processes are in place. This will consume part
of the allocated resources due to the encrypt/decrypt process and global
performance can be affected.
– Request the CSP’s technical specifications and controls to ensure that the data
are properly wiped when requested.
– Use a private cloud deployment model (no multitenancy).
3
elated guidance on technical threats and mitigating actions can also be found in COBIT 5, DSS05
R
Manage security services.

– Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:
. G.3 Information Risk Management
. G.6 Information Assessment and Testing and Compliance
Enabler:
. F.5 Adequately Secured and Configured Systems in Line With Security
Requirements and Security Architecture
. F.9 Security Testing
C. Multitenancy visibility:
• Related risk factors: S1.E, D1.B, D2.C
• Description: Due to the nature of multitenancy, some assets (e.g., routing
tables, media access controls [MAC] addresses, internal IP addresses, local
area network [LAN] traffic) can be visible to other entities in the same cloud.
Malicious entities in the cloud could take advantage of the information; for
example, by utilizing shared routing tables to map the internal network topology
of an enterprise, preparing the way for an internal attack.
• Mitigation:
– Request the CSP’s technical details for CISO (or equivalent authority) approval
and require additional controls to ensure data privacy, when necessary.
and external partners. All controls protecting the enterprise’s information
assets must be clearly documented in the contract agreement or SLA.
– U se a private cloud deployment model (no multitenancy).
– Appendix E. Detailed Guidance: Information Enabler:
. E.8 Information Security Review Reports
– Appendix C. Detailed Guidance: Organizational Structures Enabler:
. C.1 Chief Information Security Officer (CISO)
Enabler:
D. Hypervisor attacks:
• Description: Hypervisors are vital for server virtualization. They provide the
link between virtual machines and the underlying physical resources required to
run the machines by using hypercalls (similar to system calls, but for virtualized
systems). An attacker using a virtual machine in the same cloud could fake
hypercalls to inject malicious code or trigger bugs in the hypervisor. This could
potentially be used to violate confidentiality or integrity of other virtual machines
or crash the hypervisor (similar to a DDoS attack).
• Mitigation:
– Request CSP’s internal SLA for hypervisor vulnerability management, patch
management and release management when new hypervisor vulnerabilities are
discovered. The SLA must contain detailed specifications about vulnerability
classification and actions taken according to the severity level.

– Appendix B. Detailed Guidance: Processes Enabler:
. B.2 Align, Plan and Organize: APO09 Manage Service Agreements
– A ppendix A. Detailed Guidance: Principles, Policies and Framework Enabler:
E. Application attacks:
• Related risk factor: S3.H
• Description: Due to the nature of SaaS, the applications offered by a CSP are
more broadly exposed. Because they can be the target of massive and elaborate
application attacks, additional security measures (besides standard network
firewalls) are required to protect them.
• Mitigation:
– Request that the CSP implements application firewalls, antivirus and anti-
malware tools.
– The SLA must contain detailed specifications about vulnerability
classification and actions taken according to the severity level, which must
align with corporate policies and procedures for similar events.
. G.5 Information Security Operations
Enabler:
F. Application compatibility
• Related risk factor: D3.C
• Description: In a virtualized environment, direct access to resources is no
longer possible (the hypervisor stays in the middle). This could generate issues
with older and/or customized software that could go unnoticed until it is too
late to fall back.
• Mitigation:
– Evaluate extensively the design and requirements of application candidates
to move to the cloud and/or request the CSP a test period to identify possible
issues.
– Require continuous communication and notification of major changes to
ensure that compatibility testing is included in the change plans.
. B.3 Build, Acquire and Implement: BAI02 Manage Requirements
Definition
. E.6 Information Security Requirements
Enabler:
. F.3 Secure Development
G. Collateral damage
• Description: The enterprise can be affected by issues involving other entities
sharing the cloud. For example, DDoS attacks affecting another entity in the
cloud can leave the enterprise without access to business applications (for SaaS
models) or extra computing resources to handle peak loads (for IaaS models).
• Mitigation:
– Ask the CSP to include the enterprise in its incident management process
that deals with notification of collateral events.
– Include contract clauses and controls to ensure that the enterprise’s
contracted capacity is always available and cannot be directed to other
tenants without approval.
– Use a private cloud deployment model (no multitenancy).
Enabler:
. F.8 Adequate Incident Response
H. SaaS access security
• Related risk factor: S3.K
• Description: Access to SaaS applications (either via browser or specific
end-user clients) must be secure in order to control the exposure to attacks and
protect the enterprise and his assets.
• Mitigation:
– Use hardened web browsers and/or specific end-user client applications
which include appropriate security measures (anti-malware, encryption,
sandboxes, etc.).
– Use secure virtual desktops or specific browser clients when connecting to
cloud applications.
– Educate corporate users about the risk of running SaaS applications using
insecure devices.
Enabler:
. F.6 User Access and Access Rights in Line With Business Requirements
. G.5 Information Security Operations
I. Outdated VM security
• Related risk factor: S1.K
• Description: An inactive VM could be easily overlooked and important
security patches could be left unapplied. This out-of-date VM could become
compromised when activated and expose other VM connected to the cloud.
• Mitigation:
– Introduce procedures within the enterprise to verify the state of software
security updates prior to the activation of any VMs.
– Contractually request the CSP to apply security patches on inactive VMs.
– Appendix A. Detailed Guidance: Principles, Policies and Framework
Enabler:
Enabler:
. F.5 Adequately Secured and Configured Systems, Aligned With Security
Regulatory 4
A. Asset ownership
• Related risk factors: S2.D, S3.C
• Description: Any asset (data, application or process) migrated to a CSP could be
legally owned by the CSP based on contract terms. Thus, the enterprise can lose
sensitive data or have data disclosed because the enterprise is no longer the sole
legal owner of the asset. In the event of contract termination, the enterprise could
even be subject (by contract) to pay fees to retrieve its own assets.
• Mitigation:
– Include terms in the contract with the CSP that ensure that the enterprise
remains the sole legal owner of any asset migrated to the CSP.
– Encrypt all sensitive assets being migrated to the CSP prior to the migration
to prevent disclosure and ensure proper key management is in place. This can
affect the performance of the system.
– Appendix C. Detailed Guidance: Organizational Structures Enabler:
. C.5 Information Custodians/Business Owners
B. Asset disposal
• Related risk factors: S1.I, S2.E, S3.D
• Description: In the event of contract termination, to prevent disclosure of
the enterprise’s assets, those assets should be removed from the cloud using
tools and processes commensurate to data classification; forensic tools
may be necessary to remove sensitive data (or other tools that ensure a
complete wipeout).
• Mitigation:
– Request CSP’s technical specifications and controls that ensure that data are
properly wiped and backup media are destroyed when requested.
– Include terms in the contract that require, upon contract expiration or any
event ending the contract, a mandatory data wipe carried out under the
enterprise’s review.
4
elated guidance on regulatory threats and mitigating actions can be found in COBIT 5, MEA03
R
Monitor, evaluate and assess compliance with external requirements.
C. Asset location
• Related risk factor: S1.D
• Description: Technical information assets (data, logs, etc.) are subject to the
regulations of the country where they are stored or processed. In the cloud, an
enterprise may, without notification, migrate information assets to countries
where regulations are less restrictive or their transmission is prohibited
(personal information in particular). Unauthorized entities that cannot have
access to assets in one country may be able to obtain legal access in another
country. Conversely, if assets are moved to countries with stricter regulations,
the enterprise can be subject to legal actions and fines for noncompliance.
• Mitigation:
– Request the CSP’s list of infrastructure locations and verify that regulation in
those locations is aligned with the enterprise’s requirements.
– Include terms in the service contract to restrict the moving of enterprise
assets to only those areas known to be compliant with the enterprise’s own
regulation.
– To prevent disclosure, encrypt any asset prior to migration to the CSP, and
ensure proper key management is in place.
. G.4 Information Security Architecture Development
Enabler:
. F.2 Security Awareness
Information Security Governance5

A. Physical security on all premises where data/applications are stored
• Related risk factor: S1.H
• Description: Physical security is required in any infrastructure. When the
enterprise migrates assets to a cloud infrastructure, those assets are still subject
to the corporate security policy, but they can also be physically accessed by the
CSP’s staff, which is subject to the CSP’s security policy. There could be a gap
between the security measures provided by the CSP and the requirements of
the enterprise.
• Mitigation:
– Request the CSP’s physical security policy and ensure that it is aligned with
the enterprise’s security policy.
– Request that the CSP provide proof of independent security reviews or
certification reports that meet the enterprise’s compliance requirements (e.g.,
AICPA SSAE 16 SOC 2 report, SOX, PCI DSS, HIPAA, ISO certification).
– Include in the contract language that requires the CSP to be aligned with the
enterprise’s security policy and to implement necessary controls to ensure it.
– Request the CSP’s disaster recovery plans and ensure that they contain the
necessary countermeasures to protect physical assets during and after a disaster.
5
elated guidance on information security governance threats and mitigating actions can be found in
R
COBIT 5, EDM01 through EDM05 processes.

– Appendix E. Detailed Guidance: Information Enabler
– A ppendix A. Detailed Guidance: Principles, Policies and Frameworks Enabler
B. Visibility of the security measures put in place by the CSP:
• Related risk factor: S1.F
• Description: The cloud is similar to any infrastructure in that security
measures (technology and processes) should be in place to prevent security
attacks. The security measures provided by the CSP should be aligned with the
requirements of the enterprise, including management of security incidents.
• Mitigation:
– Request the CSP’s detailed schemes of the technical security measures in
place and determine whether they meet the requirements of the enterprise.
– Include in the contract language that requires the CSP to provide the
enterprise regular reporting on security (incident reports, intrusion detection
system [IDS]/intrusion prevention system [IPS] logs, etc.).
– Request the CSP’s security incident management process to be applied to
the enterprise’s assets and ensure that it is aligned with the enterprise’s own
security policy.
– Appendix E. Detailed Guidance: Information Enabler
. E.8 Information Security Review Reports
. E.9 Information Security Dashboard
– A ppendix F. Detailed Guidance: Services, Infrastructure and Applications
Enabler:
C. Media management:
• Related risk factor: S1.I
• Description: Data media must be disposed in a secure way to avoid data
leakage and disclosure. Data wipeout procedures must ensure data cannot be
reproduced when data media is designated for recycle or disposal. Controls
should be in place during transportation (encryption and physical security).
This should be specified in the CSP security policy and contract SLA.
• Mitigation:
– Request the CSP’s process and techniques in place for data media disposal
and evaluate whether they meet the requirements of the enterprise.
– Include in the contract language that requires the CSP to comply with the
enterprise’s security policy.
– Appendix B. Detailed Guidance: Processes Enabler
. B. 3 Build, Acquire and Implement: BAI08 Manage Knowledge
D. Secure software SDLC:

• Description: When using SaaS services, the enterprise must be sure that the
applications will meet its security requirements. This will reduce the risk of
theft, disclosure and unavailability.
• Mitigation:
– Request the CSP’s details about the software SDLC policy and procedures
in place and ensure that the security measures introduced into the design are
compliant with the requirements of the enterprise.
. B. 3 Build, Acquire and Implement: BAI03 Manage Solutions
Identification and Build
Enabler:
. F.3 Secure Development
E. Common security policy for community clouds:
• Description: Community clouds share resources among different entities that
belong to the same group (or community) and thereby possess a certain level
of mutual “trust.” This trust must be regulated by a common security policy.
Otherwise, an attack on the “weakest link” of the group could place all the
group’s entities in danger.
• Mitigation:
– Ensure that a global security policy specifying minimum requirements is
applied to all entities sharing a community cloud.
– Appendix 5. Detailed Guidance: Principles, Policies and Framework
Enabler:
. E.2 Information Security Strategy
F. Service termination issues
• Related risk factor: S3.G
• Description: Currently, there is very little available in terms of tools,
procedures or other offerings to facilitate data or service portability from CSP
to CSP. This can make it very difficult for the enterprise to migrate from one
CSP to another or to bring services back in-house. It can also result in serious
business disruption or failure should the CSP go bankrupt, face legal action, or be
the potential target for an acquisition (with the likelihood of sudden changes in
CSP policies and any agreements in place). Another possibility is the “run on the
banks” scenario, in which there is a crisis of confidence in the CSP’s financial
position resulting in a mass exit and withdrawal on first-come,
first-served basis. If there are limits to the amount of content that can be
withdrawn in a given time frame, then the enterprise might not be able to retrieve
all its data in the time specified. Another possibility may occur if the enterprise
decides, for any reason, to end the relationship with the CSP. The complexity of
the business logic and data models could make it impossible for the enterprise to
extract its data, reconstruct the business logic and rebuild the applications.
• Mitigation:
– Ensure by contract or SLA with the CSP an exit strategy that specifies the
terms that should trigger the retrieval of the enterprise’s assets in the time
frame required by the enterprise.
– Implement a DRP, taking into account the possibility of complete CSP
disruption.
. B.2 Align, Plan and Organize: APO09 Manage Service Agreements
. B.4 Deliver, Service and Support: DSS04 Manage Continuity
G. Solid enterprise governance:
• Related risk factor: S3.I
• Description: Enterprises turn to CSPs in search of solutions that can be
implemented easily and at low cost. This ease can be tempting, especially when
the enterprise is facing urgent deadlines that require an urgent solution (e.g.,
the expiration of application licenses or the need of more computing capacity).
This can become an issue because enterprises may contract cloud applications
without proper procurement and approval oversight, thus bypassing compliance
with internal policies.
• Mitigation:
– Ensure that internal governance controls are in place within the enterprise to
involve the necessary governance organization (legal, compliance, finance,
etc.) during the decision process of migrating to cloud services.
. B.1 Evaluate, Direct and Monitor: EDM01 Ensure Governance Framework
Setting and Maintenance.
. B.5 Monitor, Evaluate and Assess: MEA02 Monitor, Evaluate and Assess
the System of Internal Control
H. Support for audit and forensic investigations.

• Related risk factor: S1.F, S1.L
• Description: Security audits and forensic investigations are vital to the enterprise
to evaluate the security measures of the CSP (preventive and corrective), and
in some cases the CSP itself (for example, to authenticate the CSP). This raises
several issues because performing these actions requires extensive access to the
CSP’s infrastructure and monitoring capabilities, which are often shared with
other CSP’s customers. The enterprise should have the permission of the CSP to
perform regular audits and to have access to forensic data without violating the
contractual obligations of the CSP to other customers.
• Mitigation:
– Request the CSP the right to audit as part of the contract or SLA. If this is
not possible, request security audit reports by trusted third parties.
– Request that the CSP provide appropriate and timely support (logs, traces,
hard disk images, etc.) for forensic analysis as part of the contract or SLA.
If this is not possible, request to authorize trusted third parties to perform
forensic analysis when necessary.
. B.1 Align, Plan and Organise: APO10 Manage Suppliers.
. B.5 Monitor, Evaluate and Assess: MEA02 Monitor, Evaluate and Assess
the System of Internal Control.
4. The Path to the Decision and Beyond 35
4. The Path to the Decision and Beyond

This chapter provides practical guidance on how to consider a potential decision
to go to the cloud. Two decision trees are outlined to help prospective cloud users
decide whether they should move assets to the cloud and, if so, which service
and deployment models are best for their enterprise. In this context, the following
approach can be taken:
Step 1. Preparation of the internal environment
Step 2. Selection of the cloud service model
Step 3. Selection of the cloud deployment model
Step 4. Selection of the cloud provider
However, the challenge does not end after step 4. Even if the enterprise has decided
to go to the cloud based on the steps above and the enterprise trusts the CSP, there
are still a number of questions that must be answered. These questions have been
already touched on through the mitigating actions mentioned in chapter 3. These
mitigating actions can be translated into a checklist that management should use in
deciding to move to the cloud. The actions can be divided into four categories:
• Actions to be done prior to moving to the cloud (preparatory work)
• Cloud provider checks and requests
• Contract terms to be negotiated
• Preventive measures to be taken
An overview of the checklist appears in appendix A.
In addition to this publication, practical guidance on implementing best practices

relative to IT governance can be found in ISACA’s publication COBIT 5
Implementation, which includes an implementation tool kit containing a variety of
resources that are continually enhanced to reflect current trends. Its content includes:
• Self-assessment, measurement and diagnostic tools
• Presentations aimed at various audiences
• Related articles and further explanations
Step 1. Preparation of the Internal Environment
Besides selecting deployment and service models, an enterprise must do some

preparatory work to make a migration to the cloud possible.6 All IT dimensions
should be taken into account when defining the project scope and project plan. The
COBIT 5 enablers (principles, policies and frameworks; processes; organizational
structures; culture, ethics and behaviour; information; services, infrastructure and
applications; people, skills and competencies;) provide practical guidance when
looking into the different aspects:
• Principles, policies, and frameworks—Which security policies apply within
the enterprise? Which regulatory restrictions apply to the enterprise and to any
locations where a CSP might reside?
6
Commercial analysis must, of course, be done, but it is out of scope for this publication.
• Processes—How will moving to the cloud influence the enterprise’s processes?

Which processes depend on assets that could move to the cloud? Are these
processes considered to be critical for the business?
• Organizational structures—How will the relationship with the CSP be
managed? How are roles and responsibilities defined?
• Culture, ethics and behaviour—How will change within the enterprise be
managed? How can an information culture be imposed upon the CSP?
• Information—Which assets are considered for cloud computing? The enterprise
should classify its assets into categories for an optimal selection of cloud
arrangements. Generally, data can be classified as public, restricted, for internal
use, secret and top-secret. A data life cycle process can also be defined.
• Services, infrastructure and applications—Which service capabilities are
expected of the CSP? How will performance be measured? How will issues
be reported?
• People, skills and competencies—Which skills and competencies are required
to manage the assets of the enterprise? Does the enterprise wish to keep these
in-house after a move to the cloud has been decided on?
In addition to these considerations, the enterprise’s decision to migrate to the cloud

must take into account a consistent business case and an evaluation of the costs and
benefits related to the move to the CSP.
After the preparation of the internal environment, the following step is to look into
the selection of a cloud service and deployment model. The flowcharts presented in
steps 2 and 3 will help the enterprise to determine which cloud service model and
which cloud deployment model could best suit the enterprise needs.
While the questions were chosen very carefully in order to accommodate a

maximum of enterprise needs, the flowcharts only serve as an example of what type
of questions should be taken into consideration. Questions can be added or adapted
to better serve individual enterprise needs.
Step 2. Selection of the Cloud Service Model
The most common technical reason not to move to the cloud is that the cost of
customization outweighs the benefits of the cloud solution.
The decision tree presented in figure 3 is designed to help the enterprise determine
which service model best serves its business needs. The decision tree may lead to
a decision to migrate to the cloud, but it may also suggest that the cloud is not the
optimal solution for the enterprise and that other solutions, such as outsourcing,
may be more viable options.
The cloud deployment model addresses potential risk and its mitigation, while the
service model is more focused on a technical solution. This explains why not all
possible outcomes in the decision tree end in a cloud service model.
Figure 3—Decision Tree: Choosing a Service Model
1. Is the business process a A cloud solution is probably

7. Business driver not the best solution for
nonstandard solution? cloud-compatible?
N N your business needs.
Y Y
2. Interdependencies
with other SaaS
business processes? N
3. Difference from standard

solutions IT-based? N
4. Applications/hardware/OS
custom? N
5. Hardware/OS custom?
N
PaaS
6. Hardware custom? IaaS

N
A cloud solution is probably

not the best solution for
your business needs.
Breakdown of Cloud Service Model Decision Tree
Figure 4 provides a breakdown of the cloud service model decision tree.
Figure 4—Breakdown of Cloud Service Model Decision Tree

Answer Explanation Next Question
1. Is the business process a nonstandard solution?
Yes If the business process uses nonstandard Question 2: Interdependencies with
solutions, then a further drilling down is business processes?
needed to determine whether the business
process is suitable for a cloud solution.
No If a standard solution is used, then the Question 7: Business driver
transition to the cloud is relatively easy and cloud-compatible?
the benefits of adopting a cloud solution
will most likely be high.
2. Interdependencies with business processes?
Yes If there are interdependencies with Question 3: Difference from standard
different business processes, then any solutions IT-based?
alteration to one of these processes
could mean a change to the application
implemented in the cloud.
No If there are no interdependencies, Question 7: Business driver
then changes will not be required. The cloud-compatible?
chosen cloud solution will, therefore, be
independent.
3. Difference from standard solutions IT-based?
Yes While interdependency may implicate a Question 4: Applications/hardware/OS
change in the IT infrastructure, it is not custom?
always a necessity. If interdependency
does implicate such a change, however,
the cloud application will need to be
changed. This fact will largely influence the
decision for a cloud service model. Thus,
it is important to outline the differences
between the current solution and the
standard solution provided by a CSP.
No If there are no differences between the IT Question 7: Business driver
solutions, then the standard offerings of a cloud-compatible?
CSP will adequately address the business
needs.
4. Application/hardware/OS custom?
Yes Once it is established that there is indeed Question 5: Hardware/OS custom?
a gap between the business needs and the
cloud service offerings, it is important to
define the level on which the difference is
situated.
No If the differentiation is situated in the Question 7: Business driver
configuration of standard applications, then cloud-compatible?
cloud offerings will fulfill the business needs.
Figure 4—Breakdown of Cloud Service Model Decision Tree (cont.)

5. Hardware/OS custom?
Yes After establishing that the difference is Question 6: Hardware custom?
not within the application, it is important
to establish whether the differentiation
is found on the OS level or the physical
hardware platform. The answer will alter
the possibility for cloud adaptation.
No If the differentiation can be done on Solution: PaaS
application level, no further drill-down is
needed.
6. Hardware custom?
Yes After establishing that the differentiation Solution: A cloud solution is probably not
is located on the physical level, a cloud the best solution for your business needs.
solution is very unlikely. CSPs are oriented
toward standardization within their domain;
providing custom hardware is not one of
their typical offerings. While a CSP can
undoubtedly provide custom hardware
platforms, the high cost and the CSP’s
relative lack of experience in the custom
platform eliminate the cloud as a viable
solution.
No If the differentiation can be done on the OS Solution: IaaS
level, no further drill-down is needed.
7. Business driver cloud-compatible?
Yes Viable business drivers for the cloud Solution: SaaS
decision include:
• Reduce medium- and/or long-term total
cost of ownership (TCO).
• Improve cash flow by decreasing
investments.
• Shift from capital expenditures (CAPEX)
to operating expenditures (OPEX).
• Improve Quality of Service (QoS) and/
or SLAs.
• Gain access to functionality and/or
domain expertise.
No While there may be no technical Solution: A cloud solution is probably not
constraints to adopting the cloud as a the best solution for your business needs.
solution, it is possible that the business
drivers are, in fact, not cloud-compatible.
Adopting a cloud solution requires a
mid- to long-term vision. Therefore, the
cloud cannot be used as a solution to cut
costs immediately.
Step 3. Selection of the Cloud Deployment Model
While there are four common cloud deployment models, the decision tree presented
in this section focuses on deciding between a private or public cloud. Hybrid cloud
or community cloud are deployment models that arise for consideration when
evaluating several cloud solutions that are present in one enterprise or collection of
enterprises.
A hybrid cloud is most commonly used when there is a data classification system
in place and the decision is made to use different deployment models for different
data classifications (e.g., a private cloud model for HR data and a public cloud for
storage of publications).
The same goes for a community cloud. A community cloud is created when several
allied companies or enterprises decide to move to the cloud together. Either the
community as a whole decides to create a common infrastructure platform for all
to use (common reasons being the ease of sharing information and cost reduction),
or one member or sponsor provides the necessary infrastructure that is used by
the community.
The decision tree (shown in figure 5) also offers the options of not going to the
cloud at all or considering alternatives to the cloud. This decision (among others)
is made when the data or the process is too critical or contains so much sensitive or
business-critical data that the risk of going to the cloud outweighs the benefits.
NOTE: When the situation addressed in the question is not occurring or when it
can be adequately covered by technical means, policies or contracts, the question
should be answered affirmatively.
Full cloud may not
be the best solution. Cloud may
Start Hybrid cloud may not be the
be considered. best solution.
N N
N N N
Y 23. Cost
22. SLA?
1. Sensitive Y Y 15. Cost Y 16. Adequate Y efficient?
14. SLA? efficient? infrastructure? 17. Predictable?
data? Y
Y
N N
Y 18. Legal/
2. Critical Y compliance Y
21. Can upgrade?
data? impediments?
Private cloud
N N N
N
3. More than Y 4. Business Y 12. In-house Y 19. Data Y

data? process critical? DRP/BCM? ownership?
N N N
Cloud may
5. Adequate N N not be the Y
infrastructure? 13. Can upgrade? 20. Jurisdiction?
best solution.
Y Y N
N N
N Y 11. Cost
6. Predictable? 10. SLA?
Figure 5—Decision Tree: Choosing a Deployment Model
efficient?
Y Y
Y Y Y
7. Legal/compliance N 8. Data N N
ownership? 9. Jurisdiction? Public cloud
impediments?
4. The Path to the Decision and Beyond
41
Breakdown of Cloud Deployment Decision Tree

Figure 6 provides a breakdown of the cloud deployment decision tree.
Figure 6—Breakdown of Cloud Deployment Decision Tree

1. Sensitive data?
Yes When considering a move to a cloud Question 14: SLA?
infrastructure it is very important to be
aware what data are to be released to
the cloud.
It is impossible to envision all potential risk

and threats; however, data of a sensitive
nature can be placed in the cloud when the
necessary controls to protect them are in
place and work effectively.
No If data are not sensitive or if no data upload Question 2: Critical data?
to the cloud is required, the first steps
toward the cloud are taken.
2. Critical data?
Yes Critical data can be: Question 14: SLA?
• Blueprints
• Formulas
• Trade secrets
• Any information absolutely necessary
for the enterprise to operate
Critical data can be placed in the cloud

when the necessary controls to protect
them are in place and working effectively.
It is important to note, however, that some
of these controls can be expensive and
complex, which may increase the cost of
moving to the cloud.
No Noncritical data can be easily placed in Question 3: More than data?
the cloud.
3. More than data?
Yes In almost all cases the decision to move Question 4: Business process critical?
to the cloud is not restricted to solely the
data. Data in the cloud are often needed
to run applications or as part of business
processes.
No If the decision to move to the cloud is Question 5: Adequate infrastructure?
limited to data only, the next step is to
evaluate the enterprise’s readiness for
this move.
Figure 6—Breakdown of Cloud Deployment Decision Tree (cont.)

4. Business process critical?
Yes To make a sound decision, it is imperative Question 12: In-house DRP/BCM?
to determine whether data and applications
hosted in the cloud support critical
business processes. This information will
help determine the requirements that the
cloud solution must satisfy.
No When a business process or supporting Question 5: Adequate infrastructure?
application is not considered critical, it may
be easier to move to the cloud.
5. Adequate infrastructure?
Yes A move to the cloud is a step toward Question 6: Predictable?
reducing the enterprise’s IT infrastructure;
however, proper planning is needed
prior to adopting a cloud solution. Some
things to consider as part of the readiness
assessment include:
• Connectivity to the CSP (bandwidth,
redundancy)
• Network security (data encryption during
transfer)
• Integration between cloud and noncloud
systems
• User connectivity (bandwidth to the
desktop or mobile devices)
No If it is determined that the current Question 13: Can upgrade?
enterprise infrastructure is not ready to
integrate with the cloud, the next step is to
determine whether the business needs
are greater than the cost to upgrade
(feasibility analysis).
6. Predictable?
Yes As part of the readiness assessment the Question 7: Legal/compliance
enterprise must determine how business impediments?
processes function and mature. This
information can help anticipate capacity
fluctuations (up or down) that must be part
of the contract with the CSP.
No When the enterprise cannot anticipate Question 10: SLA?
capacity fluctuations, further analysis
may be needed. Flexibility and scalability
are two of the cloud characteristics that
make it attractive—a flexible SLA may be
the solution until the enterprise has more
refined requirements.

7. Legal/compliance impediments?
Yes There may be legal or compliance reasons Question 10: SLA?
why data or certain business functions
cannot be moved to the cloud.
It is important for the CSP to implement

the necessary controls to ensure the
enterprise’s legal and compliance
continuity. The CSP must be able to
provide proof of compliance as reported by
a neutral audit or control body.
Identification of legal or compliance

limitations must be addressed during
the contract negotiations to stipulate the
enterprise’s expectations and how they will
be satisfied.
No If the enterprise does not have any legal or Question 8: Data ownership?
compliance impediments, the next steps to
move to the cloud can be taken.
8. Data ownership?
Yes The contract with the CSP should Question 10: SLA?
clearly stipulate that the enterprise is,
and will remain, the data owner. It is
equally important that this ownership be
maintained throughout the entire data
life cycle. Therefore, the contract should
also outline the requirements to dispose
of data in an adequate manner when the
enterprise deems necessary.
If data ownership cannot be properly

established, the enterprise may choose
to move only nonsensitive and noncritical
data.
No If the enterprise can clearly define data Question 9: Jurisdiction?
ownership during contract negotiations, the
next steps to move to the cloud can
be taken.

9. Jurisdiction?
Yes Even though data ownership resides with Question 10: SLA?
the enterprise, local and international laws
often forbid the transfer of certain data
to countries that have conflicting laws
or regulations. Therefore, it is important
for the enterprise to know the location
of the CSP’s data storage facilities and
data processing centers to prevent legal
infractions.
It is advisable for the enterprise to include

in the contract with the CSP the necessary
clauses requiring the CSP to limit service
locations to those approved by the
enterprise.
No If the enterprise does not have jurisdiction Solution: Public cloud
limitations, the cloud may be a proper
solution.
10. SLA?
Yes The enterprise must determine in advance Question 11: Cost efficient?
the terms that will be included in the SLA
keeping in mind that strict or complex SLAs
could result in higher maintenance cost.
Some of the terms that should be

negotiated and documented in the SLA
include:
• Availability
• Response time for additional computing
resources requests
• Response time for incidents
• Backup policies
• Data retention and disposal policies and
procedures
• Patch management
• Security controls
• Recovery and continuity objectives
• Controls to satisfy legal and compliance
requirements
No If an adequate SLA cannot be agreed Solution: Cloud computing may not be
upon, moving to the cloud could pose an the best solution for your current business
unacceptable level of risk. needs.
If the cost of the SLA is greater than the

business driver, the cloud solution may not
be the best solution.

11. Cost efficient?
Yes Two of the principal goals of moving to the Solution: Public cloud
cloud are becoming more cost effective
and being able to react more quickly and
inexpensively to changing situations.
No Unless the business driver is greater than Solution: Cloud computing may not be
the cost, an expensive solution may not be the best solution for your current business
the right option. needs.
12. In-house DRP/BCM?
Yes This question may already be addressed Question 16: Adequate infrastructure?
in the SLA, but the enterprise must still
be ready to consider additional DR and
BC plans. A disaster occurring within the
CSP is likely to cause an impact on the
enterprise’s operations. For example,
routes will change and entry points will be
altered, causing delays in operations. If a
disaster takes place within the enterprise,
maintaining or reestablishing connectivity
with the CSP should be a critical part of the
recovery efforts.
Enterprises whose data reside only on the

cloud should create backups to their own
premises to retain recovery and continuity
capabilities even if the CSP is completely
offline.
No Relying solely on the DRP/BCM capabilities Question 14: SLA ?
of the CSP can expose the enterprise to
extended business outages; however, if the
cost of having an in-house DRP is greater
than the business driver, the enterprise
may address this question in a more
strict SLA.
13. Can upgrade?
Yes If it is determined that the current Question 6: Predictable?
determine whether the business needs
are greater than the cost to upgrade
(feasibility analysis).
No If the cost to upgrade the current Solution: Cloud computing may not be
infrastructure is greater than the business the best solution for your current business
needs, the cloud may not be a solution yet. needs.

14. SLA?
the terms that will be included in the
SLA keeping in mind the fact that strict
or complex SLAs could result in higher
maintenance cost.

include:
• Availability
resources requests
• Backup policies
procedures
requirements
No If an adequate SLA cannot be agreed Solution: Full cloud may not be the best
on, moving to the cloud can pose an solution. Hybrid cloud may be considered.
unacceptable level of risk.

business driver, the cloud solution may
not be the best solution; however, a hybrid
cloud solution can still provide some of the
benefits of cloud computing—sensitive or
critical components can remain within the
enterprise’s premises or a private cloud,
while nonsensitive or noncritical ones can
be moved to a public cloud.
15. Cost efficient?
Yes Two of the principal goals of moving to the Question 16: Adequate infrastructure?
No Unless the business driver is greater than Solution: Full cloud may not be the best
the cost, an expensive solution may not solution. Hybrid cloud may be considered.
be the right option; however, a hybrid
cloud solution can still provide some of the
benefits of cloud computing—sensitive or
critical components can remain within the
enterprise’s premises or a private cloud,
while nonsensitive or noncritical ones can
be moved to a public cloud.

16. Adequate infrastructure?
Yes A move to the cloud is a step toward Question 17: Predictable?
reducing the enterprise’s IT infrastructure;
however, proper planning is needed
prior to adopting a cloud solution. Some
things to consider as part of the readiness
assessment include:
• Connectivity to the CSP (bandwidth,
redundancy)
• Network security (data encryption during
transfer)
• Integration between cloud and noncloud
systems
• User connectivity (bandwidth to the
desktop or mobile devices)
No If it is determined that the current Question 21: Can upgrade?
determine whether the business needs are
greater than the cost to upgrade (feasibility
analysis).
17. Predictable?
Yes As part of the readiness assessment the Question 18: Legal/compliance
enterprise must determine how business impediments?
processes function and mature. This
information can help anticipate capacity
fluctuations (up or down) that must be part
of the contract with the CSP.
No When the enterprise cannot anticipate Question 22: SLA?
capacity fluctuations, further analysis
may be needed. Flexibility and scalability
are two of the cloud characteristics that
make it attractive—a flexible SLA may be
the solution until the enterprise has more
refined requirements.

18. Legal/compliance impediments?
Yes There may be legal or compliance reasons Question 22: SLA?
why data or certain business functions
cannot be moved to the cloud.
It is important for the CSP to implement

the necessary controls to ensure the
enterprise’s legal and compliance
continuity. The CSP must be able to
provide proof of compliance as reported by
a neutral audit or control body.
Identification of legal or compliance

limitations must be addressed during
the contract negotiations to stipulate the
enterprise’s expectations and how they will
be satisfied.
No If the enterprise does not have any legal or Question 19: Data ownership?
compliance impediments, the next steps to
move to the cloud can be taken.
19. Data ownership?
Yes The contract with the CSP should Question 22: SLA?
clearly stipulate that the enterprise is,
and will remain, the data owner. It is
equally important that this ownership be
maintained throughout the entire data
life cycle. Therefore, the contract should
also outline the requirements to dispose
of data in an adequate manner when the
enterprise deems necessary.
If data ownership cannot be properly

established, the enterprise may choose
to move only nonsensitive and noncritical
data.
No If the enterprise can clearly define data Question 20: Jurisdiction?
ownership during contract negotiations, the
next steps to move to the cloud can
be taken.

20. Jurisdiction?
Yes Even though data ownership resides with the Question 22: SLA?
enterprise, local and international laws often
forbid the transfer of certain data to countries
that have conflicting laws or regulations.
Therefore, it is important for the enterprise to
know the location of the CSP’s data storage
facilities and data processing centers to
prevent legal infractions.
It is advisable for the enterprise to include

in the contract with the CSP the necessary
clauses requiring the CSP to limit service
locations to those approved by the
enterprise.
No If the enterprise does not have jurisdiction Solution: Private cloud
limitations, the cloud may be a proper
solution.
21. Can upgrade?
Yes If it is determined that the current enterprise Question 17: Predictable?
infrastructure is not ready to integrate with
the cloud, the next step is to determine
whether the business needs are greater than
the cost to upgrade (feasibility analysis).
No If the cost to upgrade the current Solution: Cloud computing may not be
infrastructure is greater than the business the best solution for your current business
needs, the cloud may not be a solution yet. needs.

22. SLA?
the terms that will be included in the SLA
keeping in mind that strict or complex SLAs
could result in higher maintenance cost.

include:
• Availability
resources requests
• Backup policies
procedures
requirements
No If an adequate SLA cannot be agreed Solution: Cloud computing may not be
on, moving to the cloud can pose an the best solution for your current business
unacceptable level of risk. needs.

business driver, the cloud solution may not
be the best solution.
23. Cost efficient?
Yes Two of the principal goals of moving to the Solution: Private cloud
No Unless the business driver is greater than Solution: Cloud computing may not be
the cost, an expensive solution may not be the best solution for your current business
the right option. needs.
Step 4. Selection of the Cloud Service Provider
Once the best-suited cloud flavor is established, it is key to find the best-suited
cloud service provider. Matching the correct CSP to the enterprise needs could
prove challenging. The key is to find the CSP that bests serves the business needs
while minimizing potential risk.
While there are many suitable smaller CSPs, it is important to choose an established
CSP with the proper references. Established CSPs will potentially be more
experienced with running cloud infrastructures, adapting to change and generally
faster in responding to an incident or threat, thus being able to maintain stability
more efficiently. One must keep in mind that a larger CSP will also be stricter
toward its offerings, which will greatly reduce the possibility of fine-tuning services
not fully compatible with the enterprise needs.
Vendor location (storage and processing centers) is of key importance for legal
reasons. Laws are applicable locally, which can result in a multitude of different
law systems applicable to data or business processes stored in the cloud.
The most important applicable laws are:

• Local law of the enterprise—Storing data in the cloud does not waive the
enterprise from the legal obligations it has toward its customers, employees and
shareholders. Therefore, local laws will still apply even if data are stored abroad.
• Local law of the CSP—Since the CSP has legal obligations toward its customers,
meaning the enterprise, the local laws of the CSP may become applicable to its data
centers and its content, including the data or business processes of the enterprise.
• Local law where data are stored—Local laws apply to the CSP’s storage
centers. The country that houses the storage center also imposes the law. This
is very important, especially regarding privacy. Privacy regulations that the
enterprise is bound to may not be applicable in the country where the data are
housed, thus potentially compromising the stored data.
• Local law where data are processed—In some countries local laws do not
merely apply to where data are stored, but are also applicable to the location
where data are processed.
Larger CSPs will take legal matters into account when deploying their data centers
and storage centers to specifically avoid legal issues. It is important, however, to
have the CSP’s storage regions backed up by an independent organization so it can
be assured that data or business process are in the best possible hands.
The goal is to find the CSP that best serves the standards and business needs of the
enterprise. A transition to the cloud will be much easier when a CSP has the same
industry certifications as the enterprise. This also goes for the business needs of the
enterprise: If the business is changing rapidly, the enterprise will want to choose
a CSP that can change quickly as well and that is agile. If, for example, computing
requirements change daily, the enterprise will want a CSP that can accommodate
those changes rapidly and fluently. A CSP that can only change processor power
every two weeks while also being required to fill in four different forms may not
be the best-suited choice for the enterprise. One must keep in mind that CSPs offer
services for a large variety of disparate customers. And while some deployment
and service models will leave room for minor adjustments, this puts the CSP at risk
because it forces it to go outside its known area of expertise. The rule of thumb is
that the better an offered service complies with the business needs, the more a CSP
will be compliant with the enterprise.
Appendix A. The Path to the Decision 53
and Beyond—Checklist
Appendix A. The Path to the Decision

and Beyond—Checklist
Figure 7 provides a checklist of considerations for using the cloud.
Figure 7—Cloud Considerations Checklist

1 Prior to move to the cloud: 3
1.1 Prepare a consistent business case and evaluate the cost and benefits related
to the move to a cloud provider.
1.2 Identify and classify all information assets (data, application, processes) that
are considered in scope.
1.3 Prepare a list of potential cloud provider candidates and perform a sanity check
on them (financial situation, references, authenticity, etc.).
1.4 Involve the necessary control organizations (legal, compliance, finance, etc.)
during the decision process of migrating to cloud services before making
a decision.
1.5 Evaluate extensively the design and requirements of application candidates to
move to the cloud and/or request that the CSP provide a test period to locate
possible issues.
2 Cloud provider check and requests: 3
2.1 Request the CSP’s security policy and ensure that it is aligned with the
enterprise’s security policy.
2.2 Request the CSP’s list of infrastructure locations and verify that regulation in
those locations is aligned with the enterprise’s requirements.
2.3 Request the CSP’s detailed schemes of the technical security measures in
place (IDS/IPS, application firewalls, etc.) and evaluate that they meet the
requirements of the enterprise.
2.4 Request the CSP’s technical details and additional controls to ensure data
privacy for CIO and CISO approval.
2.5 Request that the CSP’s security incident management process be applied to
the enterprise’s assets and ensure that it is aligned with the enterprise’s
security policy.
2.6 Request that the CSP include the enterprise into its incident management
process to be notified of collateral events.
2.7 Request the CSP’s information about its contractual SLA for hypervisor
vulnerability management, patch management and release management to be
applied when new hypervisor vulnerabilities are discovered.
2.8 Request the CSP’s detailed technical specifications of the access management
system in place for CIO and CISO approval and include additional controls to
ensure robustness of the CSP’s access management system.
2.9 Request the CSP’s technical specifications and controls to ensure that the data
are properly wiped out when requested.
Figure 7—Cloud Considerations Checklist (cont.)

2 Cloud provider check and requests: (cont.) 3
2.10 Request the CSP’s process and techniques in place for data storage media
disposal and evaluate that they meet the requirements of the enterprise.
2.11 Request the CSP’s details about the software systems development life cycle
(SDLC) policy and procedures in place and ensure that the security measures
introduced into the design are compliant with the requirements of the
enterprise.
2.12 Request the CSP’s information about the software release management
and patch management process in place and check if it is aligned with the
enterprise needs.
3 Contract terms: 3
3.1 Ensure that the CSP is aligned with the enterprise’s security policy and
implement necessary controls to monitor compliance.
3.2 Ensure that the enterprise remains the sole owner of any asset migrated to
the CSP.
3.3 Restrict the moving of assets to a certain delimited zone known as compliant
with the regulations applicable to the enterprise.
3.4 Ensure that the enterprise’s contracted capacity is always available and cannot
be directed to other tenants without approval.
3.5 Ensure that the CSP provides regular reporting on security (incident reports,
IDS/IPS logs, etc.) to the enterprise for analysis.
3.6 Ensure that the CSP applies a mandatory data wipeout under the enterprise’s
approval on contract expiration.
3.7 Ensure that the CSP is compliant with the enterprise’s security policy for data
storage media disposal.
3.8 Ensure (together with the CSP) that an exit strategy specifies the terms that
trigger the retrieval of the enterprise’s assets in the time frame required by
the enterprise.
4 Preventive measures: 3
4.1 Encrypt all sensitive assets being migrated to the CSP prior to the migration to
prevent disclosure and ensure proper key management is in place. This could
affect the performance of the system.
4.2 Use corporate identity and access management systems instead of the CSP’s
access management systems. It requires the approval of the CSP and the
establishment of a secure channel between the CSP infrastructure and the
corporate access management system.
4.3 Ensure that a global security policy specifying minimum requirements is
applied to all entities sharing a community cloud.
4.4 Implement a DRP taking into account the possibility of complete CSP disruption.
Appendix B. Overview of Different Risk Factors per Service and
Deployment Model
Figure 8 provides an overview of cloud service and deployment model risk.
Figure 8—Risk Factors of Cloud Service and Deployment Models

Risk Event
Code Risk Factor Unavailability Loss Theft Disclosure Type Description
IaaS
S1.A Scalability/ X Decreasing Lack of physical resources is no longer an issue. Due to the scalable
elasticity nature of cloud technologies, the CSP can provide capacity on
demand at low cost to support peak loads (expected or unexpected).
Elasticity eliminates overprovisioning and underprovisioning of IT
resources, allowing better cost optimization. This becomes a great
advantage for resilience when defensive measures or resources need
to be expanded quickly (e.g., during DDoS attacks).
S1.B Disaster X X Decreasing CSPs should already have in place, as common practice, disaster
recovery and recovery and backup procedures. However, RPO, RTO, and backup
backup testing frequency and procedures provided by the CSP should be
consistent with the enterprise security policy.
S1.C Patch X X X Decreasing Cloud infrastructures are based on hypervisors and are controlled
management through a central hypervisor manager or client. The hypervisor
manager allows the necessary patches to be applied across the
infrastructure in a short time, reducing the time available for a new
vulnerability to be exploited.
per Service and Deployment Model
Appendix B. Overview of Different Risk Factors
55
56
Figure 8—Risk Factors of Cloud Service and Deployment Models (cont.)

Risk Event
IaaS (cont.)
S1.D Legal X Increasing CSPs are often transborder, and different countries have different
transborder legal requirements, especially concerning personal private
requirements information. The enterprise might be committing a violation of
regulations in other countries when storing or transmitting data
within the CSP’s infrastructure without the necessary compliance
controls. Furthermore, government entities in the hosting country may
require access to the enterprise’s information, with or without proper
notification.
S1.E Multitenancy X X Increasing One of the primary benefits of the cloud is the ability to perform
and isolation dynamic allocation of physical resources when required. The most
failure common approach is a multitenant environment (public cloud),
where different entities share a pool of resources, including storage,

hardware and network components. All resources allocated to
a particular tenant should be “isolated” and protected to avoid
disclosure of information to other tenants. For example, when
allocated storage is no longer needed by a client, it can be freely
reallocated to another enterprise. In that case, sensitive data could be
disclosed if the storage has not been scrubbed thoroughly (e.g., using
forensic software).
S1.F Lack of visibility X X X X Increasing For any infrastructure, IDS/IPS and SIEM capabilities must be in
surrounding place. It is the responsibility of the CSP to provide these capabilities
technical to its customers. To ensure that there are no security gaps, the
security security policy and governance of the CSP should match those of
measures in the enterprise.
place
Risk Event
IaaS (cont.)
S1.G Absence of DRP X X Increasing The absence of a proper DRP or backup procedures implies a high
and backup risk for any enterprise. CSPs should provide such basic preventive
measures aligned with the enterprise’s business needs (in terms of
RTO/RPO).
S1.H Physical security X X Increasing In an IaaS model, physical compute resources are shared with other
entities in the cloud. If physical access to the CSP’s infrastructure is
granted to one entity, that entity could potentially access information
assets of other entities. The CSP is responsible for applying
physical security measures to protect assets against destruction or
unauthorized access.
S1.I Data disposal X Increasing Proper disposal of data is imperative to prevent unauthorized
disclosure. If appropriate measures are not taken by the CSP,
information assets could be sent (without approval) to countries
where the data can be legally disclosed due to different regulations
concerning sensitive data. Disks could be replaced, recycled or
upgraded without proper cleaning so that the information still remains
within storage and can later be retrieved. When a contract expires,
CSPs should ensure the safe disposal or destruction of any previous
backups.
S1.J Offshoring X X X X Increasing The move to offshoring of key infrastructure expands the attack
infrastructure surface area considerably. In practice, the information assets in the
cloud still need to integrate back to other noncloud-based assets
within the boundaries of the organization. These communications
(normally done through border gateway devices) could be insecure,
exposing both the cloud and internal infrastructures.
57
58

Risk Event
IaaS (cont.)
S1.K VM security X X X X Increasing IaaS providers allow consumers to create VMs in various states
maintenance (e.g., active, running, suspended and off). Although the CSP could
be involved, the maintenance of security updates is generally the
responsibility of the customer only. An inactive VM could be easily
overlooked and important security patches could be left unapplied.
This out-of-date VM could become compromised when activated.
S1.L Cloud provider X X X X Increasing Although communications between the enterprise and the cloud
authenticity provider can be secured with technical means (encryption, VPN,
mutual authentication, etc.) it is a consumer’s responsibility to check
the identity of the cloud provider to ensure that is not an imposter.
PaaS
S2.A Short X X X X Decreasing Using the SOA library provided by the CSP, applications can be
development developed and tested within a reduced timeframe because SOA
time provides a common framework for application development.
S2.B Application X X Increasing If current applications are not perfectly aligned with the capabilities
mapping provided by the CSP, additional undesirable features (and
vulnerabilities) could be introduced.
S2.C SOA-related X X X X Increasing Security for SOA presents new challenges because vulnerabilities
vulnerabilities arise not only from the individual elements, but also from their mutual
interaction. Because the SOA libraries are under the responsibility of
the CSP and are not completely visible to the enterprise, there may
exist unnoticed application vulnerabilities.
S2.D Application X X Increasing When applications are developed in a PaaS environment, originals
disposal and backups should always be available. In the event of contract
termination, the details of the application could be disclosed and used
to create more selective attacks on applications.
Risk Event
SaaS
S3.A Improved X X Decreasing CSPs depend on the good reputation of their software capabilities to
security maintain their SaaS offering. Consequently, they introduce additional
features to improve the resilience of their software (e.g., security
testing or strict versioning) or to inform users about the exact state
of their business application (e.g., specific software logging and
monitoring).
S3.B Application X X Decreasing Application patch management—Due to the fact that the SaaS
patch application service is managed globally and only by the CSPs,
management application patch management is more effective, allowing patches to
be deployed in little time with limited impact.
S3.C Data ownership X X X X Increasing The CSP provides the applications and the customer provides the
data. If data ownership is not clearly defined, the CSP could refuse
access to data when required or even demand fees to return the data
once the service contracts are terminated.
S3.D Data disposal X X Increasing In the event of a contract termination, the data fed into the CSP’s
application must be erased immediately using forensic tools to avoid
disclosures and confidentiality breaches.
S3.E Lack of visibility X X X X Increasing Enterprises that use cloud applications have little visibility into the
into software software SDLC. Customers do not know in detail how the applications
SDLC were developed and what security considerations were taken into
account during the SDLC. This could lead to an imbalance between
the security provided by the application and the security required by
customers/users.
59
60

Risk Event
SaaS (cont.)
S3.F IAM X X X Increasing To maximize their revenues, CSPs offer their services and applications
to several customers concurrently. Those customers share servers,
applications and, eventually, data. If data access is not properly
managed by the CSP application, one customer could obtain access
to another customer’s data.
S3.G Exit strategy X X Increasing Currently, there is very little available in terms of tools, procedures or
other offerings to facilitate data or service portability from CSP to CSP.
This can make it very difficult for the enterprise to migrate from one
CSP to another or to bring services back in-house. It can also result
in serious business disruption or failure should the CSP go bankrupt,
face legal action, or be the potential target for an acquisition (with the
likelihood of sudden changes in CSP policies and any agreements in

place). If the customer-CSP relationship goes sour and the enterprise
wants to bring the data back in-house, the question of how to
securely render the data becomes critical because the in-house
applications may have been decommissioned or “sunsetted” and
there is no application available to render the data.
S3.H Broad exposure X X X X Increasing In a cloud environment, the applications offered by the CSP have
of applications broader exposure, which increases the attack space; additionally, it is
quite common that those applications still need to integrate back to
other noncloud applications within the boundaries of the enterprise.
Standard network firewalls and access controls are sometimes
insufficient to protect the applications and their external interactions.
Additional security measures are required.
Risk Event
SaaS (cont.)
S3.I Ease to contract X X X X Increasing Business organizations may contract cloud applications without
SaaS proper procurement and approval oversight, thus bypassing
compliance with internal enterprise policies.
S3.J Lack of control X X Increasing As described before, CSPs are able to introduce patches in their
of the release applications quickly. These deployments are often done without the
management approval (or even the knowledge) of the application users for merely
process practical reasons: If an application is used by hundreds of different
enterprises, it would take an extremely long time for a CSP to look
for the formal approval of every customer. In this case, the enterprise
could have no control (or no view) of the release management
process and could be subject to unexpected side effects.
S3.K Browser X X Increasing As a common practice, applications offered by SaaS providers are
vulnerabilities accessible to customers via secure communication through a web
browser. Web browsers are a common target for malware and
attacks. If the customer’s browser becomes infected, the access to
the application can be compromised as well.
Public Cloud
D1.A Public X X X X Decreasing Providers of public cloud services are aware that they are generally
reputation perceived as more “risky.” It is critical for them to ensure a good
reputation because a secure provider or customers will simply
move elsewhere.
D1.B Full sharing of X X X X Increasing The cloud infrastructure is shared by multiple tenants of the cloud
the cloud (data service provider. These tenants have no relation to the enterprise or
pooling) other tenants in the same space, therefore no common interests and
concern for security.

61
62

Risk Event
Public Cloud (cont.)
D1.C Collateral X X X X Increasing If one tenant of a public cloud is attacked, there could be an impact to
damage the other tenants of the same CSP, even if they are not the intended
target (e.g., DDoS). Another possible scenario of collateral damage
could be a public cloud IaaS that is affected by an attack, exploiting
vulnerabilities of software installed by one of the tenants.
Community Cloud
D2.A Same group of X X X X Decreasing The component of “trust” among the entities in a community cloud
entities makes the level of risk lower than in a public cloud. (However, it
remains higher than in a private cloud.)
D2.B Dedicated X X Decreasing Dedicated access can be configured for authorized community
access for the users only.

community
D2.C Sharing of the X X X Increasing Different entities may have different security measures or security
cloud requirements in place, even if they belong to the same enterprise.
This could render an entity at risk because of the faulty procedures or
SLAs of another entity, or simply because of differing security levels
for the same type of data.
Private Cloud
D3.A Can be built X X X X Decreasing Physical or location-related considerations can be more closely
on-premise controlled by the enterprise because the cloud infrastructure can
be located on the enterprise’s premises. Global enterprise security
policies would apply.
Risk Event
Private Cloud (cont.)
D3.B Performance X X Decreasing Affects on-site private clouds. Because the private cloud is deployed
inside the firewall on the enterprise’s intranet, transfer rates are
dramatically increased (fewer nodes to cross). Storage capacity can
also be higher; private clouds usually start with a few terabytes and
can be increased by adding disks.
D3.C Application X X Increasing While applications that have already been confirmed to be
compatibility virtualization-friendly are likely to run well in a private cloud
environment, problems can occur with older and/or customized
software that assumes direct access to resources. Larger applications
that currently run on dedicated specialized clusters with hardwiring
into proprietary runtime and management environments may
also be questionable candidates for migration, at least until
standards settle and vendors take steps to make their solutions
private-cloud-compatible. In the meantime, compatibility testing and
remediation are critical.
D3.D Investments (can be (can be (can be (can be Increasing Making a business case for shared infrastructure and the necessary
required triggered by triggered triggered triggered training or recruitment to acquire associated skills is notoriously hard
cost) by cost) by cost) by cost) at the best of times. Although the word “cloud” has a high profile,
messages from vendors and service providers are often confusing
and contradictory, making seeking support from senior stakeholders
even more of an issue. If the head of finance thinks cloud is all
about getting rid of infrastructure, it can be difficult to explain that
investments are needed in new equipment, software, and tools. The
enterprise must conduct a business case and cost-benefit analysis
to determine whether the cloud is a viable solution to meet specific
business requirements, and justify any expenses.
63
64

Risk Event
Private Cloud (cont.)
D3.E Cloud IT skills (can be (can be (can be (can be Increasing Affects on-site private clouds. Building a private cloud within the
required triggered by triggered triggered triggered enterprise infrastructure seems the best option in terms of security.
cost) by cost) by cost) by cost) However, the maintenance of cloud infrastructures requires specific
cloud IT skills in addition to the traditional IT skills, thus increasing the
required initial investments.
Hybrid Cloud
D4.A Cloud X X X X Increasing If the enterprise mixes two or more different types of clouds, strict
interdependency identity controls and strong credentials will be needed to allow one
cloud to have access to another. This is similar to a common network
infrastructure problem: how to allow access from a low-level security
zone to a high-level security zone.

Appendix C. Mapping Threats and Mitigating Actions to
COBIT 5 for Information Security
Figure 9 maps cloud threats and mitigating actions to COBIT 5 for Information Security.
Figure 9—Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security
Risk Mapping to
Threat Description Factors Mitigation COBIT 5 for Information Security
Technical Threats
A. Vulnerable Information assets could be accessed S1.D • A contractual agreement is necessary to • Appendix A. Detailed Guidance:
access by unauthorized entities due to faulty or S3.F officially clarify who is allowed to access Principles, Policies and Frameworks
management vulnerable access management measures D1.B the enterprise’s information, naming Enabler
(infrastructure or processes. This could result from a D2.C specific roles for CSP employees and – A.2 Information Security Policy
and application, forgery/theft of legitimate credentials external partners. • Appendix F. Detailed Guidance:
public cloud) or a common technical practice (e.g., • Request that the CSP provide detailed Services, Infrastructure and Applications
administrator permissions override) technical specifications of its IAM system Enabler
for the enterprise’s CISO to review and – F.6 User Access and Access Rights in
approve. Include additional controls to Line With Business Requirements
ensure robustness of the CSP’s IAM – F.10 Monitoring and Alert Services for
system. Most CSPs will not provide such Security-related Events
details due to internal security policies,
but the enterprise can request controls
and benchmarks as an alternative (e.g.,
result of penetration testing on the CSP’s
IAM systems).
to COBIT 5 for Information Security
Appendix C. Mapping Threats and Mitigating Actions
65
66
Figure 9—Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.)
Risk Mapping to
Technical Threats (cont.)
A. Vulnerable • Use corporate IAM systems instead of
access CSP IAM systems. The IAM remains
management the responsibility of the enterprise, so
(infrastructure no access to assets can be granted
and application, without the knowledge of the enterprise.
public cloud) It requires the approval of the CSP and
(cont.) the establishment of a secure channel
between the CSP infrastructure and the
corporate IAM system.
B. Data visible to This refers to data that have been stored S1.E • A contractual agreement is necessary to • Appendix G. Detailed Guidance: People,
other tenants in memory space or disk space that can officially clarify who is allowed to access Skills and Competencies Enabler
when resources be recovered by other entities sharing the the enterprise’s information, naming – G.3 Information Risk Management
are allocated cloud by using forensics techniques. specific roles for CSP employees and – G.6 Information Assessment and
dynamically external partners. All controls protecting Testing and Compliance
the enterprise’s information assets must • Appendix F. Detailed Guidance:
be clearly documented in the contract Services, Infrastructure and Applications
agreement or SLA. Enabler
• Encrypt all sensitive assets that are being – F.5 Adequately Secured and Configured
migrated to the CSP, and ensure that Systems, in Line With Security
proper key management processes are Requirements and Security Architecture
in place. This will consume part of the – F.9 Security Testing
allocated resources due to the
encrypt/decrypt process so global
performance could be affected.
• Request the CSP’s technical
specifications and controls to ensure
that the data are properly wiped when
requested.
• Use a private cloud deployment model
(no multitenancy).
Risk Mapping to
C. Multitenancy Due to the nature of multitenancy, S1.E • Request the CSP’s technical details for • Appendix E. Detailed Guidance:
visibility some assets (e.g., routing tables, MAC D1.B CISO approval and require additional Information Enabler
addresses, internal IP addresses, LAN D2.C controls to ensure data privacy. – E.8 Information Security Review
traffic) could be visible to other entities • A contractual agreement is necessary to Reports
in the same cloud. Malicious entities in officially clarify who is allowed to access • Appendix C. Detailed Guidance:
the cloud could take advantage of the the enterprise’s information, naming Organizational Structures Enabler
information, e.g., by utilizing shared routing specific roles for CSP employees and – C.1 Chief Information Security Officer
tables to map the internal network topology external partners. All controls protecting (CISO)
of an enterprise, preparing the way for an the enterprise’s information assets must • Appendix F. Detailed Guidance:
internal attack. be clearly documented in the contract Services, Infrastructure and Applications
agreement or SLA. Enabler
• Use a private cloud deployment model – F.10 Monitoring and Alert Services for
(no multitenancy). Security-related Events
D. Hypervisor Hypervisors are vital for cloud virtualization. S1.E • Request the CSP’s internal SLA for • Appendix B. Detailed Guidance:
attacks They provide the link between virtual hypervisor vulnerability management, Processes Enabler
machines and the underlying physical patch management and release – B.2
Align, Plan and Organize (APO)
resources required to run the machines by management when new hypervisor . APO09 Manage Service Agreements.
using hypercalls (similar to system calls, vulnerabilities are discovered. The SLA • Appendix G. Detailed Guidance: People,
but for virtualized systems). An attacker must contain detailed specifications about Skills and Competencies Enabler
using a VM in the same cloud could fake vulnerability classification and actions – G.3 Information Risk Management
hypercalls to inject malicious code or taken according to the severity level. • Appendix A. Detailed Guidance:
trigger bugs in the hypervisor. This could • Use a private cloud deployment model Principles, Policies and Framework
potentially be used to violate confidentiality (no multitenancy). Enabler
or integrity of other VMs or crash the – A .2 Information Security Policy
hypervisor (similar to a DDoS attack).
67
68
Risk Mapping to
E. Application Due to the nature of SaaS, the applications S3.H • Request that the CSP implements • Appendix G. Detailed Guidance: People,
attacks offered by a CSP are more broadly application firewalls, antivirus, and Skills and Competencies Enabler
exposed. Because they can be the target of anti-malware tools. – G.5 Information Security Operations
massive and elaborate application attacks, • The SLA must contain detailed – G.6 Information Assessment and
additional security measures (besides specifications about vulnerability Testing and Compliance
standard network firewalls) are required to classification and actions taken • Appendix F. Detailed Guidance:
protect them. according to the severity level, which Services, Infrastructure and Applications
must align with corporate policies and Enabler
procedures for similar events. – F.10 Monitoring and Alert Services for
Security-related Events
F. Application In a virtualized environment, direct access D3.C • Evaluate extensively the design and • Appendix B. Detailed Guidance:
compatibility to resources is no longer possible (the requirements of application candidates Processes Enabler
hypervisor stays in the middle). This to move to the cloud and/or request of –B .3 Build, Acquire and Implement (BAI)
could generate issues with older and/ the CSP a test period to identify possible . BAI02 Manage Requirements
or customized software that could go issues. Definition.
unnoticed until it is too late to fall back. • Require continuous communication and • Appendix E. Detailed Guidance:
notification of major changes to ensure Information Enabler
that compatibility testing is included in – E.6 Information Security Requirements
the change plans. • Appendix F. Detailed Guidance:
Services, Infrastructure and Applications
Enabler
– F.3 Secure Development
Risk Mapping to
G. Collateral The enterprise can be affected by issues D1.C • Ask the CSP to include the enterprise • Appendix E. Detailed Guidance:
damage involving other entities sharing the cloud. in its incident management process Information Enabler
For example, DDoS attacks affecting that deals with notification of collateral – E.6 Information Security Requirements
another entity in the cloud can leave the events. • Appendix F. Detailed Guidance:
enterprise without access to business • Include contract clauses and controls to Services, Infrastructure and Applications
applications (for SaaS models) or extra ensure that the enterprise’s contracted Enabler
computing resources to handle peak loads capacity is always available and cannot – F.8 Adequate Incident Response
(for IaaS models). be directed to other tenants without • Appendix G. Detailed Guidance: People,
approval. Skills and Competencies Enabler
• Use a private cloud deployment model – G.3 Information Risk Management
(no multitenancy).
H. SaaS access Access to SaaS applications (either via S3.K • Use hardened web browsers and/or • Appendix F. Detailed Guidance:
security browser or specific end-user clients) must specific end-user client applications Services, Infrastructure and Applications
be secure in order to control the exposure which include appropriate security Enabler
to attacks and protect the enterprise and measures (anti-malware, encryption, – F.6 User Access and Access Rights in
assets. sandboxes, etc.). Line With Business Requirements
•Use secure virtual desktops or specific – F.10 Monitoring and Alert Services for
browser clients when connecting to cloud Security-related Events
applications. • Appendix G. Detailed Guidance: People,
Skills and Competencies Enabler
– G.5 Information Security Operations
69
70
Risk Mapping to
I. Outdated VM An inactive VM could be easily overlooked S1.K • Introduce procedures within the • Appendix A. Detailed Guidance:
security and important security patches could be enterprise to verify the state of software Principles, Policies and Framework
left unapplied. This out-of-date VM could security updates prior to the activation of Enabler
become compromised when activated. any VMs. – A.2 Information Security Policy
• Empower the CSP to apply security • Appendix F. Detailed Guidance: Services,
patches on inactive VMs. Infrastructure and Applications Enabler
– F.5 Adequately Secured and Configured
Systems, Aligned With Security
Regulatory Threats
A. Asset ownership Any asset (data, application or process) S2.D • Include terms in the contract with • Appendix C. Detailed Guidance:
migrated to a CSP could be legally owned S3.C the CSP to ensure that the enterprise Organizational Structures Enabler
by the CSP based on contract terms. remains the sole legal owner of any –C .5 Information Custodians/Business
Thus, the enterprise can lose sensitive asset migrated to the CSP. Owners
data or have them disclosed because • Encrypt all sensitive assets being
the enterprise is no longer the sole legal migrated to the CSP prior to the
owner of the asset. In the event of contract migration to prevent disclosure and
termination, the enterprise could even be ensure proper key management is in
subject (by contract) to pay fees to retrieve place. This could affect the performance
its own assets. of the system.
B. Asset disposal In the event of contract termination, to S1.I • Request CSP’s technical specifications • Appendix G. Detailed Guidance: People,
prevent disclosure of the enterprise’s S2.E and controls that ensure that data are Skills and Competencies Enabler:
assets, those assets should be removed S3.D properly wiped and backup media is – G.3 Information Risk Management
from the cloud using forensic tools destroyed when requested.
(or other tools that ensure a complete • Include terms in the contract that
wipeout). require, upon contract expiration or any
event ending the contract, a mandatory
data wipe carried out under the
enterprise’s review.
Risk Mapping to
Regulatory Threats (cont.)
C. Asset location Technical information assets (data, logs, S1.D • Request the CSP’s list of infrastructure • Appendix G. Detailed Guidance: People,
etc.) are subject to the regulations of locations and verify that regulation Skills and Competencies Enabler
the country where they are stored. In in those locations is aligned with the – G.4 Information Security Architecture
the cloud, an enterprise may, without enterprise’s requirements. Development
notification, migrate information assets • Include terms in the service contract – G.6 Information Assessment and
to countries where regulations are to restrict the moving of enterprise Testing and Compliance
less restrictive or their transmission assets to only those areas known to • Appendix F. Detailed Guidance:
is prohibited (personal information in be compliant with the enterprise’s own Services, Infrastructure and Applications
particular). Unauthorized entities that regulation. Enabler
cannot have access to assets in one • To prevent disclosure, encrypt any asset – F.2 Security Awareness
country may be able to obtain legal prior to migration to the CSP, and ensure
access in another country. Conversely, proper key management is in place.
if assets are moved to countries with
stricter regulations, the enterprise can
be subject to legal actions and fines for
noncompliance.
71
72
Risk Mapping to
Information Security Governance Threats
A. Physical security Physical security is required in any S1.H • Request the CSP’s physical security • Appendix E. Detailed Guidance:
on all premises infrastructure. When the enterprise policy and ensure that it is aligned with Information Enabler
where migrates assets to a cloud infrastructure, the enterprise’s security policy. – E.6 Information Security Requirements
data/applications those assets are still subject to the • Request that the CSP provide proof • Appendix A. Detailed Guidance:
are stored corporate security policy, but they can of independent security reviews or Principles, Policies and Frameworks
also be physically accessed by the CSP’s certification reports (e.g., AICPA SSAE 16 Enabler
staff, which is subject to the CSP’s security SOC 2 report or ISO certification). – A.2 Information Security Policy
policy. There could be a gap between the • Include in the contract language that
security measures provided by the CSP requires the CSP to be aligned with
and the requirements of the enterprise. the enterprise’s security policy and to
implement necessary controls to
ensure it.
• Request the CSP’s DRP and ensure

that they contain the necessary
countermeasures to protect physical
assets during and after a disaster.
Risk Mapping to
Information Security Governance Threats (cont.)
B. Visibility of The cloud is similar to any infrastructure S1.F • Request the CSP’s detailed schemes of • Appendix E. Detailed Guidance:
the security in that security measures (technology and the technical security measures in place Information Enabler
measures put in processes) should be in place to prevent and determine whether they meet the – E.6 Information Security Requirements
place by the CSP security attacks. The security measures requirements of the enterprise. – E.8 Information Security Review
provided by the CSP should be aligned • Request that the CSP provide proof Reports
with the requirements of the enterprise, of independent security reviews or – E.9 Information Security Dashboard
including management of security certification reports (e.g., AICPA SSAE 16 • Appendix F. Detailed Guidance:
incidents. SOC 2 report or ISO certification). Services, Infrastructure and Applications
• Include in the contract language Enabler
that requires the CSP to provide the – F.10 Monitoring and Alert Services for
enterprise with regular reporting on Security-related Events
security (incident reports, IDS/IPS
logs, etc.).
• Request the CSP’s security incident
management process be applied to the
enterprise’s assets and ensure that it
is aligned with the enterprise’s own
security policy.
C. Media Data media must be disposed in a secure S1.I • Request the CSP’s process and • Appendix B. Detailed Guidance:
management way to avoid data leakage and disclosure. techniques in place for data media Processes Enabler
Data wipeout procedures must ensure disposal and evaluate whether they meet –B .3 Build, Acquire and Implement (BAI)
that data cannot be reproduced when data the requirements of the enterprise. . BAI08 Manage Knowledge.
media support is designated for recycle • Include in the contract language that
or disposal. Controls should be in place requires the CSP to comply with the
during transportation (encryption and enterprise’s security policy
physical security). This should be specified
in the CSP security policy.
73
74
Risk Mapping to
D. Secure software When using SaaS services, the enterprise S3.E • Request the CSP’s details about the • Appendix B. Detailed Guidance:
SDLC must be sure that the applications will software SDLC in place and ensure Processes Enabler
meet its security requirements. This will that the security measures introduced – B.3 Build, Acquire and Implement (BAI)
reduce the risk of disclosure. into the design are compliant with the . BAI03 Manage Solutions Identification
requirements of the enterprise. and Build.
• Request the CSP to provide proof • Appendix E. Detailed Guidance:
of independent security reviews or Information Enabler
certification reports (e.g., AICPA SSAE 16 – E.6 Information Security Requirements
SOC 2 report or ISO certification). • Appendix F. Detailed Guidance:
Services, Infrastructure and Applications
Enabler
– F.3 Secure Development
E. Common Community clouds share resources among D2.C • Ensure that a global security policy • Appendix E. Detailed Guidance:
security policy different entities that belong to the same specifying minimum requirements Information Enabler:
for community group (or community) and thereby possess is applied to all entities sharing a – E.6 Information Security Requirements
clouds a certain level of mutual “trust.” This community cloud. • Appendix A. Detailed Guidance:
trust must be regulated by a common • Request that the CSP provide proof Principles, Policies and Framework
security policy. Otherwise, an attack on the of independent security reviews or Enabler
“weakest link” of the group could place all certification reports (e.g., AICPA SSAE 16 – E.2 Information Security Strategy
the group’s entities in danger. SOC 2 report or ISO certification).
Risk Mapping to
F. Service Currently, there is very little available in S3.G • Ensure by contract or SLA with the CSP • Appendix B. Detailed Guidance:
termination terms of tools, procedures or other offerings an exit strategy that specifies the terms Processes Enabler
issues to facilitate data or service portability that should trigger the retrieval of the – B.2 Align, Plan and Organize (APO)
from CSP to CSP. This can make it very enterprise’s assets in the timeframe . APO09 Manage Service Agreements.
difficult for the enterprise to migrate from required by the enterprise. • Appendix B. Detailed Guidance:
one CSP to another or to bring services • Implement a DRP, taking into account Processes Enabler
back in-house. It can also result in serious the possibility of complete disruption of –B.4 Deliver, Service and Support
business disruption or failure should the the CSP. . DSS04 Manage Continuity.
CSP go bankrupt, face legal action, or be • Appendix G. Detailed Guidance: People,
the potential target for an acquisition (with Skills and Competencies Enabler
the likelihood of sudden changes in CSP – G.3 Information Risk Management
policies and any agreements in place).
Another possibility is the “run on the banks”
scenario, in which there is a crisis of
confidence in the CSP’s financial position,
resulting in a mass exit and withdrawal on
first-come, first-served basis. If there are
limits to the amount of content that can
be withdrawn in a given timeframe, then
the enterprise might not be able to retrieve
all its data in the time specified. Another
possibility may occur if the enterprise
decides, for any reason, to end the
relationship with the CSP. The complexity
of the business logic and data models could
make it literally impossible for the enterprise
to extract its data, reconstruct the business
logic and rebuild the applications.

75
76
Risk Mapping to
G. Solid enterprise Enterprises turn to CSPs in search of S3.I • Ensure that internal governance controls • Appendix B. Detailed Guidance:
governance solutions that can be implemented easily are in place within the enterprise Processes Enabler
and at a low cost. This ease can be to involve the necessary control – B.1 Evaluate, Direct and Monitor (EDM)
tempting, especially when the enterprise organizations (legal, compliance, finance, . EDM01 Ensure Governance
is facing urgent deadlines that require etc.) during the decision process of Framework Setting and Maintenance.
an urgent solution (like the expiration of migrating to cloud services. – B.5 Monitor, Evaluate and Assess (MEA)
application licenses, or the need of more . MEA02 Monitor, Evaluate and Assess
computing capacity). This can become the System of Internal Control.
an issue because organizations may
contract cloud applications without proper
procurement and approval oversight,
thus bypassing compliance with internal
policies.
H. Support for audit Security audits and forensic investigations S1.F • Request of the CSP the right to audit as • Appendix B. Detailed Guidance:
and forensic are vital to the enterprise to evaluate the S1.L part of the contract or SLA. If this is not Processes Enabler
investigations security measures of the CSP (preventive possible, request security audit reports – B.2 Align, Plan and Organise (APO)
and corrective), and in some cases the CSP by trusted third parties. . APO10 Manage Suppliers.
itself (e.g., to authenticate the CSP). This • Request that the CSP provide appropriate – B.5 Monitor, Evaluate and Assess
raises several issues because performing and timely support (logs, traces, hard (MEA)
these actions requires having extensive disk images) for forensic analysis as . MEA02 Monitor, Evaluate and Assess
access to the CSP’s infrastructure and part of the contract or SLA. If this is not the System of Internal Control.
monitoring capabilities, which are often possible, request of the CSP to authorize
shared with other CSP’s customers. The trusted third parties to perform forensic
enterprise should have the permission analysis when necessary.
of the CSP to perform regular audits and
to have access to forensic data without
violating the contractual obligations of the
CSP to other customers.
Abbreviations 77
Abbreviations
Abbreviation Full Term
BCM Business continuity management
CAPEX Capital expenditures—used to acquire or upgrade physical assets such as
buildings, infrastructure and equipment
CIO Chief information officer
CISO Chief information security officer
CSP Cloud service provider
DDoS Distributed denial of service
DRP Disaster recovery plan
IaaS Infrastructure as a Service
IAM Identity and access management
IDS/IPS Intrusion detection system/intrusion prevention system
ISM Information security manager
ISO International Organization for Standardization
OPEX Operating expenditures—ongoing cost for running a product, business or
organization
OS Operating system
PaaS Platform as a Service
QoS Quality of service
RPO Recovery point objective
RTO Recovery time objective
SaaS Software as a Service
SDLC Systems development life cycle
SIEM Security incident and event manager
SLA Service level agreement
SOA Service oriented architecture
TCO Total cost of ownership
VM Virtual machine

References 79
References
ISACA, COBIT 5, USA, 2012
ISACA, COBIT 5 for Information Security, USA, 2012
ISACA, COBIT 5 Implementation, USA, 2012
ISACA, IT Control Objectives for Cloud Computing: Controls and Assurance in

the Cloud, USA, 2011
ISACA, Risk IT Framework for Management of IT Related Business Risks,

ISACA, 2009
Mell, Peter; Timothy Grance; The NIST Definition of Cloud Computing, US

National Institute of Standards and Technology (NIST) Special Publication (SP)
800-145, USA, 2011

Security Considerations Cloud Computing WHP Eng 0912

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Security Considerations Cloud Computing WHP Eng 0912

Uploaded by

Copyright:

Available Formats

1

2 Security Considerations for Cloud Computing

ISACA Board of Directors

ISACA and IT Governance Institute® (ITGI®) Affiliates and Sponsors

3. Overview of Security Risk and Threats Related to

4. The Path to the Decision and Beyond................................................................... 35

Appendix A. The Path to the Decision and Beyond—Checklist.......................... 53

Purpose of This Document

This publication is not intended to provide yet another detailed, theoretical

Who Should Use This Guide?

Scope and Approach

This publication provides practical guidance regarding the decision process

Consequently, this guide is structured as follows:

The essential characteristics of cloud computing are:

Cloud Service Models

Cloud Deployment Models

The Key Element of Trust

Therefore, in considering cloud adoption, it is important to know all the parties

Page intentionally left blank

3. Overview of Security Risk and Threats

Visibility as a Critical Factor

The level of abstraction or visibility provided by the CSP becomes extremely

Figure 1—Cloud Service Models

APIs APIs APIs

Infrastructure as a Service (IaaS)

Infrastructure as a Service (IaaS)

Software as a Service (SaaS)

Platform as a Service (PaaS)

Abstraction Abstraction Abstraction

Hardware Hardware Hardware

Facilities Facilities Facilities

Source: Universal Model, © Cloud Security Alliance. Used with permission.

Information Assets and Risk

Information assets can be roughly categorized as data, applications and processes.

Figure 2—Impact of Risk Events on Assets

Cost Considerations (or Cost as a Risk Event)

For example, an enterprise that has migrated to a CSP possesses a database of

Risk Assessment When Migrating to the Cloud

As mentioned in chapter 1, the scope of this publication is to provide practical

Risk Factors by Service Model

by a client it can be freely reallocated to another enterprise. In that case,

Cloud provider authenticity—Although communications between the

S3.G Exit strategy—Currently, there is very little available in terms of tools,

Risk Factors by Deployment Model

D1. Public Cloud

D2. Community Cloud

D3. Private Cloud

Cloud IT skills required—Affects on-site private clouds. Building a private

D4. Hybrid Cloud

Overview of Threats and Mitigating Actions

Risk-decreasing factors are exploited through the implementation of controls to

• Related guidance in COBIT 5 for Information Security:

• Related guidance in COBIT 5 for Information Security:

Information Security Governance5

• Related guidance in COBIT 5 for Information Security:

D. Secure software SDLC:

H. Support for audit and forensic investigations.

4. The Path to the Decision and Beyond

An overview of the checklist appears in appendix A.

In addition to this publication, practical guidance on implementing best practices

Step 1. Preparation of the Internal Environment

Besides selecting deployment and service models, an enterprise must do some

3. Overview of Security Risk and Threats Related to

S3.G Exit strategy—Currently, there is very little available in terms of tools,

• Request the CSP’s DRP and ensure