2 Security Considerations for Cloud Computing

(1)

(2)

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 Control}TM_(CRISCTM₎ designations.

ISACA continually updates and expands the practical guidance and product family based on the COBIT®_{framework. COBIT helps IT professionals and enterprise leaders fulfill their IT governance} and management responsibilities, particularly in the areas of assurance, security, risk and control, and deliver value to the business.

Disclaimer

ISACA has designed and created Security Considerations for Cloud Computing (the “Work”) primarily as an educational resource for governance and assurance professionals. ISACA makes no claim that use of any of the Work will assure a successful outcome. The Work should not be considered inclusive of all proper information, procedures and tests or exclusive of other information, procedures and tests that are reasonably directed to obtaining the same results. In determining the propriety of any specific information, procedure or test, governance and assurance professionals should apply their own professional judgment to the specific circumstances presented by the particular systems or information technology environment.

Reservation of Rights

© 2012 ISACA. All rights reserved. No part of this publication may be used, copied, reproduced, modified, distributed, displayed, stored in a retrieval system or transmitted in any form by any means (electronic, mechanical, photocopying, recording or otherwise) without the prior written authorization of ISACA. Reproduction and use of all or portions of this publication are permitted solely for academic, internal and noncommercial use and for consulting/advisory engagements, and must include full attribution of the material’s source. No other right or permission is granted with respect to this work.

ISACA

3701 Algonquin Road, Suite 1010 Rolling Meadows, IL 60008 USA Phone: +1.847.253.1545 Fax: +1.847.253.1443 Email: [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

(3)

A

cknowledgments

ISACA wishes to recognize:

Development Team Stefanie Grijp, PwC, Belgium Chris Kappler, PwC, Belgium Bart Peeters, CISA, PwC, Belgium Tomas Clemente Sanchez, PwC, Belgium Work Group

Yves Marcel Le Roux, CISM, CISSP, CA Technologies, France Alan Mayer, USA

Perry Menezes, CISM, CRISC, CIPP, CISSP, Deutsche Bank, USA Yogendra Rajput, India

Paras Shah, CISA, CGEIT, CRISC, CA, Transpire Pty Ltd., Australia Brett Smith, CISSP, ISSAP, Deutsche Bank, USA

Expert Reviewers

Muhammad Amir, CISA, CISM, CRISC, CEH, CISSP, MCSE Security, Security+, NetSol Technologies Ltd., Pakistan

Mark E.S. Bernard, CISA, CSIM, CGEIT, CRISC, CISSP, PM, ISO 27001, SABSA-F2, TechSecure Holdings Inc., Canada

Roberta Donaldson Caraglia, EMCIS, ITIL V3, EMC Consulting, USA Christos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., Greece Meenu Gupta, CISA, CISM, CBP, CIPP, CISPP, Mittal Technologies, USA Masatoshi Kajimoto, CISA, CRISC, Independent Consultant, Japan Hesham Moussa, CISM, Lumension Security, USA

Jo Stewart-Rattray, CISA, CISM, CGEIT, CRISC, CSEPS, RSM Bird Cameron, Australia Lou Tinto, CISA, CRISC, CFE, CIA, NYLB, USA

Sukhwinder Wadhwa, ITIL V3, Infosys Ltd, India Justin Williams, CA (SA), Transnet, South Africa ISACA Board of Directors

Gregory T. Grocholski, CISA, The Dow Chemical Co., USA, International President

Allan Boardman, CISA, CISM, CGEIT, CRISC, ACA, CA (SA), CISSP, Morgan Stanley, UK, Vice President

Juan Luis Carselle, CISA, CGEIT, CRISC, Wal-Mart, Mexico, Vice President

Christos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., Greece, Vice President Ramses Gallego, CISM, CGEIT, CCSK, CISSP, SCPM, 6 Sigma, Quest Software, Spain,

Vice President

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

Jeff Spivey, CRISC, CPP, PSP, Security Risk Management Inc., USA, Vice President Marc Vael, Ph.D., CISA, CISM, CGEIT, CRISC, CISSP, Valuendo, Belgium, Vice President Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Past International President Emil D’Angelo, CISA, CISM, Bank of Tokyo-Mitsubishi UFJ Ltd., (retired), USA,

Past International President

John Ho Chi, CISA, CISM, CRISC, CBCP, CFE, Ernst & Young LLP, Singapore, Director Krysten McCabe, CISA, The Home Depot, USA, Director

Jo Stewart-Rattray, CISA, CISM, CGEIT, CRISC, CSEPS, RSM Bird Cameron, Australia, Director Knowledge Board

Marc Vael, Ph.D., CISA, CISM, CGEIT, CRISC, CISSP, Valuendo, Belgium, Chairman Steven A. Babb, CGEIT, CRISC, Betfair, UK

Thomas E. Borton, CISA, CISM, CRISC, CISSP, Cost Plus, USA Phillip J. Lageschulte, CGEIT, CPA, KPMG LLP, USA Salomon Rico, CISA, CISM, CGEIT, Deloitte, Mexico

(4)

A

cknowledgments

(

cont

.)

Guidance and Practices Committee

Phillip J. Lageschulte, CGEIT, CPA, KPMG LLP, USA, Chairman Dan Haley, CISA, CGEIT, CRISC, MCP, Johnson & Johnson, USA Yves Marcel Le Roux, CISM, CISSP, CA Technologies, France Aureo Monteiro Tavares Da Silva, CISM, CGEIT, Pelissari, Brazil Jotham Nyamari, CISA, Deloitte, USA

Connie Lynn Spinelli, CISA, CRISC, CFE, CGMA, CIA, CISSP, CMA, CPA, GRC Solutions LLC, USA John William Walker, CISM, CRISC, FBCS CITP, ITPC Secure Bastion Limited, UK

Siang Jun Julia Yeo, CISA, CPA (Australia), Visa Worldwide Pte. Limited, Singapore Nikolaos Zacharopoulos, CISA, CISSP, DeutschePost–DHL, Germany

ISACA and IT Governance Institute®_(ITGI®_{) Affiliates and Sponsors}

Information Security Forum

Institute of Management Accountants Inc. ISACA chapters

ITGI France ITGI Japan Norwich University

Socitum Performance Management Group

Solvay Brussels School of Economics and Management

Strategic Technology Management Institute (STMI) of the National University of Singapore University of Antwerp Management School

ASIS International Hewlett-Packard IBM

Symantec Corp. TruArx Inc.

(5)

t

Able

of

c

ontents

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

(6)

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

(7)

1. I

ntroductIon

Background

In recent years cloud computing has become more than a just another IT buzzword. It refers to a business trend that is expected to have—and for some enterprises already has—a significant impact on the way enterprises operate. It is likely that cloud computing will gain even more importance as both the cloud and cloud service provider markets mature. In times of cost optimization and economic downturn the cloud can be perceived as a way to realize a more cost-effective approach to technological support of the enterprise. However, security and data privacy concerns are frequently seen as critical issues or even barriers for adopting cloud computing services.

Purpose of This Document

This publication is not intended to provide yet another detailed, theoretical description of the concept of “cloud” and the different alternatives of cloud computing. Instead, it is designed to present practical guidance and facilitate the decision process for IT and business professionals concerning the decision to move to the cloud. This guide aims to enable effective analysis and measurement of risk using items such as decision trees and checklists outlining the security factors to be considered when evaluating the cloud as a potential solution.

Who Should Use This Guide?

Just as cloud computing is about more than just IT infrastructures, platforms and applications, the decision to operate in the cloud should not be taken solely by IT organizations. The use of cloud services might entail high risk for the business and should therefore be evaluated by responsible parties from the different control functions within an enterprise. This guide is meant for all current and potential

cloud users who need to ensure protection of information assets.

Scope and Approach

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

(8)

Consequently, this guide is structured as follows:

• Chapter 2—Cloud computing in a nutshell: What is cloud computing and how can it be implemented? This section provides a short description of the different service and deployment models used in cloud operations.

• Chapter 3—Overview of security risk and threats related to operating in the cloud, structured by service and deployment model

• Chapter 4—The path to the decision and beyond: guidance on how to evaluate the cloud as a potential solution by means of practical tools (decision trees and checklists)

(9)

2. C

loud

C

omputing

Cloud computing is defined by the US National Institute of Standards and Technology (NIST) as “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”1

There are five essential characteristics, three types of service models and four major deployment models to be taken into account relative to cloud computing. To ensure a common understanding of these models, the characteristics of each are described in the following sections.

Essential Characteristics

The essential characteristics of cloud computing are:

• On-demand self-service—Computing capabilities can be provisioned without

human interaction from the service provider.

• Broad network access—Computing capabilities are available over the network

and can be accessed by diverse client platforms.

• Resource pooling—Computer resources are pooled to support a multitenant model.

• Rapid elasticity—Resources can scale up or down rapidly and in some cases

automatically in response to business demands.

• Measured service—Resource utilization can be optimized by leveraging

charge-per-use capabilities.

Cloud Service Models

There are three main service models and each represents a different level of involvement of an outsourcing partner or cloud service provider (CSP):

• Infrastructure as a Service (IaaS)—In an IaaS solution, the CSP provides cloud

users with processing, storage, networks and other fundamental computing resources. Operating systems and applications, however, are the responsibility of the user and are not included in the service offering of the CSP. Examples are: Rackspace®_,

Equinix®_{, Softlayer}®_{, iomart Group plc, Amazon Web Services LLC, etc.}

• Platforms as a Service (PaaS)—PaaS entails the CSP making available

infrastructures and platforms on which cloud users deploy their own applications. This requires the CSP to support programming languages, libraries, services and tools. Examples are: Google App EngineTM_{, Microsoft}®_{Windows Azure}TM_,

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_{Mell, Peter; Timothy Grance; The NIST Definition of Cloud Computing, US National Institute of}

(10)

In each of these models, cloud users do not own, operate or control the underlying cloud infrastructure. They may, however, have (limited) control over operating systems and applications.

Cloud Deployment Models

The cloud is most often deployed in one of three models—also frequently referred to as cloud structures:

• Public cloud—The infrastructure is made available to the general public (e.g.,

Google Apps, Amazon Elastic Compute Cloud (EC2TM_{), Apple}®_{iCloud). It is}

deployed within the CSP infrastructure, offsite to the enterprise infrastructure.

• Community cloud—The cloud infrastructure is provisioned for exclusive use

by a specific community of consumers from enterprises or interest groups (e.g., vertical industries, schools, researchers, software developers) that have shared concerns. It can be deployed onsite (within the enterprise infrastructure) or offsite (within the CSP infrastructure, also called “outsourced”).

• Private cloud—The infrastructure can be used only by one single enterprise. As

for community clouds, it can be deployed onsite or offsite enterprise premises.

• Hybrid cloud—The cloud infrastructure is a composition of two or more distinct

cloud infrastructures (private, community or public) that remain unique entities.

The Key Element of Trust

Security and data privacy concerns are typically seen as critical barriers to the adoption of cloud services. To mitigate identified risk, cloud users can opt to set in place service level agreements (SLAs) or they can ask cloud service providers to meet certain control objectives. In the end, however, the discussion comes down to the key element of trust, which is a major component in the cloud computing business model. There can never be sufficient controls and agreements to mitigate all concerns if trust is a missing factor in the client-supplier relationship.

Therefore, in considering cloud adoption, it is important to know all the parties involved and their physical locations. The parties involved are not limited to the CSP and its employees, but also include all vendors that are in close contact with the cloud service provider and that may come in contact with user data. It is important to ensure that they are trustworthy (e.g., they are not involved in fraudulent activities, they are economically solvent). A good rule of thumb is to select CSPs that have significant history in the cloud services industry and can provide solid business references.

(11)

The answer to the question “How can I rely on a CSP to protect my data?” will be influenced by a number of aspects:

• The possibility for auditing and the verification of controls. Does the cloud user have a view of the CSP’s mitigating controls to handle risk—controls related to security, availability, processing integrity, confidentiality and privacy? In this context, several standards or best practices are available for CSPs to report on their security status. The American Institute of Certified Public Accountants (AICPA) SOC 2 report or any security certification (International Organization for Standardization [ISO 2700x]) can be used to evaluate the security practices of a possible CSP. Guidance on how to fully understand and use AICPA SOC 2 reports can be found in ISACA’s SOC 2SM_{User Guide, scheduled to be}

available by the end of September 2012. The enterprise must identify compliance requirements or select a recognized security framework (e.g., ISO, Statements on Standards for Attestation Agreements [SSAE] 16, Payment Card Industry Data Security Standard [PCI DSS], Health Insurance Portability and Accountability Act [HIPAA], US Sarbanes-OxleyAct [SOX]) and request proof of compliance from the CSP.

• The CSP financial position and market recognition

• Is the CSP certified or recognized by one or more security standards authorities (e.g., the National Information Assurance Partnership [NIAP], which is a

US government body operated by the National Security Agency [NSA], and NIST)? • The availability of business continuity plans (BCPs), disaster recovery plans

(DRPs) and robust backup procedures, taking into account multifacility,

multicountry CSPs

• The quality of the user’s own data and data classification; policies, principles and frameworks; processes; organizational structures; culture, ethics and behaviour; services, infrastructure and applications; people, skills and competencies; and risk appetite (see chapter 4)

• General negotiations and relationship with the service provider: contracts, SLAs, communication processes, roles and responsibilities matrices, etc.

(12)

(13)

3. o

vervIew

of

s

ecurIty

r

Isk

And

t

hreAts

r

elAted

to

o

perAtIng

In

the

c

loud

Recent publications and media coverage have discussed the extensive benefits of migrating to the cloud: better management and allocation of IT physical resources, flexibility, high scalability, elasticity and cost savings. However, changing from one environment to another entails some disadvantages as well, e.g., in the form of new risk or new threats. Enterprises that are considering moving to the cloud must be aware of the risk and threats involved to decide whether the cloud is an appropriate solution and which service and deployment models entail a degree of risk that they can manage and are willing to accept.

Once the enterprise is aware of the risk and threats, it can implement a series of mitigating actions and controls to reduce or eliminate the threats related to the service and delivery model it has chosen and to ensure that the benefits of moving to the cloud are realized as expected.

Visibility as a Critical Factor

The decision to move to the cloud implies that the information assets of the enterprise will be “managed” by the CSP. However, the enterprise—the owner of the assets—is likely to have little knowledge or “visibility” into the people, processes and technology supporting its information assets. The lack of visibility is also known as “abstraction;” to counter the effects the CSP should provide to customers full details on how its assets are managed.

The level of abstraction or visibility provided by the CSP becomes extremely important when evaluating risk. In fact, each service model corresponds to an abstraction level based on the number of layers in the Internet Protocol (IP) stack being replaced by the cloud. For this reason, IaaS represents the lowest abstraction level (infrastructure only) and SaaS the highest (application + middleware + infrastructure).

The higher the abstraction level, the higher the risk or the number of threats to take into account because risk is cumulative (figure 1). However, CSPs often offer only

visibility into the cloud stack corresponding to the service model chosen. Security professionals must be aware of this factor when evaluating a move to the cloud. A common mistake is to assume that SaaS will not also be subject to risk related to infrastructure; however, risk and threats are there. They are on a layer that is less visible because it is no longer under the operational responsibility of the enterprise, but is under that of the CSP.

(14)

Figure 1—Cloud 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 information assets are we considering moving to the cloud?”

Information assets can be roughly categorized as data, applications and processes. These assets are commonly subject to the following risk events:2

• Unavailability—The asset is unavailable and cannot be used or accessed by the

enterprise. The cause can be accidental (failure of the infrastructure), intentional (distributed denial-of-service [DDoS] attacks) or legal (subpoena of database holding all data in a case of multitenancy architecture where one client’s data are subject to legal investigation).

• Loss—The asset is lost or destroyed. The cause can be accidental (natural disaster,

wrong manipulation, etc.) or intentional (deliberate destruction of data).

• Theft—The asset has been intentionally stolen and is now in possession of another

individual/enterprise. Theft is a deliberate action that can involve data loss. • Disclosure—The asset has been released to unauthorized staff/enterprises/

organizations or to the public. Disclosure can be accidental or deliberate. This also includes the undesired, but legal, access to data due to different regulations across international borders.

Data are commonly the most valuable assets and the most probable targets of attacks in the cloud. However, it is important not to overlook the risk related to applications and processes. The business impact of long DDoS attacks cannot always be absorbed by an enterprise; although no data loss or disclosure is suffered,

Client Assumes All Data and Application

Security Risk IaaS Infrastructure as a Service APIs Abstraction Hardware Facilities Core Connectivity and Delivery APIs Integration and Middleware

Infrastructure as a Ser vice (IaaS) Infrastructure as a Ser vice (IaaS) Platform as a Ser vice (P aaS) Infrastructure as a Ser vice (IaaS) Platform as a Ser vice (P aaS) Software as a Ser vice (SaaS) Abstraction Hardware Facilities Core Connectivity and Delivery APIs APIs Presentation

Modality PresentationPlatform

Data Metadata Content Applications

Integration and Middleware

Abstraction Hardware Facilities Core Connectivity and Delivery PaaS Platform as a Service SaaS Software as a Service

Data and Application Security Risk

Per SLA

2_{ISACA’s Risk IT framework considers the following risk events: interruption, destruction, theft and}

disclosure. However, the terms “unavailability” (interruption) and “loss” (destruction) are found to be more suitable for the assets presented in this context.

(15)

paralyzing the systems has direct, negative effects on the data. Disclosure of details about how applications handle critical information or about internal enterprise processes could pave the way to more selective attacks with greater consequences.

Figure 2 explains at a high level the possible impact of the four risk events on assets.

Figure 2—Impact of Risk Events on Assets

Type Unavailability Loss Theft Disclosure

Data Disruption of activities; lack of resources to keep on with “business as usual;” possibility of data poisoning 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 Business competitive disadvantage; possibility of blackmail; loss of credibility with customers/clients Damage to company reputation or image; possibility of regulatory sanctions; financial impact Applications/

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

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.

(16)

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.

(17)

Risk Factors by Service Model

S1. IaaS

With IaaS, the CSP provides the enterprise with fundamental computing

resources/equipment (storage, hardware, servers and network components) while the enterprise remains in control of the operating system (OS) and applications installed. Risk-decreasing factors:

S1.A Scalability and elasticity—Lack of physical resources is no longer an

issue. Due to the scalable nature of cloud technologies, the CSP can provide capacity on demand at low cost to support peak loads (expected or unexpected). Elasticity eliminates overprovisioning and underprovisioning of IT resources, allowing better cost optimization. This becomes a great advantage for resilience when defensive measures or resources need to be expanded quickly (e.g., during DDoS attacks).

Risk affected—Unavailability

S1.B DRP and backup—CSPs should already have in place, as common practice,

disaster recovery and backup procedures. However, recovery point objective (RPO), recovery time objective (RTO), and backup testing frequency and procedures provided by the CSP should be consistent with the enterprise security policy.

Risk affected—Unavailability, loss

S1.C Patch management—Cloud infrastructures are commonly based on

hypervisors and are controlled through a central hypervisor manager or client. The hypervisor manager allows the necessary patches to be applied across the infrastructure in a short time, reducing the time available for a new vulnerability to be exploited.

Risk affected—Unavailability, loss, theft, disclosure

Risk-increasing factors:

S1.D Legal transborder requirements—CSPs are often transborder, and different

countries have different legal requirements, especially concerning personal private information. The enterprise might be committing a violation of regulations in other countries when storing, processing or transmitting data within the CSP’s infrastructure without the necessary compliance controls. Furthermore, government entities in the hosting country may require access to the enterprise’s information with or without proper notification.

Risk affected—Disclosure

S1.E Multitenancy and isolation failure—One of the primary benefits of the

cloud is the ability to perform dynamic allocation of physical resources when required. The most common approach is a multi-tenant environment (public cloud), where different entities share a pool of resources, including storage, hardware and network components. All resources allocated to a particular tenant should be “isolated” and protected to avoid disclosure of information to other tenants. For example, when allocated storage is no longer needed

(18)

by a client it can be freely reallocated to another enterprise. In that case, sensitive data could be disclosed if the storage has not been scrubbed thoroughly (e.g., using forensic software).

Risk affected—Theft, disclosure

S1.F Lack of visibility surrounding technical security measures in place—For any

infrastructure, intrusion detection systems (IDS)/intrusion prevention systems (IPS) and security incident and event management (SIEM) capabilities must be in place. It is the responsibility of the CSP to provide these capabilities to its customers. To ensure that there are no security gaps, the security policy and governance of the CSP should match those of the enterprise.

S1.G Absence of DRP and backup—The absence of a proper DRP or backup

procedures implies a high risk for any enterprise. CSPs should provide such basic preventive measures aligned with the enterprise’s business needs (in terms of RTO/RPO).

S1.H Physical security—In an IaaS model, physical computer resources are

shared with other entities in the cloud. If physical access to the CSP’s infrastructure is granted to one entity, that entity could potentially access information assets of other entities. The CSP is responsible for applying physical security measures to protect assets against destruction or unauthorized access.

S1.I Data disposal—Proper disposal of data is imperative to prevent

unauthorized disclosure. If appropriate measures are not taken by the CSP, information assets could be sent (without approval) to countries where the data can be legally disclosed due to different regulations concerning sensitive data. Disks could be replaced, recycled or upgraded without proper cleaning so that the information still remains within storage and can later be retrieved. When a contract expires, CSPs should ensure the safe disposal or destruction of any previous backups.

Risk affected—Disclosure

S1.J Offshoring infrastructure—Offshoring of key infrastructure expands the

attack surface area considerably. In practice this means that the information assets in the cloud need to integrate back to other noncloud-based assets within the boundaries of the enterprise. These communications (normally done through border gateway devices) could be insecure, exposing both the cloud and internal infrastructures.

S1.K Virtual machine (VM) security maintenance—IaaS providers allow

consumers to create VMs in various states (e.g., active, running, suspended and off). Although the CSP could be involved, the maintenance of security updates is generally the responsibility of the customer only. An inactive VM could be easily overlooked and important security patches could be left unapplied. This out-of-date VM could become compromised when activated.

(19)

S1.L Cloud provider authenticity—Although 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 consumer’s responsibility to check the identity of the cloud provider to ensure that it is not an imposter.

S2. PaaS

PaaS adds a layer to IaaS by providing the capability to deploy applications in a cloud infrastructure. The applications are developed using the programming languages and tools supported by the CSP. Thus, physical support, OS and

programming tools are the responsibility of the CSP, while the applications and the data remain under the control of the enterprise. This service model entails the same impacts on risk as IaaS, plus the following factors.

Risk-decreasing factor:

S2.A Short development time—Using the service oriented architecture (SOA)

library provided by the CSP, applications can be developed and tested within a reduced time frame because SOA provides a common framework for application development.

S2.B Application mapping—If current applications are not perfectly aligned with

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

S2.C SOA-related vulnerabilities—Security for SOA presents new challenges

because vulnerabilities arise not only from the individual elements, but also from their mutual interaction. Because the SOA libraries are under the responsibility of the CSP and are not completely visible to the enterprise, there may exist unnoticed application vulnerabilities.

S2.D Application disposal—When applications are developed in a PaaS

environment, originals and backups should always be available. In the event of a contract termination, the details of the application could be disclosed and used to create more selective attacks on applications.

(20)

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 security—CSPs depend on the good reputation of their software

capabilities to maintain their SaaS offering. Consequently, they introduce additional features to improve the resilience of their software (e.g., security testing or strict versioning) or to inform users about the exact state of their business application (e.g., specific software logging and monitoring).

S3.B Application patch management—Due to the fact that the SaaS application

service is managed globally and only by the CSPs, application patch management is more effective, allowing patches to be deployed in little time with limited impact.

S3.C Data ownership—The CSP provides the applications and the customer

provides the data. If data ownership is not clearly defined, the CSP could refuse access to data when required or even demand fees to return the data once the service contracts are terminated.

Risk affected—Unavailability, loss, disclosure

S3.D Data disposal—In the event of a contract termination, the data fed into the

CSP’s application must be erased immediately using the necessary tools to avoid disclosures and confidentiality breaches (forensic cleaning may be required for sensitive data).

S3.E Lack of visibility into software systems development life cycle (SDLC)—

Enterprises that use cloud applications have little visibility into the software SDLC. Customers do not know in detail how the applications were

developed and what security considerations were taken into account during the SDLC. This could lead to an imbalance between the security provided by the application and the security required by customers/users.

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

CSPs offer their services and applications to several customers concurrently. Those customers share servers, applications and, eventually, data. If data access is not properly managed by the CSP application, one customer could obtain access to another customer’s data.

(21)

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

procedures or other offerings to facilitate data or service portability from CSP to CSP. This can make it very difficult for the enterprise to migrate from one CSP to another or to bring services back in-house. It can also result in serious business disruption or failure should the CSP go bankrupt, face legal action, or be the potential target for an acquisition (with the likelihood of sudden changes in CSP policies and any agreements in place). If the customer-CSP relationship goes sour and the enterprise wants to bring the data back in-house, the question of how to securely render the data becomes critical because the in-house applications may have been decommissioned or “sunsetted” and there is no application available to render the data.

S3.H Broad exposure of applications—In a cloud environment, the applications

offered by the CSP have broader exposure which increases the attack space. Additionally, it is quite common that those applications still need to integrate back to other noncloud applications within the boundaries of the enterprise. Standard network firewalls and access controls are sometimes insufficient to protect the applications and their external interactions. Additional security measures may be required.

Risk affected—Unavailability, loss, disclosure

S3.I Ease to contract SaaS—Business organizations may contract cloud

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

S3.J Lack of control of the release management process—As described before,

CSPs are able to introduce patches in their applications quickly. These deployments are often done without the approval (or even the knowledge) of the application users for practical reasons: if an application is used by hundreds of different enterprises, it would take an extremely long time for a CSP to look for the formal approval of every customer. In this case, the enterprise could have no control (or no view) of the release management process and could be subject to unexpected side effects.

S3.K Browser vulnerabilities—As a common practice, applications offered

by SaaS providers are accessible to customers via secure communication through a web browser. Web browsers are a common target for malware and attacks. If the customer’s browser becomes infected, the access to the application can be compromised as well.

Risk Factors by Deployment Model

Cloud deployment models do not have the same abstraction as cloud service models. That is, risk is not cumulative, but particular to each model. However, “trust” among the different entities (CSP, customers, CSP’s third-party service providers, etc.) is an important factor—not just trust between the CSP and the customer, but enough trust in the other tenants sharing computing resources

(22)

hosting the enterprise’s information assets. If a user abuses the infrastructure and services of the public cloud, the entire infrastructure might be at risk of failure, theft or seizure (for forensics), including the services used by other enterprises. It is important as part of the decision process to carefully consider which assets can securely be hosted in a public cloud and which cannot.

D1. Public Cloud

In a public cloud, the CSP shares infrastructure and resources among various unrelated enterprises and individuals.

D1.A Public reputation—Providers of public cloud services are aware that they are

generally perceived as more “risky.” It is critical for them to ensure a good reputation as a secure provider or customers will simply move elsewhere.

D1.B Full sharing of the cloud (data pooling)—The cloud infrastructure is

shared by multiple tenants of the cloud service provider. These tenants have no relation to the enterprise or other tenants in the same space, therefore no common interest and concerns for security.

D1.C Collateral damage—If one tenant of a public cloud is attacked, there could

be an impact to the other tenants of the same CSP, even if they are not the intended target (e.g., DDoS). Another possible scenario of collateral damage could be a public cloud IaaS that is affected by an attack exploiting vulnerabilities of software installed by one of the tenants.

D2. Community Cloud

In the community cloud, cloud services are deployed for the use of a group of entities who share an inherent level of “trust.” In some cases, all the entities are subject to a common security policy (thus making the trust factor stronger). In other cases, there is no common security strategy or policy. As described previously, there are on-site and off-site community clouds.

D2.A Same group of entities—The component of “trust” among the entities in

a community cloud makes the level of risk lower than in a public cloud. (However, it remains higher than in a private cloud.)

D2.B Dedicated access for the community—Dedicated access can be configured

for authorized community users only.

(23)

Risk-increasing factor:

D2.C Sharing of the cloud—Different entities may have different security

measures or security requirements in place, even if they belong to the same enterprise. This could render an entity at risk because of the faulty procedures or SLAs of another entity, or simply because of differing security levels for the same type of data.

Risk affected—Loss, theft, disclosure

D3. Private Cloud

In a private cloud, cloud services are deployed for the exclusive use of one enterprise. No interaction with other entities is allowed within the cloud. As described previously, there are on-site and off-site private clouds.

D3.A Can be built on-premises—Physical or location-related considerations can

be more closely controlled by the enterprise because the cloud infrastructure can be located on the enterprise’s premises. Global enterprise security policies would apply.

D3.B Performance—Affects on-site private clouds. Because the private cloud is

deployed inside the firewall on the enterprise’s intranet, transfer rates are dramatically increased (fewer nodes to cross). Storage capacity can also be higher; private clouds usually start with a few terabytes and can be increased by adding disks.

D3.C Application compatibility—While applications that have already been confirmed

to be virtualization-friendly are likely to run well in a private cloud environment, problems can occur with older and/or customized software that assumes direct access to resources. Larger applications that currently run on dedicated specialized clusters with hardwiring into proprietary runtime and management environments may also be questionable candidates for migration, at least until standards settle and vendors take steps to make their solutions private-cloud-compatible. In the meantime, compatibility testing and remediation are critical.

D3.D Investments required—Making a business case for shared infrastructure

and the necessary training or recruitment to acquire associated skills is notoriously hard at the best of times. Although the word “cloud” has a high profile, messages from vendors and service providers are often confusing and contradictory, making seeking support from senior stakeholders even more of an issue. If the head of finance thinks cloud is all about getting rid of infrastructure, it can be difficult to explain that investments are needed in new equipment, software and tools. The enterprise must conduct a cost-benefit analysis and prepare a business case to determine whether the cloud is a viable solution to meet specific business requirements, and justify any expenses.

(24)

D3.E Cloud IT skills required—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 investment and maintenance costs.

Risk affected—Cost

D4. Hybrid Cloud

Hybrid cloud is a model that allows enterprises to create a mix of public,

community and private clouds, depending on the level of “trust” required for their information assets. For example, an enterprise could decide that its web portals can be migrated to a public cloud, but its main business application should be migrated to a private cloud, this combination will create a hybrid cloud model.

Because hybrid clouds are a mix of the other three models, their risk-increasing or risk-decreasing factors are the same as those models. There is, however, one risk-increasing factor related mainly to this model:

D4.A Cloud-interdependency—If the enterprise mixes two or more different

types of clouds, strict identity controls and strong credentials will be needed to allow one cloud to have access to another. This is similar to a common network infrastructure problem: how to allow access from a low-level security zone to a high-level security zone?

Overview of Threats and Mitigating Actions

When considering these implementation strategies, service models and related risk, it is noteworthy that most of the risk-increasing factors affect theft and disclosure while most of the risk-decreasing factors affect unavailability and loss. This could be interpreted as a trade-off.

Risk-decreasing factors are exploited through the implementation of controls to ensure that the enterprise receives the full benefits of the cloud. Control objectives for cloud operations are covered extensively in ISACA’s publication IT Control

Objectives for Cloud Computing: Controls and Assurance in the Cloud.

This section addresses the possible threats that could exploit any of the risk-increasing factors previously described. It also maps the threats to mitigating actions found in

COBIT 5 for Information Security, which explains in more detail selected terminology

and how to implement certain actions within the enterprise. (A table mapping threats and mitigating actions can be found in the appendices section.)

With the implementation of these mitigation actions, the impact and probability of a risk event are greatly reduced, depending on the level of severity of the controls involved. But risk and threats still exist, although reduced. Specific risk assessments must be conducted periodically to evaluate the risk situation of the assets specific to the enterprise and identify improvement opportunities.

(25)

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 could result from a forgery/theft of legitimate credentials or a common technical practice (e.g., administrator permissions override).

• Mitigation:

– A contractual agreement is necessary to officially clarify who is allowed to access the enterprise’s information, naming specific roles for CSP employees and external partners.

– Request that the CSP provide detailed technical specifications of its IAM system for the enterprise’s CISO (or equivalent authority) to review and approve. If necessary, include additional controls to ensure robustness of the CSP’s IAM system. Most CSPs will not provide such details due to internal security policies, but the enterprise can request controls and benchmarks as an alternative (e.g., result of penetration testing on the CSP’s IAM systems). – Use corporate IAM systems instead of CSP’s IAM systems. The IAM

remains the responsibility of the enterprise, so no access to assets can be granted without the knowledge of the enterprise. It requires the approval of the CSP and the establishment of a secure channel between the CSP infrastructure and the corporate IAM system.

• Related guidance in COBIT 5 for Information Security:

– 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 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 enterprise’s information, naming specific roles for CSP employees and external partners. All controls protecting the enterprise’s information assets must be clearly documented in the contract agreement or SLA. – Encrypt all sensitive assets that are being migrated to the CSP, and ensure

that proper key management processes are in place. This will consume part of the allocated resources due to the encrypt/decrypt process and global performance can be affected.

– Request the CSP’s technical specifications and controls to ensure that the data are properly wiped when requested.

– Use a private cloud deployment model (no multitenancy).

3_{Related guidance on technical threats and mitigating actions can also be found in COBIT 5, DSS05} Manage security services.

(26)

– 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 CSP’s 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 enterprise’s information, naming specific roles for CSP employees and external partners. All controls protecting the enterprise’s information assets must be clearly documented in the contract agreement or SLA. – Use 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)

. 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 CSP’s internal SLA for hypervisor vulnerability management, patch management and release management when new hypervisor vulnerabilities are discovered. The SLA must contain detailed specifications about vulnerability classification and actions taken according to the severity level.

(27)

• 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

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

– Appendix G. Detailed Guidance: People, Skills and Competencies Enabler: . G.5 Information Security Operations

. 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

(28)

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 enterprise’s 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

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

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

(29)

• 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

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

– Encrypt all sensitive assets being migrated to the CSP prior to the migration to prevent disclosure and ensure proper key management is in place. This can affect the performance of the system.

– Appendix C. Detailed Guidance: Organizational Structures Enabler: . C.5 Information Custodians/Business Owners

B. Asset disposal

• Related risk factors: S1.I, S2.E, S3.D

• Description: In the event of contract termination, to prevent disclosure of the enterprise’s assets, those assets should be removed from the cloud using tools and processes commensurate to data classification; forensic tools may be necessary to remove sensitive data (or other tools that ensure a complete wipeout).

• Mitigation:

– Request CSP’s technical specifications and controls that ensure that data are properly wiped and backup media are destroyed when requested.

– Include terms in the contract that require, upon contract expiration or any event ending the contract, a mandatory data wipe carried out under the enterprise’s review.

4_{Related guidance on regulatory threats and mitigating actions can be found in COBIT 5, MEA03} Monitor, evaluate and assess compliance with external requirements.

(30)

C. Asset location

• Related risk factor: S1.D

• Description: Technical information assets (data, logs, etc.) are subject to the regulations of the country where they are stored or processed. In the cloud, an enterprise may, without notification, migrate information assets to countries where regulations are less restrictive or their transmission is prohibited (personal information in particular). Unauthorized entities that cannot have access to assets in one country may be able to obtain legal access in another country. Conversely, if assets are moved to countries with stricter regulations, the enterprise can be subject to legal actions and fines for noncompliance. • Mitigation:

– Request the CSP’s list of infrastructure locations and verify that regulation in those locations is aligned with the enterprise’s requirements.

– Include terms in the service contract to restrict the moving of enterprise assets to only those areas known to be compliant with the enterprise’s own regulation.

– To prevent disclosure, encrypt any asset prior to migration to the CSP, and ensure proper key management is in place.

– Appendix G. Detailed Guidance: People, Skills and Competencies Enabler: . G.4 Information Security Architecture Development

. F.2 Security Awareness

Information Security Governance5

A. Physical security on all premises where data/applications are stored • Related risk factor: S1.H

• Description: Physical security is required in any infrastructure. When the enterprise migrates assets to a cloud infrastructure, those assets are still subject to the corporate security policy, but they can also be physically accessed by the CSP’s staff, which is subject to the CSP’s security policy. There could be a gap between the security measures provided by the CSP and the requirements of the enterprise.

• Mitigation:

– Request the CSP’s physical security policy and ensure that it is aligned with the enterprise’s security policy.

– Request that the CSP provide proof of independent security reviews or certification reports that meet the enterprise’s compliance requirements (e.g., AICPA SSAE 16 SOC 2 report, SOX, PCI DSS, HIPAA, ISO certification). – Include in the contract language that requires the CSP to be aligned with the

enterprise’s security policy and to implement necessary controls to ensure it. – Request the CSP’s disaster recovery plans and ensure that they contain the

necessary countermeasures to protect physical assets during and after a disaster.

5_{Related guidance on information security governance threats and mitigating actions can be found in}