1

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 materials 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: [email protected]
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 DAngelo, 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

Security Considerations for Cloud Computing

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, DeutschePostDHL, 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

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

Security Considerations for Cloud Computing

Appendix A. The Path to the Decision and BeyondChecklist.......................... 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

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 haveand for some enterprises
already hasa 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 publications discussion of
risk and threats is limited to cloud-specific elements.)

Security Considerations for Cloud Computing

Consequently, this guide is structured as follows:
Chapter 2Cloud 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 3Overview of security risk and threats related to operating in the cloud,
structured by service and deployment model
Chapter 4The 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

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-serviceComputing capabilities can be provisioned without
human interaction from the service provider.
Broad network accessComputing capabilities are available over the network
and can be accessed by diverse client platforms.
Resource poolingComputer resources are pooled to support a multitenant model.
Rapid elasticityResources can scale up or down rapidly and in some cases
automatically in response to business demands.
Measured serviceResource 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

 10

Security Considerations for Cloud Computing

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 modelsalso frequently referred
to as cloud structures:
Public cloudThe 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 cloudThe 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 cloudThe infrastructure can be used only by one single enterprise. As
for community clouds, it can be deployed onsite or offsite enterprise premises.
Hybrid cloudThe 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

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 CSPs mitigating controls to handle riskcontrols 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 ISACAs 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 users 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.

11

 12

Security Considerations for Cloud Computing

Page intentionally left blank

3. Overview of Security Risk and Threats

Related to Operating in the Cloud

3. Overview of Security Risk and Threats

Related to Operating in the Cloud
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 enterprisethe owner
of the assetsis 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.

13

 14

Security Considerations for Cloud Computing

Figure 1Cloud Service Models

Data and Application
Security Risk
Per SLA
SaaS

Software as a Service

Client Assumes
All Data and Application
Security Risk

Presentation
Modality

Applications

Abstraction
Hardware
Facilities

Data

Integration and Middleware

Integration and Middleware

APIs
Core Connectivity
and Delivery
Abstraction
Hardware
Facilities

Infrastructure as a Service (IaaS)

Platform as a Service (PaaS)

APIs
Core Connectivity
and Delivery

Infrastructure as a Service (IaaS)

Infrastructure as a Service

Platform as a Service

Metadata

Content

APIs
Core Connectivity
and Delivery
Abstraction
Hardware
Facilities

Infrastructure as a Service (IaaS)

Platform as a Service (PaaS)
Software as a Service (SaaS)

PaaS

IaaS

Presentation
Platform

APIs

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
UnavailabilityThe 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 clients data are
subject to legal investigation).
LossThe asset is lost or destroyed. The cause can be accidental (natural disaster,
wrong manipulation, etc.) or intentional (deliberate destruction of data).
TheftThe asset has been intentionally stolen and is now in possession of another
individual/enterprise. Theft is a deliberate action that can involve data loss.
DisclosureThe 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 SACAs 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.

3. Overview of Security Risk and Threats

Related to Operating in the Cloud

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 2Impact of Risk Events on Assets
Type

Unavailability

Loss

Data

Disruption of
activities; lack of
resources to keep
on with business
as usual;
possibility of data
poisoning

Applications/
processes

Disruption of
activities; lack of
resources to keep
on with business
as usual

Disruption of
activities; required
activation of
backup restore
procedures (DRP);
possibility of partial
loss of the asset
(depending on
the recovery point
objective [RPO]);
financial loss
associated with
recovery efforts

Theft
Business
competitive
disadvantage;
possibility of
blackmail; loss
of credibility with
customers/clients

Disclosure
Damage to
company
reputation or
image; possibility
of regulatory
sanctions;
financial impact

Higher risk/threat of more selective

attacks to data

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.

15

 16

Security Considerations for Cloud Computing

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.

3. Overview of Security Risk and Threats

Related to Operating in the Cloud

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 elasticityLack 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 affectedUnavailability
S1.B 
DRP and backupCSPs 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 affectedUnavailability, loss
S1.C 
Patch managementCloud 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 affectedUnavailability, loss, theft, disclosure
Risk-increasing factors:
S1.D 
Legal transborder requirementsCSPs 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 CSPs infrastructure without the necessary compliance controls.
Furthermore, government entities in the hosting country may require access
to the enterprises information with or without proper notification.
Risk affectedDisclosure
S1.E 
Multitenancy and isolation failureOne 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

17

 18

Security Considerations for Cloud Computing

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 affectedTheft, disclosure
S1.F 
Lack of visibility surrounding technical security measures in placeFor 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.
Risk affectedUnavailability, loss, theft, disclosure
S1.G Absence of DRP and backupThe 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 enterprises business needs (in
terms of RTO/RPO).
Risk affectedUnavailability, loss
S1.H 
Physical securityIn an IaaS model, physical computer resources are
shared with other entities in the cloud. If physical access to the CSPs
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.
Risk affectedTheft, disclosure
S1.I 
Data disposalProper 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 affectedDisclosure
S1.J 
Offshoring infrastructureOffshoring 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.
Risk affectedUnavailability, loss, theft, disclosure
S1.K 
Virtual machine (VM) security maintenanceIaaS 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.
Risk affectedUnavailability, loss, theft, disclosure

3. Overview of Security Risk and Threats

Related to Operating in the Cloud

S1.L 
Cloud provider authenticityAlthough communications between the
enterprise and the cloud provider can be secured with technical means
(encryption, virtual private network [VPN], mutual authentication, etc.) it is
the consumers responsibility to check the identity of the cloud provider to
ensure that it is not an imposter.
Risk affectedUnavailability, loss, theft, disclosure
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 timeUsing 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.
Risk affectedUnavailability, loss
Risk-increasing factors:
S2.B 
Application mappingIf current applications are not perfectly aligned with
the capabilities provided by the CSP, additional undesirable features (and
vulnerabilities) could be introduced.
Risk affectedTheft, disclosure
S2.C 
SOA-related vulnerabilitiesSecurity 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.
Risk affectedUnavailability, loss, theft, disclosure
S2.D 
Application disposalWhen 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.
Risk affectedTheft, disclosure

19

 20

Security Considerations for Cloud Computing

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.
Risk-decreasing factors:
S3.A Improved securityCSPs 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).
Risk affectedUnavailability, loss
S3.B 
Application patch managementDue 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.
Risk affectedUnavailability, loss
Risk-increasing factors:
S3.C 
Data ownershipThe 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 affectedUnavailability, loss, disclosure
S3.D 
Data disposalIn the event of a contract termination, the data fed into the
CSPs application must be erased immediately using the necessary tools to
avoid disclosures and confidentiality breaches (forensic cleaning may be
required for sensitive data).
Risk affectedTheft, disclosure
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.
Risk affectedUnavailability, loss, theft, disclosure
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 customers data.
Risk affectedLoss, theft, disclosure

3. Overview of Security Risk and Threats

Related to Operating in the Cloud

S3.G 
Exit strategyCurrently, 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.
Risk affectedUnavailability, loss
S3.H 
Broad exposure of applicationsIn 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 affectedUnavailability, loss, disclosure
S3.I 
Ease to contract SaaSBusiness organizations may contract cloud
applications without proper procurement and approval oversight, thus
bypassing compliance with internal enterprise policies.
Risk affectedUnavailability, loss, theft, disclosure
S3.J Lack of control of the release management processAs 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.
Risk affectedUnavailability, loss
S3.K 
Browser vulnerabilitiesAs 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 customers browser becomes infected, the access to the
application can be compromised as well.
Risk affectedTheft, disclosure

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, CSPs third-party service
providers, etc.) is an important factornot just trust between the CSP and the
customer, but enough trust in the other tenants sharing computing resources

21

 22

Security Considerations for Cloud Computing

hosting the enterprises 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.
Risk-decreasing factors:
D1.A 
Public reputationProviders 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.
Risk affectedUnavailability, loss, theft, disclosure
Risk-increasing factors:
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.
Risk affectedUnavailability, loss, theft, disclosure
D1.C Collateral damageIf 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.
Risk affectedUnavailability, loss, theft, disclosure
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.
Risk-decreasing factors:
D2.A 
Same group of entitiesThe 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.)
Risk affectedUnavailability, loss, theft, disclosure
D2.B Dedicated access for the communityDedicated access can be configured
for authorized community users only.
Risk affectedTheft, disclosure

3. Overview of Security Risk and Threats

Related to Operating in the Cloud

Risk-increasing factor:
D2.C 
Sharing of the cloudDifferent 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 affectedLoss, 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.
Risk-decreasing factors:
D3.A 
Can be built on-premisesPhysical or location-related considerations can
be more closely controlled by the enterprise because the cloud infrastructure
can be located on the enterprises premises. Global enterprise security
policies would apply.
Risk affectedUnavailability, loss, theft, disclosure
D3.B PerformanceAffects on-site private clouds. Because the private cloud is
deployed inside the firewall on the enterprises 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.
Risk affectedUnavailability, loss
Risk-increasing factors:
D3.C 
Application compatibilityWhile 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.
Risk affectedUnavailability, loss
D3.D Investments requiredMaking 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 affectedCost

23

 24

Security Considerations for Cloud Computing

D3.E 
Cloud IT skills requiredAffects on-site private clouds. Building a private
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 affectedCost
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-interdependencyIf 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?
Risk affectedUnavailability, loss, theft, disclosure

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 ISACAs 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.

3. Overview of Security Risk and Threats

Related to Operating in the Cloud

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 enterprises information, naming specific roles for CSP employees
and external partners.
Request that the CSP provide detailed technical specifications of its IAM
system for the enterprises CISO (or equivalent authority) to review and
approve. If necessary, include additional controls to ensure robustness of the
CSPs 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 CSPs IAM systems).
Use corporate IAM systems instead of CSPs 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:
A contractual agreement is necessary to officially clarify who is allowed to
access the enterprises information, naming specific roles for CSP employees
and external partners. All controls protecting the enterprises 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 CSPs 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.

25

 26

Security Considerations for Cloud Computing

Related guidance in COBIT 5 for Information Security:
Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:
. G.3 Information Risk Management
. G.6 Information Assessment and Testing and Compliance
Appendix F. Detailed Guidance: Services, Infrastructure and Applications
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 CSPs technical details for CISO (or equivalent authority) approval
and require additional controls to ensure data privacy, when necessary.
A
 contractual agreement is necessary to officially clarify who is allowed to
access the enterprises information, naming specific roles for CSP employees
and external partners. All controls protecting the enterprises information
assets must be clearly documented in the contract agreement or SLA.
U
 se a private cloud deployment model (no multitenancy).
Related guidance in COBIT 5 for Information Security:
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)
Appendix F. Detailed Guidance: Services, Infrastructure and Applications
Enabler:
. F.10 Monitoring and Alert Services for Security-related Events
D. Hypervisor attacks:
Related risk factor: S1.E
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 CSPs 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.

3. Overview of Security Risk and Threats

Related to Operating in the Cloud

Related guidance in COBIT 5 for Information Security:

Appendix B. Detailed Guidance: Processes Enabler:
. B.2 Align, Plan and Organize: APO09 Manage Service Agreements
Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:
. G.3 Information Risk Management
A
 ppendix A. Detailed Guidance: Principles, Policies and Framework Enabler:
. A.2 Information Security Policy
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 antimalware 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.
Related guidance in COBIT 5 for Information Security:
Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:
. G.5 Information Security Operations
. G.6 Information Assessment and Testing and Compliance
Appendix F. Detailed Guidance: Services, Infrastructure and Applications
Enabler:
. F.10 Monitoring and Alert Services for Security-related Events
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.
Related guidance in COBIT 5 for Information Security:
Appendix B. Detailed Guidance: Processes Enabler:
. B.3 Build, Acquire and Implement: BAI02 Manage Requirements
Definition
Appendix E. Detailed Guidance: Information Enabler:
. E.6 Information Security Requirements
Appendix F. Detailed Guidance: Services, Infrastructure and Applications
Enabler:
. F.3 Secure Development

27

 28

Security Considerations for Cloud Computing

G. Collateral damage
Related risk factor: D1.C
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 enterprises
contracted capacity is always available and cannot be directed to other
tenants without approval.
Use a private cloud deployment model (no multitenancy).
Related guidance in COBIT 5 for Information Security:
Appendix E. Detailed Guidance: Information Enabler:
. E.6 Information Security Requirements
Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:
. G.3 Information Risk Management
Appendix F. Detailed Guidance: Services, Infrastructure and Applications
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.
Related guidance in COBIT 5 for Information Security:
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
Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:
. 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.

3. Overview of Security Risk and Threats

Related to Operating in 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.
Related guidance in COBIT 5 for Information Security:
Appendix A. Detailed Guidance: Principles, Policies and Framework
Enabler:
. A.2 Information Security Policy
Appendix F. Detailed Guidance: Services, Infrastructure and Applications
Enabler:
. F.5 Adequately Secured and Configured Systems, Aligned With Security
Requirements and Security Architecture
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.
Related guidance in COBIT 5 for Information Security:
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 enterprises 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 CSPs 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
enterprises review.
Related guidance in COBIT 5 for Information Security:
Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:
. G.3 Information Risk Management
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.

29

 30

Security Considerations for Cloud Computing

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 CSPs list of infrastructure locations and verify that regulation in
those locations is aligned with the enterprises requirements.
Include terms in the service contract to restrict the moving of enterprise
assets to only those areas known to be compliant with the enterprises own
regulation.
To prevent disclosure, encrypt any asset prior to migration to the CSP, and
ensure proper key management is in place.
Related guidance in COBIT 5 for Information Security:
Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:
. G.4 Information Security Architecture Development
. G.6 Information Assessment and Testing and Compliance
Appendix F. Detailed Guidance: Services, Infrastructure and Applications
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
CSPs staff, which is subject to the CSPs security policy. There could be a gap
between the security measures provided by the CSP and the requirements of
the enterprise.
Mitigation:
Request the CSPs physical security policy and ensure that it is aligned with
the enterprises security policy.
Request that the CSP provide proof of independent security reviews or
certification reports that meet the enterprises 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
enterprises security policy and to implement necessary controls to ensure it.
Request the CSPs 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.

3. Overview of Security Risk and Threats

Related to Operating in the Cloud

Related guidance in COBIT 5 for Information Security:

Appendix E. Detailed Guidance: Information Enabler
. E.6 Information Security Requirements
A
 ppendix A. Detailed Guidance: Principles, Policies and Frameworks Enabler
. A.2 Information Security Policy
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 CSPs detailed schemes of the technical security measures in
place and determine whether they meet the requirements of the enterprise.
Request that the CSP provide proof of independent security reviews or
certification reports that meet the enterprises 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 provide the
enterprise regular reporting on security (incident reports, intrusion detection
system [IDS]/intrusion prevention system [IPS] logs, etc.).
Request the CSPs security incident management process to be applied to
the enterprises assets and ensure that it is aligned with the enterprises own
security policy.
Related guidance in COBIT 5 for Information Security:
Appendix E. Detailed Guidance: Information Enabler
. E.6 Information Security Requirements
. E.8 Information Security Review Reports
. E.9 Information Security Dashboard
A
 ppendix F. Detailed Guidance: Services, Infrastructure and Applications
Enabler:
. F.10 Monitoring and Alert Services for Security-related Events
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 CSPs 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
enterprises security policy.
Related guidance in COBIT 5 for Information Security:
Appendix B. Detailed Guidance: Processes Enabler
. B. 3 Build, Acquire and Implement: BAI08 Manage Knowledge

31

 32

Security Considerations for Cloud Computing

D. Secure software SDLC:
Related risk factor: S3.E
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 CSPs 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.
Request that the CSP provide proof of independent security reviews or
certification reports that meet the enterprises compliance requirements (e.g.,
AICPA SSAE 16 SOC 2 report, SOX, PCI DSS, HIPAA, ISO certification).
Related guidance in COBIT 5 for Information Security:
Appendix B. Detailed Guidance: Processes Enabler:
. B. 3 Build, Acquire and Implement: BAI03 Manage Solutions
Identification and Build
Appendix E. Detailed Guidance: Information Enabler:
. E.6 Information Security Requirements
Appendix F. Detailed Guidance: Services, Infrastructure and Applications
Enabler:
. F.3 Secure Development
E. Common security policy for community clouds:
Related risk factor: D2.C
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
groups entities in danger.
Mitigation:
Ensure that a global security policy specifying minimum requirements is
applied to all entities sharing a community cloud.
Request that the CSP provide proof of independent security reviews or
certification reports that meet the enterprises compliance requirements (e.g.,
AICPA SSAE 16 SOC 2 report, SOX, PCI DSS, HIPAA, ISO certification).
Related guidance in COBIT 5 for Information Security:
Appendix E. Detailed Guidance: Information Enabler:
. E.6 Information Security Requirements
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

3. Overview of Security Risk and Threats

Related to Operating in the Cloud

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 CSPs 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 enterprises assets in the time
frame required by the enterprise.
Implement a DRP, taking into account the possibility of complete CSP
disruption.
Related guidance in COBIT 5 for Information Security:
Appendix B. Detailed Guidance: Processes Enabler:
. B.2 Align, Plan and Organize: APO09 Manage Service Agreements
Appendix B. Detailed Guidance: Processes Enabler:
. B.4 Deliver, Service and Support: DSS04 Manage Continuity
Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:
. G.3 Information Risk Management
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.
Related guidance in COBIT 5 for Information Security:
Appendix B. Detailed Guidance: Processes Enabler:
. 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

33

 34

Security Considerations for Cloud Computing

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
CSPs infrastructure and monitoring capabilities, which are often shared with
other CSPs 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.
Related guidance in COBIT 5 for Information Security:
Appendix B. Detailed Guidance: Processes Enabler:
. 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

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 ISACAs 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 frameworksWhich 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.

35

 36

Security Considerations for Cloud Computing

ProcessesHow will moving to the cloud influence the enterprises processes?
Which processes depend on assets that could move to the cloud? Are these
processes considered to be critical for the business?
Organizational structuresHow will the relationship with the CSP be
managed? How are roles and responsibilities defined?
Culture, ethics and behaviourHow will change within the enterprise be
managed? How can an information culture be imposed upon the CSP?
InformationWhich 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 applicationsWhich service capabilities are
expected of the CSP? How will performance be measured? How will issues
be reported?
People, skills and competenciesWhich 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 enterprises 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.

4. The Path to the Decision and Beyond

Figure 3Decision Tree: Choosing a Service Model

1. Is the business process a

nonstandard solution?

2. Interdependencies
with other
business processes?

7. Business driver
cloud-compatible?

SaaS

3. Difference from standard

solutions IT-based?

4. Applications/hardware/OS
custom?

5. Hardware/OS custom?

PaaS

6. Hardware custom?

A cloud solution is probably

not the best solution for
your business needs.

IaaS

A cloud solution is probably

not the best solution for
your business needs.

37

 38

Security Considerations for Cloud Computing

Breakdown of Cloud Service Model Decision Tree
Figure 4 provides a breakdown of the cloud service model decision tree.
Figure 4Breakdown 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

solutions, then a further drilling down is
needed to determine whether the business
process is suitable for a cloud solution.

Question 2: Interdependencies with

business processes?

No

If a standard solution is used, then the

transition to the cloud is relatively easy and
the benefits of adopting a cloud solution
will most likely be high.

Question 7: Business driver

cloud-compatible?

2. Interdependencies with business processes?

Yes

If there are interdependencies with

different business processes, then any
alteration to one of these processes
could mean a change to the application
implemented in the cloud.

Question 3: Difference from standard

solutions IT-based?

No

If there are no interdependencies,

then changes will not be required. The
chosen cloud solution will, therefore, be
independent.

Question 7: Business driver

cloud-compatible?

3. Difference from standard solutions IT-based?

Yes

Question 4: Applications/hardware/OS
While interdependency may implicate a
custom?
change in the IT infrastructure, it is not
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

solutions, then the standard offerings of a
CSP will adequately address the business
needs.

Question 7: Business driver

cloud-compatible?

4. Application/hardware/OS custom?
Yes

Once it is established that there is indeed

a gap between the business needs and the
cloud service offerings, it is important to
define the level on which the difference is
situated.

Question 5: Hardware/OS custom?

No

If the differentiation is situated in the

configuration of standard applications, then
cloud offerings will fulfill the business needs.

Question 7: Business driver

cloud-compatible?

4. The Path to the Decision and Beyond

Figure 4Breakdown of Cloud Service Model Decision Tree (cont.)

Answer

Explanation

Next Question

5. Hardware/OS custom?
Yes

After establishing that the difference is

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.

Question 6: Hardware custom?

No

If the differentiation can be done on

application level, no further drill-down is
needed.

Solution: PaaS

6. Hardware custom?
Yes

Solution: A cloud solution is probably not

After establishing that the differentiation
the best solution for your business needs.
is located on the physical level, a cloud
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 CSPs
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

level, no further drill-down is needed.

Solution: IaaS

7. Business driver cloud-compatible?

Yes

Viable business drivers for the cloud

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.

Solution: SaaS

No

While there may be no technical

constraints to adopting the cloud as a
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.

Solution: A cloud solution is probably not

the best solution for your business needs.

39

 40

Security Considerations for Cloud Computing

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.

6. Predictable?

5. Adequate
infrastructure?

3. More than
data?

2. Critical
data?

1. Sensitive
data?

Start

7. Legal/compliance
impediments?

13. Can upgrade?

4. Business
process critical?

14. SLA?

Full cloud may not

be the best solution.
Hybrid cloud may
be considered.

10. SLA?

Y
9. Jurisdiction?

8. Data
ownership?

Cloud may
not be the
best solution.

12. In-house
DRP/BCM?

21. Can upgrade?

N
Y

Public cloud

11. Cost
efficient?

19. Data
ownership?

18. Legal/
compliance
impediments?

20. Jurisdiction?

17. Predictable?

16. Adequate
infrastructure?

15. Cost
efficient?
Y

22. SLA?

N
Y

Cloud may
not be the
best solution.

Private cloud

23. Cost
efficient?

4. The Path to the Decision and Beyond

Figure 5Decision Tree: Choosing a Deployment Model

41

 42

Security Considerations for Cloud Computing

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

Explanation

Next Question

1. Sensitive data?
Yes

When considering a move to a cloud

infrastructure it is very important to be
aware what data are to be released to
the cloud.

Question 14: SLA?

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:

Blueprints
Formulas
Trade secrets
Any information absolutely necessary
for the enterprise to operate

Question 14: SLA?

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

the cloud.

Question 3: More than data?

3. More than data?

Yes

In almost all cases the decision to move

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.

Question 4: Business process critical?

No

If the decision to move to the cloud is

limited to data only, the next step is to
evaluate the enterprises readiness for
this move.

Question 5: Adequate infrastructure?

4. The Path to the Decision and Beyond

Figure 6Breakdown of Cloud Deployment Decision Tree (cont.)

Answer

Explanation

Next Question

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

application is not considered critical, it may
be easier to move to the cloud.

Question 5: Adequate infrastructure?

5. Adequate infrastructure?
Yes

A move to the cloud is a step toward

reducing the enterprises 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)

Question 6: Predictable?

No

If it is determined that the current

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).

Question 13: Can upgrade?

6. Predictable?
Yes

As part of the readiness assessment the

enterprise must determine how business
processes function and mature. This
information can help anticipate capacity
fluctuations (up or down) that must be part
of the contract with the CSP.

Question 7: Legal/compliance
impediments?

No

When the enterprise cannot anticipate

capacity fluctuations, further analysis
may be needed. Flexibility and scalability
are two of the cloud characteristics that
make it attractivea flexible SLA may be
the solution until the enterprise has more
refined requirements.

Question 10: SLA?

43

 44

Security Considerations for Cloud Computing

Figure 6Breakdown of Cloud Deployment Decision Tree (cont.)

Answer

Explanation

Next Question

7. Legal/compliance impediments?
Yes

There may be legal or compliance reasons

why data or certain business functions
cannot be moved to the cloud.

Question 10: SLA?

It is important for the CSP to implement

the necessary controls to ensure the
enterprises 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
enterprises expectations and how they will
be satisfied.
No

If the enterprise does not have any legal or

compliance impediments, the next steps to
move to the cloud can be taken.

Question 8: Data ownership?

8. Data ownership?
Yes

The contract with the CSP should

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.

Question 10: SLA?

If data ownership cannot be properly

established, the enterprise may choose
to move only nonsensitive and noncritical
data.
No

Question 9: Jurisdiction?
If the enterprise can clearly define data
ownership during contract negotiations, the
next steps to move to the cloud can
be taken.

4. The Path to the Decision and Beyond

Figure 6Breakdown of Cloud Deployment Decision Tree (cont.)

Answer

Explanation

Next Question

9. Jurisdiction?
Yes

Even though data ownership resides with

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 CSPs data storage facilities and
data processing centers to prevent legal
infractions.

Question 10: SLA?

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

limitations, the cloud may be a proper
solution.

Solution: Public cloud

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

upon, moving to the cloud could pose an
unacceptable level of risk.
If the cost of the SLA is greater than the
business driver, the cloud solution may not
be the best solution.

Solution: Cloud computing may not be

the best solution for your current business
needs.

45

 46

Security Considerations for Cloud Computing

Figure 6Breakdown of Cloud Deployment Decision Tree (cont.)

Answer

Explanation

Next Question

11. Cost efficient?

Yes

Two of the principal goals of moving to the

cloud are becoming more cost effective
and being able to react more quickly and
inexpensively to changing situations.

Solution: Public cloud

No

Unless the business driver is greater than

the cost, an expensive solution may not be
the right option.

Solution: Cloud computing may not be

the best solution for your current business
needs.

12. In-house DRP/BCM?

Yes

Question 16: Adequate infrastructure?

This question may already be addressed
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
enterprises 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

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).

Question 6: Predictable?

No

If the cost to upgrade the current

infrastructure is greater than the business
needs, the cloud may not be a solution yet.

Solution: Cloud computing may not be

the best solution for your current business
needs.

4. The Path to the Decision and Beyond

Figure 6Breakdown of Cloud Deployment Decision Tree (cont.)

Answer

Explanation

Next Question

14. SLA?
Yes

The enterprise must determine in advance

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.

Question 15: Cost efficient?

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

on, moving to the cloud can pose an
unacceptable level of risk.

Solution: Full cloud may not be the best

solution. Hybrid cloud may be considered.

If the cost of the SLA is greater than the

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 computingsensitive or
critical components can remain within the
enterprises 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

cloud are becoming more cost effective
and being able to react more quickly and
inexpensively to changing situations.

Question 16: Adequate infrastructure?

No

Unless the business driver is greater than

the cost, an expensive solution may not
be the right option; however, a hybrid
cloud solution can still provide some of the
benefits of cloud computingsensitive or
critical components can remain within the
enterprises premises or a private cloud,
while nonsensitive or noncritical ones can
be moved to a public cloud.

Solution: Full cloud may not be the best

solution. Hybrid cloud may be considered.

47

 48

Security Considerations for Cloud Computing

Figure 6Breakdown of Cloud Deployment Decision Tree (cont.)

Answer

Explanation

Next Question

16. Adequate infrastructure?

Yes

A move to the cloud is a step toward

reducing the enterprises 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)

Question 17: Predictable?

No

If it is determined that the current

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).

Question 21: Can upgrade?

17. Predictable?
Yes

As part of the readiness assessment the

enterprise must determine how business
processes function and mature. This
information can help anticipate capacity
fluctuations (up or down) that must be part
of the contract with the CSP.

Question 18: Legal/compliance

impediments?

No

When the enterprise cannot anticipate

capacity fluctuations, further analysis
may be needed. Flexibility and scalability
are two of the cloud characteristics that
make it attractivea flexible SLA may be
the solution until the enterprise has more
refined requirements.

Question 22: SLA?

4. The Path to the Decision and Beyond

Figure 6Breakdown of Cloud Deployment Decision Tree (cont.)

Answer

Explanation

Next Question

18. Legal/compliance impediments?

Yes

There may be legal or compliance reasons

why data or certain business functions
cannot be moved to the cloud.

Question 22: SLA?

It is important for the CSP to implement

the necessary controls to ensure the
enterprises 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
enterprises expectations and how they will
be satisfied.
No

If the enterprise does not have any legal or

compliance impediments, the next steps to
move to the cloud can be taken.

Question 19: Data ownership?

19. Data ownership?

Yes

The contract with the CSP should

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.

Question 22: SLA?

If data ownership cannot be properly

established, the enterprise may choose
to move only nonsensitive and noncritical
data.
No

Question 20: Jurisdiction?

If the enterprise can clearly define data
ownership during contract negotiations, the
next steps to move to the cloud can
be taken.

49

 50

Security Considerations for Cloud Computing

Figure 6Breakdown of Cloud Deployment Decision Tree (cont.)

Answer

Explanation

Next Question

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 CSPs 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

limitations, the cloud may be a proper
solution.

Solution: Private cloud

21. Can upgrade?

Yes

If it is determined that the current 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).

Question 17: Predictable?

No

If the cost to upgrade the current

infrastructure is greater than the business
needs, the cloud may not be a solution yet.

Solution: Cloud computing may not be

the best solution for your current business
needs.

4. The Path to the Decision and Beyond

Figure 6Breakdown of Cloud Deployment Decision Tree (cont.)

Answer

Explanation

Next Question

22. SLA?
Yes

The enterprise must determine in advance Question 23: 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

on, moving to the cloud can pose an
unacceptable level of risk.

Solution: Cloud computing may not be

the best solution for your current business
needs.

If the cost of the SLA is greater than the

business driver, the cloud solution may not
be the best solution.
23. Cost efficient?
Yes

Two of the principal goals of moving to the

cloud are becoming more cost effective
and being able to react more quickly and
inexpensively to changing situations.

Solution: Private cloud

No

Unless the business driver is greater than

the cost, an expensive solution may not be
the right option.

Solution: Cloud computing may not be

the best solution for your current business
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

51

 52

Security Considerations for Cloud Computing

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 enterpriseStoring 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 CSPSince 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 storedLocal laws apply to the CSPs 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 processedIn 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 CSPs 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

and BeyondChecklist

Appendix A. The Path to the Decision

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

Prior to move to the cloud:

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.

Cloud provider check and requests:

2.1

Request the CSPs security policy and ensure that it is aligned with the
enterprises security policy.

2.2

Request the CSPs list of infrastructure locations and verify that regulation in
those locations is aligned with the enterprises requirements.

2.3

Request the CSPs 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 CSPs technical details and additional controls to ensure data
privacy for CIO and CISO approval.

2.5

Request that the CSPs security incident management process be applied to

the enterprises assets and ensure that it is aligned with the enterprises
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 CSPs 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 CSPs detailed technical specifications of the access management

system in place for CIO and CISO approval and include additional controls to
ensure robustness of the CSPs access management system.

2.9

Request the CSPs technical specifications and controls to ensure that the data
are properly wiped out when requested.

53

 54

Security Considerations for Cloud Computing

Figure 7Cloud Considerations Checklist (cont.)

2

Cloud provider check and requests: (cont.)

2.10

Request the CSPs process and techniques in place for data storage media
disposal and evaluate that they meet the requirements of the enterprise.

2.11

Request the CSPs 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 CSPs information about the software release management

and patch management process in place and check if it is aligned with the
enterprise needs.

Contract terms:

3.1

Ensure that the CSP is aligned with the enterprises 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 enterprises 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 enterprises
approval on contract expiration.

3.7

Ensure that the CSP is compliant with the enterprises 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 enterprises assets in the time frame required by
the enterprise.

Preventive measures:

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 CSPs
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.

Scalability/
elasticity

Disaster
recovery and
backup

Patch
management

S1.B

S1.C

Risk Factor

S1.A

IaaS

Code

Unavailability

Loss

Theft

Risk Event

Disclosure

Decreasing

Decreasing

Decreasing

Type

Description

Cloud infrastructures are 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.

CSPs should already have in place, as common practice, disaster

recovery and backup procedures. However, RPO, RTO, and backup
testing frequency and procedures provided by the CSP should be
consistent with the enterprise security policy.

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).

Figure 8Risk Factors of Cloud Service and Deployment Models

Figure 8 provides an overview of cloud service and deployment model risk.

Appendix B. Overview of Different Risk Factors per Service and

Deployment Model

Appendix B. Overview of Different Risk Factors
per Service and Deployment Model
55

Risk Factor

Legal
transborder
requirements

Multitenancy
and isolation
failure

Lack of visibility
surrounding
technical
security
measures in
place

S1.D

S1.E

S1.F

IaaS (cont.)

Code

Unavailability

Loss

Theft

Risk Event

Disclosure

Increasing

Increasing

Increasing

Type

Description

For any infrastructure, IDS/IPS and 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.

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 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).

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 or transmitting data
within the CSPs infrastructure without the necessary compliance
controls. Furthermore, government entities in the hosting country may
require access to the enterprises information, with or without proper
notification.

Figure 8Risk Factors of Cloud Service and Deployment Models (cont.)

56
Security Considerations for Cloud Computing

Risk Factor

Absence of DRP
and backup

Physical security

Data disposal

Offshoring
infrastructure

S1.G

S1.H

S1.I

S1.J

IaaS (cont.)

Code

Unavailability

Loss

Theft

Risk Event

Disclosure

Increasing

Increasing

Increasing

Increasing

Type

Description

The move to offshoring of key infrastructure expands the attack

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.

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.

In an IaaS model, physical compute resources are shared with other

entities in the cloud. If physical access to the CSPs 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.

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 enterprises business needs (in terms of
RTO/RPO).

Figure 8Risk Factors of Cloud Service and Deployment Models (cont.)

Appendix B. Overview of Different Risk Factors
per Service and Deployment Model
57

Risk Factor

Cloud provider
authenticity

S1.L

Short
development
time

Application
mapping

SOA-related
vulnerabilities

Application
disposal

S2.A

S2.B

S2.C

S2.D

PaaS

VM security
maintenance

S1.K

IaaS (cont.)

Code

Unavailability

Loss

Theft

Risk Event

Disclosure

Increasing

Increasing

Increasing

Decreasing

Increasing

Increasing

Type

Description

When applications are developed in a PaaS environment, originals

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.

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.

If current applications are not perfectly aligned with the capabilities

provided by the CSP, additional undesirable features (and
vulnerabilities) could be introduced.

Using the SOA library provided by the CSP, applications can be

developed and tested within a reduced timeframe because SOA
provides a common framework for application development.

Although communications between the enterprise and the cloud

provider can be secured with technical means (encryption, VPN,
mutual authentication, etc.) it is a consumers responsibility to check
the identity of the cloud provider to ensure that is not an imposter.

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.

Figure 8Risk Factors of Cloud Service and Deployment Models (cont.)

58
Security Considerations for Cloud Computing

Improved
security

Application
patch
management

Data ownership

Data disposal

Lack of visibility
into software
SDLC

S3.B

S3.C

S3.D

S3.E

Risk Factor

S3.A

SaaS

Code

Unavailability

Loss

Theft

Risk Event

Disclosure

Increasing

Increasing

Increasing

Decreasing

Decreasing

Type

Description

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.

In the event of a contract termination, the data fed into the CSPs
application must be erased immediately using forensic tools to avoid
disclosures and confidentiality breaches.

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.

Application patch managementDue 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.

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).

Figure 8Risk Factors of Cloud Service and Deployment Models (cont.)

Appendix B. Overview of Different Risk Factors
per Service and Deployment Model
59

Risk Factor

IAM

Exit strategy

Broad exposure
of applications

S3.F

S3.G

S3.H

SaaS (cont.)

Code

Unavailability

Loss

Theft

Risk Event

Disclosure

Increasing

Increasing

Increasing

Type

Description

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 are required.

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.

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 customers data.

Figure 8Risk Factors of Cloud Service and Deployment Models (cont.)

60
Security Considerations for Cloud Computing

Risk Factor

Lack of control
of the release
management
process

Browser
vulnerabilities

S3.J

S3.K

Public
reputation

Full sharing of
the cloud (data
pooling)

D1.A

D1.B

Public Cloud

Ease to contract
SaaS

S3.I

SaaS (cont.)

Code

Unavailability

Loss
X

Theft

Risk Event

Disclosure

Increasing

Decreasing

Increasing

Increasing

Increasing

Type

Description

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 interests and
concern for security.

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 because a secure provider or customers will simply
move elsewhere.

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 customers browser becomes infected, the access to
the application can be compromised as well.

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 merely
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.

Business organizations may contract cloud applications without

proper procurement and approval oversight, thus bypassing
compliance with internal enterprise policies.

Figure 8Risk Factors of Cloud Service and Deployment Models (cont.)

Appendix B. Overview of Different Risk Factors
per Service and Deployment Model
61

Risk Factor

Collateral
damage

Dedicated
access for the
community

Sharing of the
cloud

D2.B

D2.C

D3.A

Can be built
on-premise

Private Cloud

Same group of
entities

D2.A

Community Cloud

D1.C

Public Cloud (cont.)

Code

Unavailability

Loss

Theft

Risk Event

Disclosure

Decreasing

Increasing

Decreasing

Decreasing

Increasing

Type

Description

Physical or location-related considerations can be more closely

controlled by the enterprise because the cloud infrastructure can
be located on the enterprises premises. Global enterprise security
policies would apply.

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.

Dedicated access can be configured for authorized community

users only.

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.)

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.

Figure 8Risk Factors of Cloud Service and Deployment Models (cont.)

62
Security Considerations for Cloud Computing

Risk Factor

Performance

Application
compatibility

Investments
required

D3.B

D3.C

D3.D

Private Cloud (cont.)

Code

(can be
triggered by
cost)

Unavailability

Theft

(can be (can be
triggered triggered
by cost) by cost)

Loss

Risk Event

(can be
triggered
by cost)

Disclosure

Increasing

Increasing

Decreasing

Type

Description

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 business case and cost-benefit analysis
to determine whether the cloud is a viable solution to meet specific
business requirements, and justify any expenses.

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.

Affects on-site private clouds. Because the private cloud is deployed

inside the firewall on the enterprises 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.

Figure 8Risk Factors of Cloud Service and Deployment Models (cont.)

Appendix B. Overview of Different Risk Factors
per Service and Deployment Model
63

Risk Factor

Cloud IT skills
required

D4.A

Cloud
interdependency

Hybrid Cloud

D3.E

Private Cloud (cont.)

Code

(can be
triggered by
cost)

Unavailability

Theft

(can be (can be
triggered triggered
by cost) by cost)

Loss

Risk Event

(can be
triggered
by cost)

Disclosure

Increasing

Increasing

Type

Description

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.

Affects on-site private clouds. Building a private 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 investments.

Figure 8Risk Factors of Cloud Service and Deployment Models (cont.)

64
Security Considerations for Cloud Computing

A. Vulnerable
access
management
(infrastructure
and application,
public cloud)

Technical Threats

Threat

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)

Description
S1.D
S3.F
D1.B
D2.C

Risk
Factors
A contractual agreement is necessary to
officially clarify who is allowed to access
the enterprises information, naming
specific roles for CSP employees and
external partners.
Request that the CSP provide detailed
technical specifications of its IAM system
for the enterprises CISO to review and
approve. Include additional controls to
ensure robustness of the CSPs 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 CSPs
IAM systems).

Mitigation

Appendix 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

Mapping to
COBIT 5 for Information Security

Figure 9Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security

Figure 9 maps cloud threats and mitigating actions to COBIT 5 for Information Security.

Appendix C. Mapping Threats and Mitigating Actions to

COBIT 5 for Information Security

Appendix C. Mapping Threats and Mitigating Actions 65
to COBIT 5 for Information Security

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.
A contractual agreement is necessary to
officially clarify who is allowed to access
the enterprises information, naming
specific roles for CSP employees and
external partners. All controls protecting
the enterprises 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 so global
performance could be affected.
Request the CSPs technical
specifications and controls to ensure
that the data are properly wiped when
requested.
Use a private cloud deployment model
(no multitenancy).

Mitigation

B. Data visible to
other tenants
when resources
are allocated
dynamically
S1.E

Risk
Factors
Use corporate IAM systems instead of
CSP 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.

Description

A. Vulnerable
access
management
(infrastructure
and application,
public cloud)
(cont.)

Technical Threats (cont.)

Threat

Appendix G. Detailed Guidance: People,

Skills and Competencies Enabler
G.3 Information Risk Management
G.6 Information Assessment and
Testing and Compliance
Appendix F. Detailed Guidance:
Services, Infrastructure and Applications
Enabler
F.5 Adequately Secured and Configured
Systems, in Line With Security
Requirements and Security Architecture
F.9 Security Testing

Mapping to
COBIT 5 for Information Security

Figure 9Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.)

66
Security Considerations for Cloud Computing

 Request the CSPs 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.
Use a private cloud deployment model
(no multitenancy).

Hypervisors are vital for cloud virtualization. S1.E

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 VM 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 VMs or crash the
hypervisor (similar to a DDoS attack).

D. Hypervisor
attacks

Mitigation
Request the CSPs technical details for
CISO approval and require additional
controls to ensure data privacy.
A contractual agreement is necessary to
officially clarify who is allowed to access
the enterprises information, naming
specific roles for CSP employees and
external partners. All controls protecting
the enterprises information assets must
be clearly documented in the contract
agreement or SLA.
Use a private cloud deployment model
(no multitenancy).

Risk
Factors

S1.E
Due to the nature of multitenancy,
D1.B
some assets (e.g., routing tables, MAC
D2.C
addresses, internal IP addresses, LAN
traffic) could be visible to other entities
in the same cloud. Malicious entities in
the cloud could take advantage of the
information, e.g., by utilizing shared routing
tables to map the internal network topology
of an enterprise, preparing the way for an
internal attack.

Description

C. Multitenancy
visibility

Technical Threats (cont.)

Threat

Appendix B. Detailed Guidance:

Processes Enabler
B.2
 Align, Plan and Organize (APO)
. APO09 Manage Service Agreements.
Appendix G. Detailed Guidance: People,
Skills and Competencies Enabler
G.3 Information Risk Management
Appendix A. Detailed Guidance:
Principles, Policies and Framework
Enabler
A .2 Information Security Policy

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)
Appendix F. Detailed Guidance:
Services, Infrastructure and Applications
Enabler
F.10 Monitoring and Alert Services for
Security-related Events

Mapping to
COBIT 5 for Information Security

Figure 9Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.)

Appendix C. Mapping Threats and Mitigating Actions 67
to COBIT 5 for Information Security

F. Application
compatibility

E. Application
attacks

Description

Risk
Factors

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.

D3.C

Due to the nature of SaaS, the applications S3.H

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.

Technical Threats (cont.)

Threat

Evaluate extensively the design and

requirements of application candidates
to move to the cloud and/or request of
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.

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.

Mitigation

Appendix B. Detailed Guidance:

Processes Enabler
B
 .3 Build, Acquire and Implement (BAI)
. BAI02 Manage Requirements
Definition.
Appendix E. Detailed Guidance:
Information Enabler
E.6 Information Security Requirements
Appendix F. Detailed Guidance:
Services, Infrastructure and Applications
Enabler
F.3 Secure Development

Appendix G. Detailed Guidance: People,

Skills and Competencies Enabler
G.5 Information Security Operations
G.6 Information Assessment and
Testing and Compliance
Appendix F. Detailed Guidance:
Services, Infrastructure and Applications
Enabler
F.10 Monitoring and Alert Services for
Security-related Events

Mapping to
COBIT 5 for Information Security

Figure 9Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.)

68
Security Considerations for Cloud Computing

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).

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
assets.

H. SaaS access
security

Description

G. Collateral
damage

Technical Threats (cont.)

Threat

S3.K

D1.C

Risk
Factors

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.

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 enterprises contracted
capacity is always available and cannot
be directed to other tenants without
approval.
Use a private cloud deployment model
(no multitenancy).

Mitigation

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
Appendix G. Detailed Guidance: People,
Skills and Competencies Enabler
G.5 Information Security Operations

Appendix E. Detailed Guidance:

Information Enabler
E.6 Information Security Requirements
Appendix F. Detailed Guidance:
Services, Infrastructure and Applications
Enabler
F.8 Adequate Incident Response
Appendix G. Detailed Guidance: People,
Skills and Competencies Enabler
G.3 Information Risk Management

Mapping to
COBIT 5 for Information Security

Figure 9Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.)

Appendix C. Mapping Threats and Mitigating Actions 69
to COBIT 5 for Information Security

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 them 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.

In the event of contract termination, to

prevent disclosure of the enterprises
assets, those assets should be removed
from the cloud using forensic tools
(or other tools that ensure a complete
wipeout).

B. Asset disposal

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.

Description

A. Asset ownership

Regulatory Threats

I. Outdated VM
security

Technical Threats (cont.)

Threat

Include terms in the contract with

the CSP to 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 could affect the performance
of the system.
Request CSPs technical specifications
and controls that ensure that data are
properly wiped and backup media is
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
enterprises review.

S1.I
S2.E
S3.D

Introduce procedures within the

enterprise to verify the state of software
security updates prior to the activation of
any VMs.
Empower the CSP to apply security
patches on inactive VMs.

Mitigation

S2.D
S3.C

S1.K

Risk
Factors

Appendix G. Detailed Guidance: People,

Skills and Competencies Enabler:
G.3 Information Risk Management

Appendix C. Detailed Guidance:

Organizational Structures Enabler
C
 .5 Information Custodians/Business
Owners

Appendix A. Detailed Guidance:

Principles, Policies and Framework
Enabler
A.2 Information Security Policy
Appendix F. Detailed Guidance: Services,
Infrastructure and Applications Enabler
F.5 Adequately Secured and Configured
Systems, Aligned With Security
Requirements and Security Architecture

Mapping to
COBIT 5 for Information Security

Figure 9Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.)

70
Security Considerations for Cloud Computing

C. Asset location

Description

Technical information assets (data, logs,

etc.) are subject to the regulations of
the country where they are stored. 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.

Regulatory Threats (cont.)

Threat
S1.D

Risk
Factors
Request the CSPs list of infrastructure
locations and verify that regulation
in those locations is aligned with the
enterprises requirements.
Include terms in the service contract
to restrict the moving of enterprise
assets to only those areas known to
be compliant with the enterprises own
regulation.
To prevent disclosure, encrypt any asset
prior to migration to the CSP, and ensure
proper key management is in place.

Mitigation

Appendix G. Detailed Guidance: People,

Skills and Competencies Enabler
G.4 Information Security Architecture
Development
G.6 Information Assessment and
Testing and Compliance
Appendix F. Detailed Guidance:
Services, Infrastructure and Applications
Enabler
F.2 Security Awareness

Mapping to
COBIT 5 for Information Security

Figure 9Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.)

Appendix C. Mapping Threats and Mitigating Actions 71
to COBIT 5 for Information Security

Description

A. Physical security
on all premises
where
data/applications
are stored

Risk
Factors

S1.H
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 CSPs
staff, which is subject to the CSPs security
policy. There could be a gap between the
security measures provided by the CSP
and the requirements of the enterprise.

Information Security Governance Threats

Threat
Request the CSPs physical security
policy and ensure that it is aligned with
the enterprises security policy.
Request that the CSP provide proof
of independent security reviews or
certification reports (e.g., AICPA SSAE 16
SOC 2 report or ISO certification).
Include in the contract language that
requires the CSP to be aligned with
the enterprises security policy and to
implement necessary controls to
ensure it.
Request the CSPs DRP and ensure
that they contain the necessary
countermeasures to protect physical
assets during and after a disaster.

Mitigation

Appendix E. Detailed Guidance:

Information Enabler
E.6 Information Security Requirements
Appendix A. Detailed Guidance:
Principles, Policies and Frameworks
Enabler
A.2 Information Security Policy

Mapping to
COBIT 5 for Information Security

Figure 9Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.)

72
Security Considerations for Cloud Computing

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.

Data media must be disposed in a secure

way to avoid data leakage and disclosure.
Data wipeout procedures must ensure
that data cannot be reproduced when data
media support 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.

B. Visibility of
the security
measures put in
place by the CSP

C. Media
management

Information Security Governance Threats (cont.)

Threat
Request the CSPs detailed schemes of
the technical security measures in place
and determine whether they meet the
requirements of the enterprise.
Request that the CSP provide proof
of independent security reviews or
certification reports (e.g., AICPA SSAE 16
SOC 2 report or ISO certification).
Include in the contract language
that requires the CSP to provide the
enterprise with regular reporting on
security (incident reports, IDS/IPS
logs, etc.).
Request the CSPs security incident
management process be applied to the
enterprises assets and ensure that it
is aligned with the enterprises own
security policy.
Request the CSPs 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
enterprises security policy

S1.I

Mitigation

S1.F

Risk
Factors

Appendix B. Detailed Guidance:

Processes Enabler
B
 .3 Build, Acquire and Implement (BAI)
. BAI08 Manage Knowledge.

Appendix E. Detailed Guidance:

Information Enabler
E.6 Information Security Requirements
E.8 Information Security Review
Reports
E.9 Information Security Dashboard
Appendix F. Detailed Guidance:
Services, Infrastructure and Applications
Enabler
F.10 Monitoring and Alert Services for
Security-related Events

Mapping to
COBIT 5 for Information Security

Figure 9Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.)

Appendix C. Mapping Threats and Mitigating Actions 73
to COBIT 5 for Information Security

Description
Request the CSPs details about the
software SDLC in place and ensure
that the security measures introduced
into the design are compliant with the
requirements of the enterprise.
Request the CSP to provide proof
of independent security reviews or
certification reports (e.g., AICPA SSAE 16
SOC 2 report or ISO certification).

Ensure that a global security policy

specifying minimum requirements
is applied to all entities sharing a
community cloud.
Request that the CSP provide proof
of independent security reviews or
certification reports (e.g., AICPA SSAE 16
SOC 2 report or ISO certification).

S3.E

D2.C

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 groups entities in danger.

E. Common
security policy
for community
clouds

Mitigation

When using SaaS services, the enterprise

must be sure that the applications will
meet its security requirements. This will
reduce the risk of disclosure.

Risk
Factors

D. Secure software
SDLC

Information Security Governance Threats (cont.)

Threat

Appendix E. Detailed Guidance:

Information Enabler:
E.6 Information Security Requirements
Appendix A. Detailed Guidance:
Principles, Policies and Framework
Enabler
E.2 Information Security Strategy

Appendix B. Detailed Guidance:

Processes Enabler
B.3 Build, Acquire and Implement (BAI)
. BAI03 Manage Solutions Identification
and Build.
Appendix E. Detailed Guidance:
Information Enabler
E.6 Information Security Requirements
Appendix F. Detailed Guidance:
Services, Infrastructure and Applications
Enabler
F.3 Secure Development

Mapping to
COBIT 5 for Information Security

Figure 9Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.)

74
Security Considerations for Cloud Computing

Description

F. Service
termination
issues

Risk
Factors

S3.G
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 CSPs 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.

Information Security Governance Threats (cont.)

Threat
Ensure by contract or SLA with the CSP
an exit strategy that specifies the terms
that should trigger the retrieval of the
enterprises assets in the timeframe
required by the enterprise.
Implement a DRP, taking into account
the possibility of complete disruption of
the CSP.

Mitigation

Appendix B. Detailed Guidance:

Processes Enabler
B.2 Align, Plan and Organize (APO)
. APO09 Manage Service Agreements.
Appendix B. Detailed Guidance:
Processes Enabler
B.4 Deliver, Service and Support
. DSS04 Manage Continuity.
Appendix G. Detailed Guidance: People,
Skills and Competencies Enabler
G.3 Information Risk Management

Mapping to
COBIT 5 for Information Security

Figure 9Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.)

Appendix C. Mapping Threats and Mitigating Actions 75
to COBIT 5 for Information Security

Description
Ensure that internal governance controls
are in place within the enterprise
to involve the necessary control
organizations (legal, compliance, finance,
etc.) during the decision process of
migrating to cloud services.

Request of 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) for forensic analysis as
part of the contract or SLA. If this is not
possible, request of the CSP to authorize
trusted third parties to perform forensic
analysis when necessary.

S3.I

Security audits and forensic investigations S1.F

S1.L
are vital to the enterprise to evaluate the
security measures of the CSP (preventive
and corrective), and in some cases the CSP
itself (e.g., to authenticate the CSP). This
raises several issues because performing
these actions requires having extensive
access to the CSPs infrastructure and
monitoring capabilities, which are often
shared with other CSPs 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.

H. Support for audit

and forensic
investigations

Mitigation

Enterprises turn to CSPs in search of

solutions that can be implemented easily
and at a low cost. This ease can be
tempting, especially when the enterprise
is facing urgent deadlines that require
an urgent solution (like the expiration of
application licenses, or the need of more
computing capacity). This can become
an issue because organizations may
contract cloud applications without proper
procurement and approval oversight,
thus bypassing compliance with internal
policies.

Risk
Factors

G. Solid enterprise
governance

Information Security Governance Threats (cont.)

Threat

Appendix B. Detailed Guidance:

Processes Enabler
B.2 Align, Plan and Organise (APO)
. APO10 Manage Suppliers.
B.5 Monitor, Evaluate and Assess
(MEA)
. MEA02 Monitor, Evaluate and Assess
the System of Internal Control.

Appendix B. Detailed Guidance:

Processes Enabler
B.1 Evaluate, Direct and Monitor (EDM)
. EDM01 Ensure Governance
Framework Setting and Maintenance.
B.5 Monitor, Evaluate and Assess (MEA)
. MEA02 Monitor, Evaluate and Assess
the System of Internal Control.

Mapping to
COBIT 5 for Information Security

Figure 9Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.)

76
Security Considerations for Cloud Computing

Abbreviations 77

Abbreviations
Abbreviation

Full Term

BCM

Business continuity management

CAPEX

Capital expendituresused 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 expendituresongoing 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

 78

Security Considerations for Cloud Computing

Page intentionally left blank

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

 80

Security Considerations for Cloud Computing

Page intentionally left blank