security considerations cloud computing

8/10/2019 Security Considerations Cloud Computing

1/80

1


2/80

2 Security Considerations for Cloud Computing

About ISACA

With more than 100,000 constituents in 180 countries, ISACA (www.isaca.org) is a leading globalprovider of knowledge, certifications, community, advocacy and education on information systems(IS) assurance and security, enterprise governance and management of IT, and IT-related risk andcompliance. Founded in 1969, the nonprofit, independent ISACA hosts international conferences,

publishes theISACA

Journal, and develops international IS auditing and control standards,which help its constituents ensure trust in, and value from, information systems. It also advancesand attests IT skills and knowledge through the globally respected Certified Information SystemsAuditor(CISA), Certified Information Security Manager(CISM), Certified in the Governanceof 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 theCOBITframework. COBIT helps IT professionals and enterprise leaders fulfill their IT governanceand management responsibilities, particularly in the areas of assurance, security, risk and control, anddeliver value to the business.

DisclaimerISACA has designed and created Security Considerations for Cloud Computing(the Work)primarily as an educational resource for governance and assurance professionals. ISACA makesno 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 otherinformation, procedures and tests that are reasonably directed to obtaining the same results. Indetermining the propriety of any specific information, procedure or test, governance and assurance

professionals should apply their own professional judgment to the specific circumstances presentedby 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 anymeans (electronic, mechanical, photocopying, recording or otherwise) without the prior writtenauthorization of ISACA. Reproduction and use of all or portions of this publication are permittedsolely for academic, internal and noncommercial use and for consulting/advisory engagements, andmust include full attribution of the materials source. No other right or permission is granted withrespect to this work.

ISACA3701 Algonquin Road, Suite 1010Rolling Meadows, IL 60008 USAPhone: +1.847.253.1545Fax: +1.847.253.1443

Email: [email protected] site: www.isaca.org

Feedback: www.isaca.org/cloud-securityParticipate in the ISACA Knowledge Center: www.isaca.org/knowledge-centerFollow ISACA on Twitter: https://twitter.com/ISACANewsJoin ISACA on LinkedIn: ISACA (Official), http://linkd.in/ISACAOfficialLike ISACA on Facebook: www.facebook.com/ISACAHQ

ISBN 978-60420-263-2Security Considerations for Cloud Computing


3/80

Acknowledgments 3

ACKNOWLEDGMENTS

ISACA wishes to recognize:

Development TeamStefanie Grijp, PwC, BelgiumChris Kappler, PwC, BelgiumBart Peeters, CISA, PwC, BelgiumTomas Clemente Sanchez, PwC, Belgium

Work GroupYves Marcel Le Roux, CISM, CISSP, CA Technologies, FranceAlan Mayer, USAPerry Menezes, CISM, CRISC, CIPP, CISSP, Deutsche Bank, USAYogendra Rajput, IndiaParas Shah, CISA, CGEIT, CRISC, CA, Transpire Pty Ltd., Australia

Brett Smith, CISSP, ISSAP, Deutsche Bank, USA

Expert ReviewersMuhammad Amir, CISA, CISM, CRISC, CEH, CISSP, MCSE Security, Security+,

NetSol Technologies Ltd., PakistanMark E.S. Bernard, CISA, CSIM, CGEIT, CRISC, CISSP, PM, ISO 27001, SABSA-F2,

TechSecure Holdings Inc., CanadaRoberta Donaldson Caraglia, EMCIS, ITIL V3, EMC Consulting, USAChristos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., GreeceMeenu Gupta, CISA, CISM, CBP, CIPP, CISPP, Mittal Technologies, USAMasatoshi Kajimoto, CISA, CRISC, Independent Consultant, JapanHesham Moussa, CISM, Lumension Security, USA

Jo Stewart-Rattray, CISA, CISM, CGEIT, CRISC, CSEPS, RSM Bird Cameron, AustraliaLou Tinto, CISA, CRISC, CFE, CIA, NYLB, USASukhwinder Wadhwa, ITIL V3, Infosys Ltd, IndiaJustin Williams, CA (SA), Transnet, South Africa

ISACA Board of DirectorsGregory T. Grocholski, CISA, The Dow Chemical Co., USA, International PresidentAllan Boardman, CISA, CISM, CGEIT, CRISC, ACA, CA (SA), CISSP, Morgan Stanley, UK,

Vice PresidentJuan Luis Carselle, CISA, CGEIT, CRISC, Wal-Mart, Mexico, Vice PresidentChristos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., Greece, Vice PresidentRamses Gallego, CISM, CGEIT, CCSK, CISSP, SCPM, 6 Sigma, Quest Software, Spain,

Vice PresidentTony Hayes, CGEIT, AFCHSE, CHE, FACS, FCPA, FIIA, Queensland Government, Australia,

Vice PresidentJeff Spivey, CRISC, CPP, PSP, Security Risk Management Inc., USA, Vice PresidentMarc Vael, Ph.D., CISA, CISM, CGEIT, CRISC, CISSP, Valuendo, Belgium, Vice PresidentKenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Past International PresidentEmil DAngelo, CISA, CISM, Bank of Tokyo-Mitsubishi UFJ Ltd., (retired), USA,

Past International PresidentJohn Ho Chi, CISA, CISM, CRISC, CBCP, CFE, Ernst & Young LLP, Singapore, DirectorKrysten McCabe, CISA, The Home Depot, USA, DirectorJo Stewart-Rattray, CISA, CISM, CGEIT, CRISC, CSEPS, RSM Bird Cameron, Australia, Director

Knowledge BoardMarc Vael, Ph.D., CISA, CISM, CGEIT, CRISC, CISSP, Valuendo, Belgium, ChairmanSteven A. Babb, CGEIT, CRISC, Betfair, UKThomas E. Borton, CISA, CISM, CRISC, CISSP, Cost Plus, USAPhillip J. Lageschulte, CGEIT, CPA, KPMG LLP, USASalomon Rico, CISA, CISM, CGEIT, Deloitte, MexicoSteven E. Sizemore, CISA, CIA, CGAP, Texas Health and Human Services Commission, USA


4/80


ACKNOWLEDGMENTS(CONT.)Guidance and Practices CommitteePhillip J. Lageschulte, CGEIT, CPA, KPMG LLP, USA, ChairmanDan Haley, CISA, CGEIT, CRISC, MCP, Johnson & Johnson, USAYves Marcel Le Roux, CISM, CISSP, CA Technologies, FranceAureo Monteiro Tavares Da Silva, CISM, CGEIT, Pelissari, BrazilJotham Nyamari, CISA, Deloitte, USAConnie Lynn Spinelli, CISA, CRISC, CFE, CGMA, CIA, CISSP, CMA, CPA, GRC Solutions LLC, USAJohn William Walker, CISM, CRISC, FBCS CITP, ITPC Secure Bastion Limited, UKSiang 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 SponsorsInformation Security ForumInstitute of Management Accountants Inc.ISACA chaptersITGI FranceITGI Japan

Norwich UniversitySocitum Performance Management GroupSolvay Brussels School of Economics and ManagementStrategic Technology Management Institute (STMI) of the National University of SingaporeUniversity of Antwerp Management School

ASIS InternationalHewlett-PackardIBMSymantec Corp.TruArx Inc.


5/80

Table of Contents 5

TABLEOFCONTENTS

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


6/80


Appendix A. The Path to the Decision and BeyondChecklist......................... 53

Appendix B. Overview of Different Risk Factors per Service

and Deployment Model ...................................................................... 55

Appendix C. Mapping Threats and Mitigating Actions to

COBIT 5 for Information Security..................................................... 65

Abbreviations................................................................................................................ 77

References...................................................................................................................... 79


7/80

1. Introduction 7

1. INTRODUCTION

Background

In recent years cloud computing has become more than a just another IT buzzword.

It refers to a business trend that is expected to 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 beconsidered 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 allcurrent and potentialcloud 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 ofrisk and threats is limited to cloud-specific elements.)


8/80


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)


9/80

2. Cloud Computing 9

2. CLOUDCOMPUTING

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 casesautomatically 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 cloudusers 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, MicrosoftWindows 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.

1Mell, Peter; Timothy Grance; The NIST Definition of Cloud Computing, US National Institute ofStandards and Technology (NIST) Special Publication (SP) 800-145, USA, 2011


10/80


11/80

2. Cloud Computing 11

The answer to the question How can I rely on a CSP to protect my data? will be

influenced by a number of aspects:

The possibility for auditing and the verification of controls. Does the cloud user

have a view of the CSPs mitigating controls to handle riskcontrols related to

security, availability, processing integrity, confidentiality and privacy? In thiscontext, 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 2SMUser 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 DataSecurity 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.


12/80


Page intentionally left blank


13/80

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

3. OVERVIEWOFSECURITYRISKANDTHREATS

RELATEDTOOPERATINGINTHECLOUD

Recent publications and media coverage have discussed the extensive benefits ofmigrating 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 ofmitigating 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.


14/80


Figure 1Cloud Service Models

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

Client Assumes

All Data and Application

Security Risk

IaaSInfrastructure as a Service

APIs

Abstraction

Hardware

Facilities

Core Connectivityand Delivery

APIs

Integration and Middleware

InfrastructureasaService(IaaS)


Platforma

saService(PaaS)


Platforma

saService(PaaS)

SoftwareasaService(SaaS)

Abstraction

Hardware

Facilities


APIs

APIs

PresentationModality

PresentationPlatform

Data Metadata Content

Applications

Integration and Middleware

Abstraction

Hardware

Facilities


PaaSPlatform as a Service

SaaSSoftware as a Service

Data and Application

Security Risk

Per SLA

2ISACAs Risk IT framework considers the following risk events: interruption, destruction, theft anddisclosure. However, the terms unavailability (interruption) and loss (destruction) are found to bemore suitable for the assets presented in this context.


15/80


16/80


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 anddeployment 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 practicalguidance 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.


17/80


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 theenterprise 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 beexpanded 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 onhypervisors 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 personalprivate 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 (publiccloud), 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


18/80


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 anyinfrastructure, intrusion detection systems (IDS)/intrusion prevention systems

(IPS) and security incident and event management (SIEM) capabilities must

be in place. It is the responsibility of the CSP to provide these capabilities to

its customers. To ensure that there are no security gaps, the security policy and

governance of the CSP should match those of the enterprise.


S1.G Absence of DRP and 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 (interms of RTO/RPO).


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, disclosureS1.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 affectedDisclosureS1.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.


S1.K Virtual machine (VM) security maintenanceIaaS providers allow

consumers to create VMs in various states (e.g., active, running, suspendedand 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.



19/80


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


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.



20/80


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



S3.C Data ownershipThe CSP provides the applications and the customerprovides 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, disclosureS3.E Lack of visibility into software systems development life cycle (SDLC)

Enterprises that use cloud applications have little visibility into the software

SDLC. Customers do not know in detail how the applications were

developed and what security considerations were taken into account during

the SDLC. This could lead to an imbalance between the security provided by

the application and the security required by customers/users.


S3.F Identity and access management (IAM)To maximize their revenues,

CSPs offer their services and applications to several customers concurrently.Those customers share servers, applications and, eventually, data. If data

access is not properly managed by the CSP application, one customer could

obtain access to another customers data.

Risk affectedLoss, theft, disclosure


21/80


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, facelegal action, or be the potential target for an acquisition (with the likelihood

of sudden changes in CSP policies and any agreements in place). If the

customer-CSP relationship goes sour and the enterprise wants to bring the

data back in-house, the question of how to securely render the data becomes

critical because the in-house applications may have been decommissioned or

sunsetted and there is no application available to render the data.


S3.H Broad exposure of 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 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


22/80


23/80


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


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 increasedby adding disks.



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 environmentsmay also be questionable candidates for migration, at least until standards settle

and vendors take steps to make their solutions private-cloud-compatible. In the

meantime, compatibility testing and remediation are critical.


D3.D Investments 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 evenmore 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


24/80


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?


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 toensure that the enterprise receives the full benefits of the cloud. Control objectives

for cloud operations are covered extensively in ISACAs publicationIT 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.


25/80


Technical3

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 couldresult 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 theCSPs 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: 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

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 ordisk space that can be recovered by other entities sharing the cloud by using

forensics techniques.

Mitigation:



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

3Related guidance on technical threats and mitigating actions can also be found in COBIT 5, DSS05Manage security services.


26/80


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 ApplicationsEnabler:

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



and external partners. All controls protecting the enterprises informationassets must be clearly documented in the contract agreement or SLA.



Appendix E. Detailed Guidance: Information Enabler:

.E.8 Information Security Review Reports

Appendix C. Detailed Guidance: Organizational Structures Enabler:

.C.1 Chief Information Security Officer (CISO)


Enabler: .F.10 Monitoring and Alert Services for Security-related Events

D. Hypervisor attacks:


Description: Hypervisors are vital for server virtualization. They provide the

link between virtual machines and the underlying physical resources required to

run the machines by using hypercalls (similar to system calls, but for virtualized

systems). An attacker using a virtual machine in the same cloud could fake

hypercalls to inject malicious code or trigger bugs in the hypervisor. This could

potentially be used to violate confidentiality or integrity of other virtual machinesor 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.


27/80


28/80


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


Related guidance in COBIT 5 for Information Security: Appendix E. Detailed Guidance: Information Enabler:

.E.6 Information Security Requirements




Enabler:

.F.8 Adequate Incident Response

H. SaaS access security

Related risk factor: S3.K Description: Access to SaaS applications (either via browser or specific

end-user clients) must be secure in order to control the exposure to attacks and

protect the enterprise and his assets.

Mitigation:

Use hardened web browsers and/or specific end-user client applications

which include appropriate security measures (anti-malware, encryption,

sandboxes, etc.).

Use secure virtual desktops or specific browser clients when connecting to

cloud applications. Educate corporate users about the risk of running SaaS applications using

insecure devices.



Enabler:

.F.6 User Access and Access Rights in Line With Business Requirements



.G.5 Information Security OperationsI. 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.


29/80


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


Enabler:

.F.5 Adequately Secured and Configured Systems, Aligned With Security

Requirements and Security Architecture

Regulatory4

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 enterpriseremains the sole legal owner of any asset migrated to the CSP.

Encrypt all sensitive assets being migrated to the CSP prior to the migration

to prevent disclosure and ensure proper key management is in place. This can

affect the performance of the system.


Appendix C. Detailed Guidance: Organizational Structures Enabler:

.C.5 Information Custodians/Business Owners

B. Asset disposal

Related risk factors: S1.I, S2.E, S3.D Description: In the event of contract termination, to prevent disclosure of

the 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 anyevent ending the contract, a mandatory data wipe carried out under the

enterprises review.




4Related guidance on regulatory threats and mitigating actions can be found in COBIT 5, MEA03Monitor, evaluate and assess compliance with external requirements.


30/80


31/80



Appendix E. Detailed Guidance: Information Enabler


Appendix A. Detailed Guidance: Principles, Policies and Frameworks Enabler

.A.2 Information Security PolicyB. 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.8 Information Security Review Reports

.E.9 Information Security Dashboard


Enabler:


C. Media management: Related risk factor: S1.I

Description: Data media must be disposed in a secure way to avoid data

leakage and disclosure. Data wipeout procedures must ensure data cannot be

reproduced when data media is designated for recycle or disposal. Controls

should be in place during transportation (encryption and physical security).

This should be specified in the CSP security policy and contract SLA.

Mitigation:

Request the 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.


Appendix B. Detailed Guidance: Processes Enabler

.B. 3 Build, Acquire and Implement: BAI08 Manage Knowledge


32/80


D. Secure software SDLC:


Description: When using SaaS services, the enterprise must be sure that the

applications will meet its security requirements. This will reduce the risk of

theft, disclosure and unavailability. Mitigation:

Request the 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.,



Appendix B. Detailed Guidance: Processes Enabler: .B. 3 Build, Acquire and Implement: BAI03 Manage Solutions

Identification and Build




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 orcertification reports that meet the enterprises compliance requirements (e.g.,





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


33/80


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 timeframe required by the enterprise.

Implement a DRP, taking into account the possibility of complete CSP

disruption.


Appendix B. Detailed Guidance: Processes Enabler:

.B.2 Align, Plan and Organize: APO09 Manage Service Agreements


.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 compliancewith internal policies.

Mitigation:

Ensure that internal governance controls are in place within the enterprise to

involve the necessary governance organization (legal, compliance, finance,

etc.) during the decision process of migrating to cloud services.



.B.1 Evaluate, Direct and Monitor: EDM01 Ensure Governance Framework

Setting and Maintenance. .B.5 Monitor, Evaluate and Assess: MEA02 Monitor, Evaluate and Assess

the System of Internal Control


34/80


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



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


35/80

4. The Path to the Decision and Beyond 35

4. THEPATHTOTHEDECISIONANDBEYOND

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.6All 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 andapplications; 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?

6Commercial analysis must, of course, be done, but it is out of scope for this publication.


36/80


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 intothe 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 3is 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.


37/80


Figure 3Decision Tree: Choosing a Service Model

1. Is the business process anonstandard solution?

7. Business drivercloud-compatible?

SaaS

PaaS

IaaS

4. Applications/hardware/OScustom?

5. Hardware/OS custom?

6. Hardware custom?

A cloud solution is probablynot the best solution for

your business needs.

Y

Y

Y

Y

Y

Y

N

N

N

N

N

N

N

Y

3. Difference from standardsolutions IT-based?

2. Interdependencieswith other

business processes?

A cloud solution is probablynot the best solution for

your business needs.


38/80


Breakdown of Cloud Service Model Decision Tree

Figure 4provides 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 nonstandardsolutions, then a further drilling down isneeded to determine whether the businessprocess is suitable for a cloud solution.

Question 2: Interdependencies withbusiness processes?

No If a standard solution is used, then the

transition to the cloud is relatively easy andthe benefits of adopting a cloud solutionwill most likely be high.

Question 7: Business driver

cloud-compatible?

2. Interdependencies with business processes?

Yes If there are interdependencies withdifferent business processes, then anyalteration to one of these processescould mean a change to the applicationimplemented in the cloud.

Question 3: Difference from standardsolutions IT-based?

No If there are no interdependencies,

then changes will not be required. Thechosen cloud solution will, therefore, beindependent.

Question 7: Business driver

cloud-compatible?

3. Difference from standard solutions IT-based?

Yes While interdependency may implicate achange in the IT infrastructure, it is notalways a necessity. If interdependencydoes implicate such a change, however,the cloud application will need to bechanged. This fact will largely influence thedecision for a cloud service model. Thus,it is important to outline the differencesbetween the current solution and thestandard solution provided by a CSP.

Question 4: Applications/hardware/OScustom?

No If there are no differences between the ITsolutions, then the standard offerings of aCSP will adequately address the businessneeds.

Question 7: Business drivercloud-compatible?

4. Application/hardware/OS custom?

Yes Once it is established that there is indeeda gap between the business needs and thecloud service offerings, it is important todefine the level on which the difference issituated.

Question 5: Hardware/OS custom?

No If the differentiation is situated in theconfiguration of standard applications, thencloud offerings will fulfill the business needs.

Question 7: Business drivercloud-compatible?


39/80


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

Answer Explanation Next Question

5. Hardware/OS custom?

Yes After establishing that the difference isnot within the application, it is importantto establish whether the differentiationis found on the OS level or the physicalhardware platform. The answer will alterthe possibility for cloud adaptation.

Question 6: Hardware custom?

No If the differentiation can be done onapplication level, no further drill-down isneeded.

Solution: PaaS

6. Hardware custom?

Yes After establishing that the differentiationis located on the physical level, a cloudsolution is very unlikely. CSPs are orientedtoward standardization within their domain;providing custom hardware is not one oftheir typical offerings. While a CSP canundoubtedly provide custom hardwareplatforms, the high cost and the CSPsrelative lack of experience in the customplatform eliminate the cloud as a viable

solution.

Solution: A cloud solution is probably notthe best solution for your business needs.

No If the differentiation can be done on the OSlevel, no further drill-down is needed.

Solution: IaaS

7. Business driver cloud-compatible?

Yes

Viable business drivers for the clouddecision include: Reduce medium- and/or long-term total

cost of ownership (TCO). Improve cash ow 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/ordomain expertise.

Solution: SaaS

No While there may be no technicalconstraints to adopting the cloud as asolution, it is possible that the businessdrivers are, in fact, not cloud-compatible.

Adopting a cloud solution requires amid- to long-term vision. Therefore, thecloud cannot be used as a solution to cutcosts immediately.

Solution: A cloud solution is probably notthe best solution for your business needs.


40/80


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 whenevaluating 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 severalallied 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 orbusiness-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.


41/80


Figure 5Decision Tree: Choosing a Deployment Model

Start

Fullcloudmaynot

bethebestsolution.

Hybridcloudmay

beconsidered.

1.

Sensitive

data?

2.

Critical

data?

3.

Morethan

data?

5.

Adequate

infrastructure?

1

security considerations cloud computing

Documents