2 Security Considerations for Cloud Computing

Transcription

1 1

2 2 Security Considerations for Cloud Computing About ISACA With more than 100,000 constituents in 180 countries, ISACA ( 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 (CRISC TM ) 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 USA Phone: Fax: [email protected] Web site: Feedback: Participate in the ISACA Knowledge Center: Follow ISACA on Twitter: Join ISACA on LinkedIn: ISACA (Official), Like ISACA on Facebook: ISBN Security Considerations for Cloud Computing

3 Acknowledgments 3 ISACA wishes to recognize: Development Team Stefanie Grijp, PwC, Belgium Chris Kappler, PwC, Belgium Bart Peeters, CISA, PwC, Belgium Tomas Clemente Sanchez, PwC, Belgium Acknowledgments Work Group Yves Marcel Le Roux, CISM, CISSP, CA Technologies, France Alan Mayer, USA Perry Menezes, CISM, CRISC, CIPP, CISSP, Deutsche Bank, USA Yogendra Rajput, India Paras Shah, CISA, CGEIT, CRISC, CA, Transpire Pty Ltd., Australia Brett Smith, CISSP, ISSAP, Deutsche Bank, USA Expert Reviewers Muhammad Amir, CISA, CISM, CRISC, CEH, CISSP, MCSE Security, Security+, NetSol Technologies Ltd., Pakistan Mark E.S. Bernard, CISA, CSIM, CGEIT, CRISC, CISSP, PM, ISO 27001, SABSA-F2, TechSecure Holdings Inc., Canada Roberta Donaldson Caraglia, EMCIS, ITIL V3, EMC Consulting, USA Christos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., Greece Meenu Gupta, CISA, CISM, CBP, CIPP, CISPP, Mittal Technologies, USA Masatoshi Kajimoto, CISA, CRISC, Independent Consultant, Japan Hesham Moussa, CISM, Lumension Security, USA Jo Stewart-Rattray, CISA, CISM, CGEIT, CRISC, CSEPS, RSM Bird Cameron, Australia Lou Tinto, CISA, CRISC, CFE, CIA, NYLB, USA Sukhwinder Wadhwa, ITIL V3, Infosys Ltd, India Justin Williams, CA (SA), Transnet, South Africa ISACA Board of Directors Gregory T. Grocholski, CISA, The Dow Chemical Co., USA, International President Allan Boardman, CISA, CISM, CGEIT, CRISC, ACA, CA (SA), CISSP, Morgan Stanley, UK, Vice President Juan Luis Carselle, CISA, CGEIT, CRISC, Wal-Mart, Mexico, Vice President Christos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., Greece, Vice President Ramses Gallego, CISM, CGEIT, CCSK, CISSP, SCPM, 6 Sigma, Quest Software, Spain, Vice President Tony Hayes, CGEIT, AFCHSE, CHE, FACS, FCPA, FIIA, Queensland Government, Australia, Vice President Jeff Spivey, CRISC, CPP, PSP, Security Risk Management Inc., USA, Vice President Marc Vael, Ph.D., CISA, CISM, CGEIT, CRISC, CISSP, Valuendo, Belgium, Vice President Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Past International President Emil D Angelo, CISA, CISM, Bank of Tokyo-Mitsubishi UFJ Ltd., (retired), USA, Past International President John Ho Chi, CISA, CISM, CRISC, CBCP, CFE, Ernst & Young LLP, Singapore, Director Krysten McCabe, CISA, The Home Depot, USA, Director Jo Stewart-Rattray, CISA, CISM, CGEIT, CRISC, CSEPS, RSM Bird Cameron, Australia, Director Knowledge Board Marc Vael, Ph.D., CISA, CISM, CGEIT, CRISC, CISSP, Valuendo, Belgium, Chairman Steven A. Babb, CGEIT, CRISC, Betfair, UK Thomas E. Borton, CISA, CISM, CRISC, CISSP, Cost Plus, USA Phillip J. Lageschulte, CGEIT, CPA, KPMG LLP, USA Salomon Rico, CISA, CISM, CGEIT, Deloitte, Mexico Steven E. Sizemore, CISA, CIA, CGAP, Texas Health and Human Services Commission, USA

4 4 Security Considerations for Cloud Computing Acknowledgments (cont.) Guidance and Practices Committee Phillip J. Lageschulte, CGEIT, CPA, KPMG LLP, USA, Chairman Dan Haley, CISA, CGEIT, CRISC, MCP, Johnson & Johnson, USA Yves Marcel Le Roux, CISM, CISSP, CA Technologies, France Aureo Monteiro Tavares Da Silva, CISM, CGEIT, Pelissari, Brazil Jotham Nyamari, CISA, Deloitte, USA Connie Lynn Spinelli, CISA, CRISC, CFE, CGMA, CIA, CISSP, CMA, CPA, GRC Solutions LLC, USA John William Walker, CISM, CRISC, FBCS CITP, ITPC Secure Bastion Limited, UK Siang Jun Julia Yeo, CISA, CPA (Australia), Visa Worldwide Pte. Limited, Singapore Nikolaos Zacharopoulos, CISA, CISSP, 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 Table of Contents 5 Table of Contents 1. Introduction... 7 Background... 7 Purpose of This Document... 7 Who Should Use This Guide?... 7 Scope and Approach Cloud Computing... 9 Essential Characteristics... 9 Cloud Service Models... 9 Cloud Deployment Models The Key Element of Trust Overview of Security Risk and Threats Related to Operating in the Cloud Visibility as a Critical Factor Information Assets and Risk Cost Considerations (or Cost as a Risk Event) Privacy Considerations Risk Assessment When Migrating to the Cloud Risk Factors by Service Model S1. IaaS S2. PaaS S3. SaaS Risk Factors by Deployment Model D1. Public Cloud D2. Community Cloud D3. Private Cloud D4. Hybrid Cloud Overview of Threats and Mitigating Actions Technical Regulatory Information Security Governance The Path to the Decision and Beyond Step 1. Preparation of the Internal Environment Step 2. Selection of the Cloud Service Model Breakdown of Cloud Service Model Decision Tree Step 3. Selection of the Cloud Deployment Model Breakdown of Cloud Deployment Decision Tree Step 4. Selection of the Cloud Service Provider... 51

6 6 Security Considerations for Cloud Computing Appendix A. The Path to the Decision and Beyond Checklist Appendix B. Overview of Different Risk Factors per Service and Deployment Model Appendix C. Mapping Threats and Mitigating Actions to COBIT 5 for Information Security Abbreviations References... 79

7 1. Introduction 7 1. Introduction Background In recent years cloud computing has become more than a just another IT buzzword. It refers to a business trend that is expected to have and for some enterprises already has a significant impact on the way enterprises operate. It is likely that cloud computing will gain even more importance as both the cloud and cloud service provider markets mature. In times of cost optimization and economic downturn the cloud can be perceived as a way to realize a more cost-effective approach to technological support of the enterprise. However, security and data privacy concerns are frequently seen as critical issues or even barriers for adopting cloud computing services. Purpose of This Document This publication is not intended to provide yet another detailed, theoretical description of the concept of cloud and the different alternatives of cloud computing. Instead, it is designed to present practical guidance and facilitate the decision process for IT and business professionals concerning the decision to move to the cloud. This guide aims to enable effective analysis and measurement of risk using items such as decision trees and checklists outlining the security factors to be considered when evaluating the cloud as a potential solution. Who Should Use This Guide? Just as cloud computing is about more than just IT infrastructures, platforms and applications, the decision to operate in the cloud should not be taken solely by IT organizations. The use of cloud services might entail high risk for the business and should therefore be evaluated by responsible parties from the different control functions within an enterprise. This guide is meant for all current and potential cloud users who need to ensure protection of information assets. Scope and Approach This publication provides practical guidance regarding the decision process surrounding the adoption of cloud services. This requires a short theoretical description of cloud concepts before presenting the most common risk areas and threats in the cloud landscape. This guide also provides an approach to cope with these risk areas and threats. (To avoid scope creep, this publication s discussion of risk and threats is limited to cloud-specific elements.)

8 8 Security Considerations for Cloud Computing 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. Cloud Computing 9 2. Cloud Computing Cloud computing is defined by the US National Institute of Standards and Technology (NIST) as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. 1 There are five essential characteristics, three types of service models and four major deployment models to be taken into account relative to cloud computing. To ensure a common understanding of these models, the characteristics of each are described in the following sections. Essential Characteristics The essential characteristics of cloud computing are: On-demand self-service Computing capabilities can be provisioned without human interaction from the service provider. Broad network access Computing capabilities are available over the network and can be accessed by diverse client platforms. Resource pooling Computer resources are pooled to support a multitenant model. Rapid elasticity Resources can scale up or down rapidly and in some cases automatically in response to business demands. Measured service Resource utilization can be optimized by leveraging charge-per-use capabilities. Cloud Service Models There are three main service models and each represents a different level of involvement of an outsourcing partner or cloud service provider (CSP): Infrastructure as a Service (IaaS) In an IaaS solution, the CSP provides cloud users with processing, storage, networks and other fundamental computing resources. Operating systems and applications, however, are the responsibility of the user and are not included in the service offering of the CSP. Examples are: Rackspace, Equinix, Softlayer, iomart Group plc, Amazon Web Services LLC, etc. Platforms as a Service (PaaS) PaaS entails the CSP making available infrastructures and platforms on which cloud users deploy their own applications. This requires the CSP to support programming languages, libraries, services and tools. Examples are: Google App Engine TM, 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 Standards and Technology (NIST) Special Publication (SP) , USA, 2011

10 10 Security Considerations for Cloud Computing In each of these models, cloud users do not own, operate or control the underlying cloud infrastructure. They may, however, have (limited) control over operating systems and applications. Cloud Deployment Models The cloud is most often deployed in one of three 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 (EC2 TM ), 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 2. Cloud Computing 11 The answer to the question How can I rely on a CSP to protect my data? will be influenced by a number of aspects: The possibility for auditing and the verification of controls. Does the cloud user have a view of the CSP s mitigating controls to handle risk controls related to security, availability, processing integrity, confidentiality and privacy? In this context, several standards or best practices are available for CSPs to report on their security status. The American Institute of Certified Public Accountants (AICPA) SOC 2 report or any security certification (International Organization for Standardization [ISO 2700x]) can be used to evaluate the security practices of a possible CSP. Guidance on how to fully understand and use AICPA SOC 2 reports can be found in ISACA s SOC 2 SM User Guide, scheduled to be available by the end of September 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 12 Security Considerations for Cloud Computing Page intentionally left blank

13 3. Overview of Security Risk and Threats 13 Related to Operating in the Cloud 3. Overview of Security Risk and Threats Related to Operating in the Cloud Recent publications and media coverage have discussed the extensive benefits of migrating to the cloud: better management and allocation of IT physical resources, flexibility, high scalability, elasticity and cost savings. However, changing from one environment to another entails some disadvantages as well, e.g., in the form of new risk or new threats. Enterprises that are considering moving to the cloud must be aware of the risk and threats involved to decide whether the cloud is an appropriate solution and which service and deployment models entail a degree of risk that they can manage and are willing to accept. Once the enterprise is aware of the risk and threats, it can implement a series of mitigating actions and controls to reduce or eliminate the threats related to the service and delivery model it has chosen and to ensure that the benefits of moving to the cloud are realized as expected. Visibility as a Critical Factor The decision to move to the cloud implies that the information assets of the enterprise will be managed by the CSP. However, the 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 14 Security Considerations for Cloud Computing Client Assumes All Data and Application Security Risk IaaS Infrastructure as a Service APIs Core Connectivity and Delivery Abstraction Hardware Facilities Infrastructure as a Service (IaaS) Figure 1 Cloud Service Models PaaS Platform as a Service Integration and Middleware APIs Core Connectivity and Delivery Abstraction Hardware Facilities Infrastructure as a Service (IaaS) Platform as a Service (PaaS) Data and Application Security Risk Per SLA SaaS Software as a Service Presentation Modality APIs Applications Presentation Platform Data Metadata Content Integration and Middleware APIs Core Connectivity and Delivery Abstraction Hardware Facilities Infrastructure as a Service (IaaS) Platform as a Service (PaaS) Software as a Service (SaaS) Source: Universal Model, Cloud Security Alliance. Used with permission. Information Assets and Risk The first question to ask when evaluating cloud-related risk is: Which information assets are we considering moving to the cloud? Information assets can be roughly categorized as data, applications and processes. These assets are commonly subject to the following risk events: 2 Unavailability The asset is unavailable and cannot be used or accessed by the enterprise. The cause can be accidental (failure of the infrastructure), intentional (distributed denial-of-service [DDoS] attacks) or legal (subpoena of database holding all data in a case of multitenancy architecture where one client s data are subject to legal investigation). Loss The asset is lost or destroyed. The cause can be accidental (natural disaster, wrong manipulation, etc.) or intentional (deliberate destruction of data). Theft The asset has been intentionally stolen and is now in possession of another individual/enterprise. Theft is a deliberate action that can involve data loss. Disclosure The asset has been released to unauthorized staff/enterprises/ organizations or to the public. Disclosure can be accidental or deliberate. This also includes the undesired, but legal, access to data due to different regulations across international borders. Data are commonly the most valuable assets and the most probable targets of attacks in the cloud. However, it is important not to overlook the risk related to applications and processes. The business impact of long DDoS attacks cannot always be absorbed by an enterprise; although no data loss or disclosure is suffered, 2 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 3. Overview of Security Risk and Threats 15 Related to Operating in the Cloud paralyzing the systems has direct, negative effects on the data. Disclosure of details about how applications handle critical information or about internal enterprise processes could pave the way to more selective attacks with greater consequences. Figure 2 explains at a high level the possible impact of the four risk events on assets. Figure 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 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 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 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 16 Security Considerations for Cloud Computing For example, an enterprise that has migrated to a CSP possesses a database of customers and sends s to these customers to advertise new products. Both the database and the 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 s 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 3. Overview of Security Risk and Threats 17 Related to Operating in the Cloud Risk Factors by Service Model S1. IaaS With IaaS, the CSP provides the enterprise with fundamental computing resources/equipment (storage, hardware, servers and network components) while the enterprise remains in control of the operating system (OS) and applications installed. Risk-decreasing factors: S1.A Scalability and 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 18 Security Considerations for Cloud Computing by a client it can be freely reallocated to another enterprise. In that case, sensitive data could be disclosed if the storage has not been scrubbed thoroughly (e.g., using forensic software). Risk 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. Risk affected Unavailability, loss, theft, disclosure 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). Risk affected Unavailability, loss 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. Risk affected Theft, disclosure 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. S1.J Risk affected Disclosure 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. Risk affected Unavailability, loss, theft, disclosure 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. Risk affected Unavailability, loss, theft, disclosure

19 3. Overview of Security Risk and Threats 19 Related to Operating in the Cloud 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. Risk affected Unavailability, 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 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. Risk affected Unavailability, loss Risk-increasing factors: 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. Risk affected Theft, disclosure 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. Risk affected Unavailability, loss, theft, disclosure 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. Risk affected Theft, disclosure

20 20 Security Considerations for Cloud Computing S3. SaaS In a SaaS model, the CSP provides to the enterprise the capability to use applications running on the cloud infrastructure. The enterprise, in turn, provides to the CSP the data necessary to run the application. The physical infrastructure, OS, applications and data are the responsibility of the CSP. The enterprise has only the role of client/user. This service model entails the same impacts on risk as PaaS, plus the following factors. Risk-decreasing factors: S3.A Improved 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). Risk affected Unavailability, loss 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. Risk affected Unavailability, loss Risk-increasing factors: 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). Risk affected Theft, disclosure S3.E Lack of visibility into software systems development life cycle (SDLC) Enterprises that use cloud applications have little visibility into the software SDLC. Customers do not know in detail how the applications were developed and what security considerations were taken into account during the SDLC. This could lead to an imbalance between the security provided by the application and the security required by customers/users. Risk affected Unavailability, loss, theft, disclosure S3.F Identity and access management (IAM) To maximize their revenues, CSPs offer their services and applications to several customers concurrently. Those customers share servers, applications and, eventually, data. If data access is not properly managed by the CSP application, one customer could obtain access to another customer s data. Risk affected Loss, theft, disclosure

21 3. Overview of Security Risk and Threats 21 Related to Operating in the Cloud 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. Risk affected Unavailability, loss 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 Risk affected Unavailability, loss, theft, disclosure 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. Risk affected Unavailability, loss 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 affected Theft, disclosure Risk Factors by Deployment Model Cloud deployment models do not have the same abstraction as cloud service models. That is, risk is not cumulative, but particular to each model. However, trust among the different entities (CSP, customers, 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 22 Security Considerations for Cloud Computing 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. Risk-decreasing factors: 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. Risk affected Unavailability, loss, theft, disclosure Risk-increasing factors: D1.B Full sharing of the cloud (data pooling) The cloud infrastructure is shared by multiple tenants of the cloud service provider. These tenants have no relation to the enterprise or other tenants in the same space, therefore no common interest and concerns for security. Risk affected Unavailability, loss, theft, disclosure 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. Risk affected Unavailability, loss, theft, disclosure D2. Community Cloud In the community cloud, cloud services are deployed for the use of a group of entities who share an inherent level of trust. In some cases, all the entities are subject to a common security policy (thus making the trust factor stronger). In other cases, there is no common security strategy or policy. As described previously, there are on-site and off-site community clouds. Risk-decreasing factors: D2.A Same group of 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.) Risk affected Unavailability, loss, theft, disclosure D2.B Dedicated access for the community Dedicated access can be configured for authorized community users only. Risk affected Theft, disclosure

23 3. Overview of Security Risk and Threats 23 Related to Operating in the Cloud 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. Risk-decreasing factors: 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. Risk affected Unavailability, loss, theft, disclosure 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. Risk affected Unavailability, loss Risk-increasing factors: 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. Risk affected Unavailability, loss D3.D Investments required Making a business case for shared infrastructure and the necessary training or recruitment to acquire associated skills is notoriously hard at the best of times. Although the word cloud has a high profile, messages from vendors and service providers are often confusing and contradictory, making seeking support from senior stakeholders even more of an issue. If the head of finance thinks cloud is all about getting rid of infrastructure, it can be difficult to explain that investments are needed in new equipment, software and tools. The enterprise must conduct a cost-benefit analysis and prepare a business case to determine whether the cloud is a viable solution to meet specific business requirements, and justify any expenses. Risk affected Cost

24 24 Security Considerations for Cloud Computing 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? Risk affected Unavailability, loss, theft, disclosure Overview of Threats and Mitigating Actions When considering these implementation strategies, service models and related risk, it is noteworthy that most of the risk-increasing factors affect theft and disclosure while most of the risk-decreasing factors affect unavailability and loss. This could be interpreted as a trade-off. Risk-decreasing factors are exploited through the implementation of controls to ensure that the enterprise receives the full benefits of the cloud. Control objectives for cloud operations are covered extensively in 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 3. Overview of Security Risk and Threats 25 Related to Operating in the Cloud Technical 3 A. Vulnerable access management (infrastructure and application, public cloud): Related risk factors: S1.D, S3.F, D1.B, D2.C Description: Information assets could be accessed by unauthorized entities due to faulty or vulnerable access management measures or processes. This could result from a forgery/theft of legitimate credentials or a common technical practice (e.g., administrator permissions override). Mitigation: A contractual agreement is necessary to officially clarify who is allowed to access the 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 26 Security Considerations for Cloud Computing Related guidance in COBIT 5 for Information Security: Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:. G.3 Information Risk Management. G.6 Information Assessment and Testing and Compliance Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler:. F.5 Adequately Secured and Configured Systems in Line With Security Requirements and Security Architecture. F.9 Security Testing C. Multitenancy visibility: Related risk factors: S1.E, D1.B, D2.C Description: Due to the nature of multitenancy, some assets (e.g., routing tables, media access controls [MAC] addresses, internal IP addresses, local area network [LAN] traffic) can be visible to other entities in the same cloud. Malicious entities in the cloud could take advantage of the information; for example, by utilizing shared routing tables to map the internal network topology of an enterprise, preparing the way for an internal attack. Mitigation: Request the 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) Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler:. F.10 Monitoring and Alert Services for Security-related Events D. Hypervisor attacks: Related risk factor: S1.E Description: Hypervisors are vital for server virtualization. They provide the link between virtual machines and the underlying physical resources required to run the machines by using hypercalls (similar to system calls, but for virtualized systems). An attacker using a virtual machine in the same cloud could fake hypercalls to inject malicious code or trigger bugs in the hypervisor. This could potentially be used to violate confidentiality or integrity of other virtual machines or crash the hypervisor (similar to a DDoS attack). Mitigation: Request 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 3. Overview of Security Risk and Threats 27 Related to Operating in the Cloud Related guidance in COBIT 5 for Information Security: Appendix B. Detailed Guidance: Processes Enabler:. B.2 Align, Plan and Organize: APO09 Manage Service Agreements Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:. G.3 Information Risk Management 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 antimalware tools. The SLA must contain detailed specifications about vulnerability classification and actions taken according to the severity level, which must align with corporate policies and procedures for similar events. Related guidance in COBIT 5 for Information Security: Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:. G.5 Information Security Operations. G.6 Information Assessment and Testing and Compliance Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler:. F.10 Monitoring and Alert Services for Security-related Events F. Application compatibility Related risk factor: D3.C Description: In a virtualized environment, direct access to resources is no longer possible (the hypervisor stays in the middle). This could generate issues with older and/or customized software that could go unnoticed until it is too late to fall back. Mitigation: Evaluate extensively the design and requirements of application candidates to move to the cloud and/or request the CSP a test period to identify possible issues. Require continuous communication and notification of major changes to ensure that compatibility testing is included in the change plans. Related guidance in COBIT 5 for Information Security: Appendix B. Detailed Guidance: Processes Enabler:. B.3 Build, Acquire and Implement: BAI02 Manage Requirements Definition Appendix E. Detailed Guidance: Information Enabler:. E.6 Information Security Requirements Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler:. F.3 Secure Development

28 28 Security Considerations for Cloud Computing G. Collateral damage Related risk factor: D1.C Description: The enterprise can be affected by issues involving other entities sharing the cloud. For example, DDoS attacks affecting another entity in the cloud can leave the enterprise without access to business applications (for SaaS models) or extra computing resources to handle peak loads (for IaaS models). Mitigation: Ask the CSP to include the enterprise in its incident management process that deals with notification of collateral events. Include contract clauses and controls to ensure that the 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 Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:. G.3 Information Risk Management Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler:. F.8 Adequate Incident Response H. SaaS access security Related risk factor: S3.K Description: Access to SaaS applications (either via browser or specific end-user clients) must be secure in order to control the exposure to attacks and protect the enterprise and his assets. Mitigation: Use hardened web browsers and/or specific end-user client applications which include appropriate security measures (anti-malware, encryption, sandboxes, etc.). Use secure virtual desktops or specific browser clients when connecting to cloud applications. Educate corporate users about the risk of running SaaS applications using insecure devices. Related guidance in COBIT 5 for Information Security: Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler:. F.6 User Access and Access Rights in Line With Business Requirements. F.10 Monitoring and Alert Services for Security-related Events Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:. G.5 Information Security Operations I. Outdated VM security Related risk factor: S1.K Description: An inactive VM could be easily overlooked and important security patches could be left unapplied. This out-of-date VM could become compromised when activated and expose other VM connected to the cloud.

29 3. Overview of Security Risk and Threats 29 Related to Operating in the Cloud Mitigation: Introduce procedures within the enterprise to verify the state of software security updates prior to the activation of any VMs. Contractually request the CSP to apply security patches on inactive VMs. Related guidance in COBIT 5 for Information Security: Appendix A. Detailed Guidance: Principles, Policies and Framework Enabler:. A.2 Information Security Policy Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler:. F.5 Adequately Secured and Configured Systems, Aligned With Security Requirements and Security Architecture Regulatory 4 A. Asset ownership Related risk factors: S2.D, S3.C Description: Any asset (data, application or process) migrated to a CSP could be legally owned by the CSP based on contract terms. Thus, the enterprise can lose sensitive data or have data disclosed because the enterprise is no longer the sole legal owner of the asset. In the event of contract termination, the enterprise could even be subject (by contract) to pay fees to retrieve its own assets. Mitigation: Include terms in the contract with the CSP that ensure that the enterprise remains the sole legal owner of any asset migrated to the CSP. Encrypt all sensitive assets being migrated to the CSP prior to the migration to prevent disclosure and ensure proper key management is in place. This can affect the performance of the system. Related guidance in COBIT 5 for Information Security: Appendix C. Detailed Guidance: Organizational Structures Enabler:. C.5 Information Custodians/Business Owners B. Asset disposal Related risk factors: S1.I, S2.E, S3.D Description: In the event of contract termination, to prevent disclosure of the 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. Related guidance in COBIT 5 for Information Security: Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:. G.3 Information Risk Management 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 30 Security Considerations for Cloud Computing C. Asset location Related risk factor: S1.D Description: Technical information assets (data, logs, etc.) are subject to the regulations of the country where they are stored or processed. In the cloud, an enterprise may, without notification, migrate information assets to countries where regulations are less restrictive or their transmission is prohibited (personal information in particular). Unauthorized entities that cannot have access to assets in one country may be able to obtain legal access in another country. Conversely, if assets are moved to countries with stricter regulations, the enterprise can be subject to legal actions and fines for noncompliance. Mitigation: Request the 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. Related guidance in COBIT 5 for Information Security: Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:. G.4 Information Security Architecture Development. G.6 Information Assessment and Testing and Compliance Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler:. F.2 Security Awareness Information Security Governance 5 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 COBIT 5, EDM01 through EDM05 processes.

31 3. Overview of Security Risk and Threats 31 Related to Operating in the Cloud Related guidance in COBIT 5 for Information Security: Appendix E. Detailed Guidance: Information Enabler. E.6 Information Security Requirements Appendix A. Detailed Guidance: Principles, Policies and Frameworks Enabler. A.2 Information Security Policy B. Visibility of the security measures put in place by the CSP: Related risk factor: S1.F Description: The cloud is similar to any infrastructure in that security measures (technology and processes) should be in place to prevent security attacks. The security measures provided by the CSP should be aligned with the requirements of the enterprise, including management of security incidents. Mitigation: Request the CSP s 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 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 provide the enterprise regular reporting on security (incident reports, intrusion detection system [IDS]/intrusion prevention system [IPS] logs, etc.). Request the CSP s security incident management process to be applied to the enterprise s assets and ensure that it is aligned with the enterprise s own security policy. Related guidance in COBIT 5 for Information Security: Appendix E. Detailed Guidance: Information Enabler. E.6 Information Security Requirements. E.8 Information Security Review Reports. E.9 Information Security Dashboard Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler:. F.10 Monitoring and Alert Services for Security-related Events C. Media management: Related risk factor: S1.I Description: Data media must be disposed in a secure way to avoid data leakage and disclosure. Data wipeout procedures must ensure data cannot be reproduced when data media is designated for recycle or disposal. Controls should be in place during transportation (encryption and physical security). This should be specified in the CSP security policy and contract SLA. Mitigation: Request the CSP s process and techniques in place for data media disposal and evaluate whether they meet the requirements of the enterprise. Include in the contract language that requires the CSP to comply with the enterprise s security policy. Related guidance in COBIT 5 for Information Security: Appendix B. Detailed Guidance: Processes Enabler. B. 3 Build, Acquire and Implement: BAI08 Manage Knowledge

32 32 Security Considerations for Cloud Computing D. Secure software SDLC: Related risk factor: S3.E Description: When using SaaS services, the enterprise must be sure that the applications will meet its security requirements. This will reduce the risk of theft, disclosure and unavailability. Mitigation: Request the CSP s details about the software SDLC policy and procedures in place and ensure that the security measures introduced into the design are compliant with the requirements of the enterprise. 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). Related guidance in COBIT 5 for Information Security: Appendix B. Detailed Guidance: Processes Enabler:. B. 3 Build, Acquire and Implement: BAI03 Manage Solutions Identification and Build Appendix E. Detailed Guidance: Information Enabler:. E.6 Information Security Requirements Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler:. F.3 Secure Development E. Common security policy for community clouds: Related risk factor: D2.C Description: Community clouds share resources among different entities that belong to the same group (or community) and thereby possess a certain level of mutual trust. This trust must be regulated by a common security policy. Otherwise, an attack on the weakest link of the group could place all the group s entities in danger. Mitigation: Ensure that a global security policy specifying minimum requirements is applied to all entities sharing a community cloud. Request that the CSP provide proof of independent security reviews or certification reports that meet the enterprise s compliance requirements (e.g., AICPA SSAE 16 SOC 2 report, SOX, PCI DSS, HIPAA, ISO certification). Related guidance in COBIT 5 for Information Security: Appendix E. Detailed Guidance: Information Enabler:. E.6 Information Security Requirements Appendix 5. Detailed Guidance: Principles, Policies and Framework Enabler:. E.2 Information Security Strategy F. Service termination issues Related risk factor: S3.G Description: Currently, there is very little available in terms of tools, procedures or other offerings to facilitate data or service portability from CSP to CSP. This can make it very difficult for the enterprise to migrate from one CSP to another or to bring services back in-house. It can also result in serious

33 3. Overview of Security Risk and Threats 33 Related to Operating in the Cloud business disruption or failure should the CSP go bankrupt, face legal action, or be the potential target for an acquisition (with the likelihood of sudden changes in CSP policies and any agreements in place). Another possibility is the run on the banks scenario, in which there is a crisis of confidence in the CSP s financial position resulting in a mass exit and withdrawal on first-come, first-served basis. If there are limits to the amount of content that can be withdrawn in a given time frame, then the enterprise might not be able to retrieve all its data in the time specified. Another possibility may occur if the enterprise decides, for any reason, to end the relationship with the CSP. The complexity of the business logic and data models could make it impossible for the enterprise to extract its data, reconstruct the business logic and rebuild the applications. Mitigation: Ensure by contract or SLA with the CSP an exit strategy that specifies the terms that should trigger the retrieval of the enterprise s assets in the time frame required by the enterprise. Implement a DRP, taking into account the possibility of complete CSP disruption. Related guidance in COBIT 5 for Information Security: Appendix B. Detailed Guidance: Processes Enabler:. B.2 Align, Plan and Organize: APO09 Manage Service Agreements Appendix B. Detailed Guidance: Processes Enabler:. B.4 Deliver, Service and Support: DSS04 Manage Continuity Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:. G.3 Information Risk Management G. Solid enterprise governance: Related risk factor: S3.I Description: Enterprises turn to CSPs in search of solutions that can be implemented easily and at low cost. This ease can be tempting, especially when the enterprise is facing urgent deadlines that require an urgent solution (e.g., the expiration of application licenses or the need of more computing capacity). This can become an issue because enterprises may contract cloud applications without proper procurement and approval oversight, thus bypassing compliance with internal policies. Mitigation: Ensure that internal governance controls are in place within the enterprise to involve the necessary governance organization (legal, compliance, finance, etc.) during the decision process of migrating to cloud services. Related guidance in COBIT 5 for Information Security: Appendix B. Detailed Guidance: Processes Enabler:. B.1 Evaluate, Direct and Monitor: EDM01 Ensure Governance Framework Setting and Maintenance.. B.5 Monitor, Evaluate and Assess: MEA02 Monitor, Evaluate and Assess the System of Internal Control

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

35 4. The Path to the Decision and Beyond The Path to the Decision and Beyond This chapter provides practical guidance on how to consider a potential decision to go to the cloud. Two decision trees are outlined to help prospective cloud users decide whether they should move assets to the cloud and, if so, which service and deployment models are best for their enterprise. In this context, the following approach can be taken: Step 1. Preparation of the internal environment Step 2. Selection of the cloud service model Step 3. Selection of the cloud deployment model Step 4. Selection of the cloud provider However, the challenge does not end after step 4. Even if the enterprise has decided to go to the cloud based on the steps above and the enterprise trusts the CSP, there are still a number of questions that must be answered. These questions have been already touched on through the mitigating actions mentioned in chapter 3. These mitigating actions can be translated into a checklist that management should use in deciding to move to the cloud. The actions can be divided into four categories: Actions to be done prior to moving to the cloud (preparatory work) Cloud provider checks and requests Contract terms to be negotiated Preventive measures to be taken An overview of the checklist appears in appendix A. In addition to this publication, practical guidance on implementing best practices relative to IT governance can be found in ISACA s publication COBIT 5 Implementation, which includes an implementation tool kit containing a variety of resources that are continually enhanced to reflect current trends. Its content includes: Self-assessment, measurement and diagnostic tools Presentations aimed at various audiences Related articles and further explanations Step 1. Preparation of the Internal Environment Besides selecting deployment and service models, an enterprise must do some preparatory work to make a migration to the cloud possible. 6 All IT dimensions should be taken into account when defining the project scope and project plan. The COBIT 5 enablers (principles, policies and frameworks; processes; organizational structures; culture, ethics and behaviour; information; services, infrastructure and applications; people, skills and competencies;) provide practical guidance when looking into the different aspects: Principles, policies, and frameworks Which security policies apply within the enterprise? Which regulatory restrictions apply to the enterprise and to any locations where a CSP might reside? 6 Commercial analysis must, of course, be done, but it is out of scope for this publication.

36 36 Security Considerations for Cloud Computing Processes How will moving to the cloud influence the enterprise s processes? Which processes depend on assets that could move to the cloud? Are these processes considered to be critical for the business? Organizational structures How will the relationship with the CSP be managed? How are roles and responsibilities defined? Culture, ethics and behaviour How will change within the enterprise be managed? How can an information culture be imposed upon the CSP? Information Which assets are considered for cloud computing? The enterprise should classify its assets into categories for an optimal selection of cloud arrangements. Generally, data can be classified as public, restricted, for internal use, secret and top-secret. A data life cycle process can also be defined. Services, infrastructure and applications Which service capabilities are expected of the CSP? How will performance be measured? How will issues be reported? People, skills and competencies Which skills and competencies are required to manage the assets of the enterprise? Does the enterprise wish to keep these in-house after a move to the cloud has been decided on? In addition to these considerations, the enterprise s decision to migrate to the cloud must take into account a consistent business case and an evaluation of the costs and benefits related to the move to the CSP. After the preparation of the internal environment, the following step is to look into the selection of a cloud service and deployment model. The flowcharts presented in steps 2 and 3 will help the enterprise to determine which cloud service model and which cloud deployment model could best suit the enterprise needs. While the questions were chosen very carefully in order to accommodate a maximum of enterprise needs, the flowcharts only serve as an example of what type of questions should be taken into consideration. Questions can be added or adapted to better serve individual enterprise needs. Step 2. Selection of the Cloud Service Model The most common technical reason not to move to the cloud is that the cost of customization outweighs the benefits of the cloud solution. The decision tree presented in figure 3 is designed to help the enterprise determine which service model best serves its business needs. The decision tree may lead to a decision to migrate to the cloud, but it may also suggest that the cloud is not the optimal solution for the enterprise and that other solutions, such as outsourcing, may be more viable options. The cloud deployment model addresses potential risk and its mitigation, while the service model is more focused on a technical solution. This explains why not all possible outcomes in the decision tree end in a cloud service model.

37 4. The Path to the Decision and Beyond 37 Figure 3 Decision Tree: Choosing a Service Model 1. Is the business process a nonstandard solution? N 7. Business driver cloud-compatible? N A cloud solution is probably not the best solution for your business needs. Y Y 2. Interdependencies with other business processes? N SaaS Y 3. Difference from standard solutions IT-based? N Y 4. Applications/hardware/OS custom? N Y 5. Hardware/OS custom? N PaaS Y 6. Hardware custom? N IaaS Y A cloud solution is probably not the best solution for your business needs.

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

39 4. The Path to the Decision and Beyond 39 Figure 4 Breakdown of Cloud Service Model Decision Tree (cont.) Answer Explanation Next Question 5. Hardware/OS custom? Yes After establishing that the difference is not within the application, it is important to establish whether the differentiation is found on the OS level or the physical hardware platform. The answer will alter the possibility for cloud adaptation. No If the differentiation can be done on application level, no further drill-down is needed. 6. Hardware custom? Yes After establishing that the differentiation is located on the physical level, a cloud solution is very unlikely. CSPs are oriented toward standardization within their domain; providing custom hardware is not one of their typical offerings. While a CSP can undoubtedly provide custom hardware platforms, the high cost and the CSP s relative lack of experience in the custom platform eliminate the cloud as a viable solution. No If the differentiation can be done on the OS level, no further drill-down is needed. 7. Business driver cloud-compatible? Yes Viable business drivers for the cloud decision include: Reduce medium- and/or long-term total cost of ownership (TCO). Improve cash flow by decreasing investments. Shift from capital expenditures (CAPEX) to operating expenditures (OPEX). Improve Quality of Service (QoS) and/ or SLAs. Gain access to functionality and/or domain expertise. No While there may be no technical constraints to adopting the cloud as a solution, it is possible that the business drivers are, in fact, not cloud-compatible. Adopting a cloud solution requires a mid- to long-term vision. Therefore, the cloud cannot be used as a solution to cut costs immediately. Question 6: Hardware custom? Solution: PaaS Solution: A cloud solution is probably not the best solution for your business needs. Solution: IaaS Solution: SaaS Solution: A cloud solution is probably not the best solution for your business needs.

40 40 Security Considerations for Cloud Computing Step 3. Selection of the Cloud Deployment Model While there are four common cloud deployment models, the decision tree presented in this section focuses on deciding between a private or public cloud. Hybrid cloud or community cloud are deployment models that arise for consideration when evaluating several cloud solutions that are present in one enterprise or collection of enterprises. A hybrid cloud is most commonly used when there is a data classification system in place and the decision is made to use different deployment models for different data classifications (e.g., a private cloud model for HR data and a public cloud for storage of publications). The same goes for a community cloud. A community cloud is created when several allied companies or enterprises decide to move to the cloud together. Either the community as a whole decides to create a common infrastructure platform for all to use (common reasons being the ease of sharing information and cost reduction), or one member or sponsor provides the necessary infrastructure that is used by the community. The decision tree (shown in figure 5) also offers the options of not going to the cloud at all or considering alternatives to the cloud. This decision (among others) is made when the data or the process is too critical or contains so much sensitive or business-critical data that the risk of going to the cloud outweighs the benefits. NOTE: When the situation addressed in the question is not occurring or when it can be adequately covered by technical means, policies or contracts, the question should be answered affirmatively.

41 4. The Path to the Decision and Beyond 41 Figure 5 Decision Tree: Choosing a Deployment Model Start 1. Sensitive data? Y Full cloud may not be the best solution. Hybrid cloud may be considered. 14. SLA? N N Y 15. Cost Y efficient? 16. Adequate infrastructure? N N Y N 17. Predictable? Y Cloud may not be the best solution. N N Y 22. SLA? 23. Cost efficient? Y 2. Critical data? Y 21. Can upgrade? Y 18. Legal/ compliance Y impediments? N N N N Private cloud 3. More than data? Y 4. Business process critical? Y 12. In-house DRP/BCM? Y 19. Data ownership? Y N N N 5. Adequate infrastructure? N N 13. Can upgrade? Cloud may not be the best solution. 20. Jurisdiction? Y Y Y N N N 6. Predictable? N 10. SLA? Y 11. Cost efficient? Y Y Y Y Y 7. Legal/compliance impediments? N 8. Data N ownership? 9. Jurisdiction? N Public cloud

42 42 Security Considerations for Cloud Computing Breakdown of Cloud Deployment Decision Tree Figure 6 provides a breakdown of the cloud deployment decision tree. Figure 6 Breakdown of Cloud Deployment Decision Tree Answer Explanation Next Question 1. Sensitive data? Yes When considering a move to a cloud infrastructure it is very important to be aware what data are to be released to the cloud. Question 14: SLA? It is impossible to envision all potential risk and threats; however, data of a sensitive nature can be placed in the cloud when the necessary controls to protect them are in place and work effectively. No If data are not sensitive or if no data upload to the cloud is required, the first steps toward the cloud are taken. 2. Critical data? Yes Critical data can be: Blueprints Formulas Trade secrets Any information absolutely necessary for the enterprise to operate Critical data can be placed in the cloud when the necessary controls to protect them are in place and working effectively. It is important to note, however, that some of these controls can be expensive and complex, which may increase the cost of moving to the cloud. No Noncritical data can be easily placed in the cloud. 3. More than data? Yes In almost all cases the decision to move to the cloud is not restricted to solely the data. Data in the cloud are often needed to run applications or as part of business processes. No If the decision to move to the cloud is limited to data only, the next step is to evaluate the enterprise s readiness for this move. Question 2: Critical data? Question 14: SLA? Question 3: More than data? Question 4: Business process critical? Question 5: Adequate infrastructure?

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

44 44 Security Considerations for Cloud Computing Figure 6 Breakdown of Cloud Deployment Decision Tree (cont.) Answer Explanation Next Question 7. Legal/compliance impediments? Yes There may be legal or compliance reasons why data or certain business functions cannot be moved to the cloud. It is important for the CSP to implement the necessary controls to ensure the enterprise s legal and compliance continuity. The CSP must be able to provide proof of compliance as reported by a neutral audit or control body. Question 10: SLA? Identification of legal or compliance limitations must be addressed during the contract negotiations to stipulate the enterprise s expectations and how they will be satisfied. No If the enterprise does not have any legal or compliance impediments, the next steps to move to the cloud can be taken. 8. Data ownership? Yes The contract with the CSP should clearly stipulate that the enterprise is, and will remain, the data owner. It is equally important that this ownership be maintained throughout the entire data life cycle. Therefore, the contract should also outline the requirements to dispose of data in an adequate manner when the enterprise deems necessary. Question 8: Data ownership? Question 10: SLA? No If data ownership cannot be properly established, the enterprise may choose to move only nonsensitive and noncritical data. If the enterprise can clearly define data ownership during contract negotiations, the next steps to move to the cloud can be taken. Question 9: Jurisdiction?

45 4. The Path to the Decision and Beyond 45 Figure 6 Breakdown of Cloud Deployment Decision Tree (cont.) Answer Explanation Next Question 9. Jurisdiction? Yes Even though data ownership resides with the enterprise, local and international laws often forbid the transfer of certain data to countries that have conflicting laws or regulations. Therefore, it is important for the enterprise to know the location of the CSP s data storage facilities and data processing centers to prevent legal infractions. Question 10: SLA? No 10. SLA? Yes It is advisable for the enterprise to include in the contract with the CSP the necessary clauses requiring the CSP to limit service locations to those approved by the enterprise. If the enterprise does not have jurisdiction limitations, the cloud may be a proper solution. The enterprise must determine in advance the terms that will be included in the SLA keeping in mind that strict or complex SLAs could result in higher maintenance cost. Solution: Public cloud Question 11: Cost efficient? Some of the terms that should be negotiated and documented in the SLA include: Availability Response time for additional computing resources requests Response time for incidents Backup policies Data retention and disposal policies and procedures Patch management Security controls Recovery and continuity objectives Controls to satisfy legal and compliance requirements No If an adequate SLA cannot be agreed upon, moving to the cloud could pose an unacceptable level of risk. Solution: Cloud computing may not be the best solution for your current business needs. If the cost of the SLA is greater than the business driver, the cloud solution may not be the best solution.

46 46 Security Considerations for Cloud Computing Figure 6 Breakdown of Cloud Deployment Decision Tree (cont.) Answer Explanation Next Question 11. Cost efficient? Yes Two of the principal goals of moving to the cloud are becoming more cost effective and being able to react more quickly and inexpensively to changing situations. No Unless the business driver is greater than the cost, an expensive solution may not be the right option. 12. In-house DRP/BCM? Yes This question may already be addressed in the SLA, but the enterprise must still be ready to consider additional DR and BC plans. A disaster occurring within the CSP is likely to cause an impact on the enterprise s operations. For example, routes will change and entry points will be altered, causing delays in operations. If a disaster takes place within the enterprise, maintaining or reestablishing connectivity with the CSP should be a critical part of the recovery efforts. Solution: Public cloud Solution: Cloud computing may not be the best solution for your current business needs. Question 16: Adequate infrastructure? Enterprises whose data reside only on the cloud should create backups to their own premises to retain recovery and continuity capabilities even if the CSP is completely offline. No Relying solely on the DRP/BCM capabilities of the CSP can expose the enterprise to extended business outages; however, if the cost of having an in-house DRP is greater than the business driver, the enterprise may address this question in a more strict SLA. 13. Can upgrade? Yes If it is determined that the current enterprise infrastructure is not ready to integrate with the cloud, the next step is to determine whether the business needs are greater than the cost to upgrade (feasibility analysis). No If the cost to upgrade the current infrastructure is greater than the business needs, the cloud may not be a solution yet. Question 14: SLA? Question 6: Predictable? Solution: Cloud computing may not be the best solution for your current business needs.

47 4. The Path to the Decision and Beyond 47 Figure 6 Breakdown of Cloud Deployment Decision Tree (cont.) Answer Explanation Next Question 14. SLA? Yes The enterprise must determine in advance the terms that will be included in the SLA keeping in mind the fact that strict or complex SLAs could result in higher maintenance cost. Question 15: Cost efficient? No Some of the terms that should be negotiated and documented in the SLA include: Availability Response time for additional computing resources requests Response time for incidents Backup policies Data retention and disposal policies and procedures Patch management Security controls Recovery and continuity objectives Controls to satisfy legal and compliance requirements If an adequate SLA cannot be agreed on, moving to the cloud can pose an unacceptable level of risk. Solution: Full cloud may not be the best solution. Hybrid cloud may be considered. If the cost of the SLA is greater than the business driver, the cloud solution may not be the best solution; however, a hybrid cloud solution can still provide some of the benefits of cloud computing sensitive or critical components can remain within the enterprise s premises or a private cloud, while nonsensitive or noncritical ones can be moved to a public cloud. 15. Cost efficient? Yes Two of the principal goals of moving to the cloud are becoming more cost effective and being able to react more quickly and inexpensively to changing situations. No Unless the business driver is greater than the cost, an expensive solution may not be the right option; however, a hybrid cloud solution can still provide some of the benefits of cloud computing sensitive or critical components can remain within the enterprise s premises or a private cloud, while nonsensitive or noncritical ones can be moved to a public cloud. Question 16: Adequate infrastructure? Solution: Full cloud may not be the best solution. Hybrid cloud may be considered.

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

49 4. The Path to the Decision and Beyond 49 Figure 6 Breakdown of Cloud Deployment Decision Tree (cont.) Answer Explanation Next Question 18. Legal/compliance impediments? Yes There may be legal or compliance reasons why data or certain business functions cannot be moved to the cloud. It is important for the CSP to implement the necessary controls to ensure the enterprise s legal and compliance continuity. The CSP must be able to provide proof of compliance as reported by a neutral audit or control body. Question 22: SLA? Identification of legal or compliance limitations must be addressed during the contract negotiations to stipulate the enterprise s expectations and how they will be satisfied. No If the enterprise does not have any legal or compliance impediments, the next steps to move to the cloud can be taken. 19. Data ownership? Yes The contract with the CSP should clearly stipulate that the enterprise is, and will remain, the data owner. It is equally important that this ownership be maintained throughout the entire data life cycle. Therefore, the contract should also outline the requirements to dispose of data in an adequate manner when the enterprise deems necessary. Question 19: Data ownership? Question 22: SLA? No If data ownership cannot be properly established, the enterprise may choose to move only nonsensitive and noncritical data. If the enterprise can clearly define data ownership during contract negotiations, the next steps to move to the cloud can be taken. Question 20: Jurisdiction?

50 50 Security Considerations for Cloud Computing Figure 6 Breakdown of Cloud Deployment Decision Tree (cont.) Answer Explanation Next Question 20. Jurisdiction? Yes Even though data ownership resides with the enterprise, local and international laws often forbid the transfer of certain data to countries that have conflicting laws or regulations. Therefore, it is important for the enterprise to know the location of the CSP s data storage facilities and data processing centers to prevent legal infractions. Question 22: SLA? It is advisable for the enterprise to include in the contract with the CSP the necessary clauses requiring the CSP to limit service locations to those approved by the enterprise. No If the enterprise does not have jurisdiction limitations, the cloud may be a proper solution. 21. Can upgrade? Yes If it is determined that the current enterprise infrastructure is not ready to integrate with the cloud, the next step is to determine whether the business needs are greater than the cost to upgrade (feasibility analysis). No If the cost to upgrade the current infrastructure is greater than the business needs, the cloud may not be a solution yet. Solution: Private cloud Question 17: Predictable? Solution: Cloud computing may not be the best solution for your current business needs.

51 4. The Path to the Decision and Beyond 51 Figure 6 Breakdown of Cloud Deployment Decision Tree (cont.) Answer Explanation Next Question 22. SLA? Yes The enterprise must determine in advance the terms that will be included in the SLA keeping in mind that strict or complex SLAs could result in higher maintenance cost. Question 23: Cost efficient? No Some of the terms that should be negotiated and documented in the SLA include: Availability Response time for additional computing resources requests Response time for incidents Backup policies Data retention and disposal policies and procedures Patch management Security controls Recovery and continuity objectives Controls to satisfy legal and compliance requirements If an adequate SLA cannot be agreed on, moving to the cloud can pose an unacceptable level of risk. Solution: Cloud computing may not be the best solution for your current business needs. If the cost of the SLA is greater than the business driver, the cloud solution may not be the best solution. 23. Cost efficient? Yes Two of the principal goals of moving to the cloud are becoming more cost effective and being able to react more quickly and inexpensively to changing situations. No Unless the business driver is greater than the cost, an expensive solution may not be the right option. Solution: Private cloud Solution: Cloud computing may not be the best solution for your current business needs. Step 4. Selection of the Cloud Service Provider Once the best-suited cloud flavor is established, it is key to find the best-suited cloud service provider. Matching the correct CSP to the enterprise needs could prove challenging. The key is to find the CSP that bests serves the business needs while minimizing potential risk. While there are many suitable smaller CSPs, it is important to choose an established CSP with the proper references. Established CSPs will potentially be more experienced with running cloud infrastructures, adapting to change and generally faster in responding to an incident or threat, thus being able to maintain stability

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

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

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

55 Appendix B. Overview of Different Risk Factors 55 per Service and Deployment Model Appendix B. Overview of Different Risk Factors per Service and Deployment Model Figure 8 provides an overview of cloud service and deployment model risk. Code Risk Factor IaaS S1.A Scalability/ elasticity S1.B Disaster recovery and backup S1.C Patch management Figure 8 Risk Factors of Cloud Service and Deployment Models Risk Event Unavailability Loss Theft Disclosure Type Description X Decreasing 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). X X Decreasing CSPs should already have in place, as common practice, disaster recovery and backup procedures. However, RPO, RTO, and backup testing frequency and procedures provided by the CSP should be consistent with the enterprise security policy. X X X Decreasing Cloud infrastructures are based on hypervisors and are controlled through a central hypervisor manager or client. The hypervisor manager allows the necessary patches to be applied across the infrastructure in a short time, reducing the time available for a new vulnerability to be exploited.

56 56 Security Considerations for Cloud Computing Code Risk Factor IaaS (cont.) S1.D Legal transborder requirements S1.E Multitenancy and isolation failure S1.F Lack of visibility surrounding technical security measures in place Figure 8 Risk Factors of Cloud Service and Deployment Models (cont.) Risk Event Unavailability Loss Theft Disclosure Type Description X Increasing CSPs are often transborder, and different countries have different legal requirements, especially concerning personal private information. The enterprise might be committing a violation of regulations in other countries when storing or transmitting data within the 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. X X Increasing One of the primary benefits of the cloud is the ability to perform dynamic allocation of physical resources when required. The most common approach is a multitenant environment (public cloud), where different entities share a pool of resources, including storage, hardware and network components. All resources allocated to a particular tenant should be isolated and protected to avoid disclosure of information to other tenants. For example, when allocated storage is no longer needed by a client, it can be freely reallocated to another enterprise. In that case, sensitive data could be disclosed if the storage has not been scrubbed thoroughly (e.g., using forensic software). X X X X Increasing For any infrastructure, IDS/IPS and SIEM capabilities must be in place. It is the responsibility of the CSP to provide these capabilities to its customers. To ensure that there are no security gaps, the security policy and governance of the CSP should match those of the enterprise.

57 Appendix B. Overview of Different Risk Factors 57 per Service and Deployment Model Code Risk Factor IaaS (cont.) S1.G Absence of DRP and backup Figure 8 Risk Factors of Cloud Service and Deployment Models (cont.) Risk Event Unavailability Loss Theft Disclosure Type Description X X Increasing 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 X X Increasing In an IaaS model, physical compute resources are shared with other entities in the cloud. If physical access to the CSP s infrastructure is granted to one entity, that entity could potentially access information assets of other entities. The CSP is responsible for applying physical security measures to protect assets against destruction or unauthorized access. S1.I Data disposal X Increasing Proper disposal of data is imperative to prevent unauthorized disclosure. If appropriate measures are not taken by the CSP, information assets could be sent (without approval) to countries where the data can be legally disclosed due to different regulations concerning sensitive data. Disks could be replaced, recycled or upgraded without proper cleaning so that the information still remains within storage and can later be retrieved. When a contract expires, CSPs should ensure the safe disposal or destruction of any previous backups. S1.J Offshoring infrastructure X X X X Increasing The move to offshoring of key infrastructure expands the attack surface area considerably. In practice, the information assets in the cloud still need to integrate back to other noncloud-based assets within the boundaries of the organization. These communications (normally done through border gateway devices) could be insecure, exposing both the cloud and internal infrastructures.

58 58 Security Considerations for Cloud Computing Code Risk Factor IaaS (cont.) S1.K VM security maintenance S1.L Cloud provider authenticity PaaS S2.A Short development time S2.B Application mapping S2.C SOA-related vulnerabilities S2.D Application disposal Figure 8 Risk Factors of Cloud Service and Deployment Models (cont.) Risk Event Unavailability Loss Theft Disclosure Type Description X X X X Increasing 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. X X X X Increasing Although communications between the enterprise and the cloud provider can be secured with technical means (encryption, VPN, mutual authentication, etc.) it is a consumer s responsibility to check the identity of the cloud provider to ensure that is not an imposter. X X X X Decreasing Using the SOA library provided by the CSP, applications can be developed and tested within a reduced timeframe because SOA provides a common framework for application development. X X Increasing If current applications are not perfectly aligned with the capabilities provided by the CSP, additional undesirable features (and vulnerabilities) could be introduced. X X X X Increasing 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. X X Increasing When applications are developed in a PaaS environment, originals and backups should always be available. In the event of contract termination, the details of the application could be disclosed and used to create more selective attacks on applications.

59 Appendix B. Overview of Different Risk Factors 59 per Service and Deployment Model Code Risk Factor SaaS S3.A Improved security S3.B Application patch management Figure 8 Risk Factors of Cloud Service and Deployment Models (cont.) Risk Event Unavailability Loss Theft Disclosure Type Description X X Decreasing 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). X X Decreasing 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 X X X X Increasing The CSP provides the applications and the customer provides the data. If data ownership is not clearly defined, the CSP could refuse access to data when required or even demand fees to return the data once the service contracts are terminated. S3.D Data disposal X X Increasing In the event of a contract termination, the data fed into the CSP s application must be erased immediately using forensic tools to avoid disclosures and confidentiality breaches. S3.E Lack of visibility into software SDLC X X X X Increasing 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.

60 60 Security Considerations for Cloud Computing Code Risk Factor SaaS (cont.) Figure 8 Risk Factors of Cloud Service and Deployment Models (cont.) Risk Event Unavailability Loss Theft Disclosure Type Description S3.F IAM X X X Increasing To maximize their revenues, CSPs offer their services and applications to several customers concurrently. Those customers share servers, applications and, eventually, data. If data access is not properly managed by the CSP application, one customer could obtain access to another customer s data. S3.G Exit strategy X X Increasing Currently, there is very little available in terms of tools, procedures or other offerings to facilitate data or service portability from CSP to CSP. This can make it very difficult for the enterprise to migrate from one CSP to another or to bring services back in-house. It can also result in serious business disruption or failure should the CSP go bankrupt, face legal action, or be the potential target for an acquisition (with the likelihood of sudden changes in CSP policies and any agreements in place). If the customer-csp relationship goes sour and the enterprise wants to bring the data back in-house, the question of how to securely render the data becomes critical because the in-house applications may have been decommissioned or sunsetted and there is no application available to render the data. S3.H Broad exposure of applications X X X X Increasing In a cloud environment, the applications offered by the CSP have broader exposure, which increases the attack space; additionally, it is quite common that those applications still need to integrate back to other noncloud applications within the boundaries of the enterprise. Standard network firewalls and access controls are sometimes insufficient to protect the applications and their external interactions. Additional security measures are required.

61 Appendix B. Overview of Different Risk Factors 61 per Service and Deployment Model Code Risk Factor SaaS (cont.) S3.I Ease to contract SaaS S3.J Lack of control of the release management process S3.K Browser vulnerabilities Public Cloud D1.A Public reputation D1.B Full sharing of the cloud (data pooling) Figure 8 Risk Factors of Cloud Service and Deployment Models (cont.) Risk Event Unavailability Loss Theft Disclosure Type Description X X X X Increasing Business organizations may contract cloud applications without proper procurement and approval oversight, thus bypassing compliance with internal enterprise policies. X X Increasing As described before, CSPs are able to introduce patches in their applications quickly. These deployments are often done without the approval (or even the knowledge) of the application users for merely practical reasons: If an application is used by hundreds of different enterprises, it would take an extremely long time for a CSP to look for the formal approval of every customer. In this case, the enterprise could have no control (or no view) of the release management process and could be subject to unexpected side effects. X X Increasing 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. X X X X Decreasing Providers of public cloud services are aware that they are generally perceived as more risky. It is critical for them to ensure a good reputation because a secure provider or customers will simply move elsewhere. X X X X Increasing The cloud infrastructure is shared by multiple tenants of the cloud service provider. These tenants have no relation to the enterprise or other tenants in the same space, therefore no common interests and concern for security.

62 62 Security Considerations for Cloud Computing Code Risk Factor Public Cloud (cont.) D1.C Collateral damage Community Cloud D2.A Same group of entities D2.B Dedicated access for the community D2.C Sharing of the cloud Private Cloud D3.A Can be built on-premise Figure 8 Risk Factors of Cloud Service and Deployment Models (cont.) Risk Event Unavailability Loss Theft Disclosure Type Description X X X X Increasing 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. X X X X Decreasing 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.) X X Decreasing Dedicated access can be configured for authorized community users only. X X X Increasing 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. X X X X Decreasing 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.

63 Appendix B. Overview of Different Risk Factors 63 per Service and Deployment Model Code Risk Factor Private Cloud (cont.) Figure 8 Risk Factors of Cloud Service and Deployment Models (cont.) Risk Event Unavailability Loss Theft Disclosure Type Description D3.B Performance X X Decreasing Affects on-site private clouds. Because the private cloud is deployed inside the firewall on the enterprise s intranet, transfer rates are dramatically increased (fewer nodes to cross). Storage capacity can also be higher; private clouds usually start with a few terabytes and can be increased by adding disks. D3.C Application compatibility D3.D Investments required (can be triggered by cost) X X Increasing 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. (can be triggered by cost) (can be triggered by cost) (can be triggered by cost) Increasing Making a business case for shared infrastructure and the necessary training or recruitment to acquire associated skills is notoriously hard at the best of times. Although the word cloud has a high profile, messages from vendors and service providers are often confusing and contradictory, making seeking support from senior stakeholders even more of an issue. If the head of finance thinks cloud is all about getting rid of infrastructure, it can be difficult to explain that investments are needed in new equipment, software, and tools. The enterprise must conduct a business case and cost-benefit analysis to determine whether the cloud is a viable solution to meet specific business requirements, and justify any expenses.

64 64 Security Considerations for Cloud Computing Code Risk Factor Private Cloud (cont.) D3.E Cloud IT skills required Hybrid Cloud D4.A Cloud interdependency Figure 8 Risk Factors of Cloud Service and Deployment Models (cont.) Risk Event Unavailability Loss Theft Disclosure Type Description (can be triggered by cost) (can be triggered by cost) (can be triggered by cost) (can be triggered by cost) Increasing Affects on-site private clouds. Building a private cloud within the enterprise infrastructure seems the best option in terms of security. However, the maintenance of cloud infrastructures requires specific cloud IT skills in addition to the traditional IT skills, thus increasing the required initial investments. X X X X Increasing 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.

65 Appendix C. Mapping Threats and Mitigating Actions 65 to COBIT 5 for Information Security Appendix C. Mapping Threats and Mitigating Actions to COBIT 5 for Information Security Figure 9 maps cloud threats and mitigating actions to COBIT 5 for Information Security. Threat Description Technical Threats A. Vulnerable access management (infrastructure and application, public cloud) Figure 9 Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security 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) Risk Factors Mitigation S1.D S3.F D1.B D2.C 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 to review and approve. 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). Mapping to 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

66 66 Security Considerations for Cloud Computing Threat Description Technical Threats (cont.) A. Vulnerable access management (infrastructure and application, public cloud) (cont.) B. Data visible to other tenants when resources are allocated dynamically Figure 9 Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.) 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. Risk Factors Mitigation Use corporate IAM systems instead of CSP IAM systems. The IAM remains the responsibility of the enterprise, so no access to assets can be granted without the knowledge of the enterprise. It requires the approval of the CSP and the establishment of a secure channel between the CSP infrastructure and the corporate IAM system. S1.E 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 so global performance could be affected. Request the CSP s technical specifications and controls to ensure that the data are properly wiped when requested. Use a private cloud deployment model (no multitenancy). Mapping to COBIT 5 for Information Security Appendix G. Detailed Guidance: People, Skills and Competencies Enabler G.3 Information Risk Management G.6 Information Assessment and Testing and Compliance Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler F.5 Adequately Secured and Configured Systems, in Line With Security Requirements and Security Architecture F.9 Security Testing

67 Appendix C. Mapping Threats and Mitigating Actions 67 to COBIT 5 for Information Security Threat Description Technical Threats (cont.) C. Multitenancy visibility D. Hypervisor attacks Figure 9 Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.) Due to the nature of multitenancy, some assets (e.g., routing tables, MAC addresses, internal IP addresses, LAN traffic) could be visible to other entities in the same cloud. Malicious entities in the cloud could take advantage of the information, e.g., by utilizing shared routing tables to map the internal network topology of an enterprise, preparing the way for an internal attack. Hypervisors are vital for cloud 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 VM in the same cloud could fake hypercalls to inject malicious code or trigger bugs in the hypervisor. This could potentially be used to violate confidentiality or integrity of other VMs or crash the hypervisor (similar to a DDoS attack). Risk Factors Mitigation S1.E D1.B D2.C Request the CSP s technical details for CISO approval and require additional controls to ensure data privacy. A contractual agreement is necessary to officially clarify who is allowed to access the 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). S1.E Request the 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. Use a private cloud deployment model (no multitenancy). Mapping to COBIT 5 for Information Security Appendix E. Detailed Guidance: Information Enabler E.8 Information Security Review Reports Appendix C. Detailed Guidance: Organizational Structures Enabler C.1 Chief Information Security Officer (CISO) Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler F.10 Monitoring and Alert Services for Security-related Events Appendix B. Detailed Guidance: Processes Enabler B.2 Align, Plan and Organize (APO). APO09 Manage Service Agreements. Appendix G. Detailed Guidance: People, Skills and Competencies Enabler G.3 Information Risk Management Appendix A. Detailed Guidance: Principles, Policies and Framework Enabler A.2 Information Security Policy

68 68 Security Considerations for Cloud Computing Threat Description Technical Threats (cont.) E. Application attacks F. Application compatibility Figure 9 Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.) 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. 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. Risk Factors Mitigation S3.H 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. D3.C Evaluate extensively the design and requirements of application candidates to move to the cloud and/or request of the CSP a test period to identify possible issues. Require continuous communication and notification of major changes to ensure that compatibility testing is included in the change plans. Mapping to COBIT 5 for Information Security Appendix G. Detailed Guidance: People, Skills and Competencies Enabler G.5 Information Security Operations G.6 Information Assessment and Testing and Compliance Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler F.10 Monitoring and Alert Services for Security-related Events Appendix B. Detailed Guidance: Processes Enabler B.3 Build, Acquire and Implement (BAI). BAI02 Manage Requirements Definition. Appendix E. Detailed Guidance: Information Enabler E.6 Information Security Requirements Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler F.3 Secure Development

69 Appendix C. Mapping Threats and Mitigating Actions 69 to COBIT 5 for Information Security Threat Description Technical Threats (cont.) G. Collateral damage H. SaaS access security Figure 9 Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.) The enterprise can be affected by issues involving other entities sharing the cloud. For example, DDoS attacks affecting another entity in the cloud can leave the enterprise without access to business applications (for SaaS models) or extra computing resources to handle peak loads (for IaaS models). Access to SaaS applications (either via browser or specific end-user clients) must be secure in order to control the exposure to attacks and protect the enterprise and assets. Risk Factors Mitigation D1.C 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). S3.K 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. Mapping to COBIT 5 for Information Security Appendix E. Detailed Guidance: Information Enabler E.6 Information Security Requirements Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler F.8 Adequate Incident Response Appendix G. Detailed Guidance: People, Skills and Competencies Enabler G.3 Information Risk Management Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler F.6 User Access and Access Rights in Line With Business Requirements F.10 Monitoring and Alert Services for Security-related Events Appendix G. Detailed Guidance: People, Skills and Competencies Enabler G.5 Information Security Operations

70 70 Security Considerations for Cloud Computing Threat Description Technical Threats (cont.) I. Outdated VM security Regulatory Threats Figure 9 Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.) 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. A. Asset ownership Any asset (data, application or process) migrated to a CSP could be legally owned by the CSP based on contract terms. Thus, the enterprise can lose sensitive data or have them disclosed because the enterprise is no longer the sole legal owner of the asset. In the event of contract termination, the enterprise could even be subject (by contract) to pay fees to retrieve its own assets. B. Asset disposal In the event of contract termination, to prevent disclosure of the enterprise s assets, those assets should be removed from the cloud using forensic tools (or other tools that ensure a complete wipeout). Risk Factors Mitigation S1.K Introduce procedures within the enterprise to verify the state of software security updates prior to the activation of any VMs. Empower the CSP to apply security patches on inactive VMs. S2.D S3.C S1.I S2.E S3.D Include terms in the contract with the CSP to ensure that the enterprise remains the sole legal owner of any asset migrated to the CSP. Encrypt all sensitive assets being migrated to the CSP prior to the migration to prevent disclosure and ensure proper key management is in place. This could affect the performance of the system. Request CSP s technical specifications and controls that ensure that data are properly wiped and backup media is destroyed when requested. Include terms in the contract that require, upon contract expiration or any event ending the contract, a mandatory data wipe carried out under the enterprise s review. Mapping to COBIT 5 for Information Security Appendix A. Detailed Guidance: Principles, Policies and Framework Enabler A.2 Information Security Policy Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler F.5 Adequately Secured and Configured Systems, Aligned With Security Requirements and Security Architecture Appendix C. Detailed Guidance: Organizational Structures Enabler C.5 Information Custodians/Business Owners Appendix G. Detailed Guidance: People, Skills and Competencies Enabler: G.3 Information Risk Management

71 Appendix C. Mapping Threats and Mitigating Actions 71 to COBIT 5 for Information Security Threat Description Regulatory Threats (cont.) Figure 9 Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.) C. Asset location Technical information assets (data, logs, etc.) are subject to the regulations of the country where they are stored. In the cloud, an enterprise may, without notification, migrate information assets to countries where regulations are less restrictive or their transmission is prohibited (personal information in particular). Unauthorized entities that cannot have access to assets in one country may be able to obtain legal access in another country. Conversely, if assets are moved to countries with stricter regulations, the enterprise can be subject to legal actions and fines for noncompliance. Risk Factors Mitigation S1.D 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. Mapping to COBIT 5 for Information Security Appendix G. Detailed Guidance: People, Skills and Competencies Enabler G.4 Information Security Architecture Development G.6 Information Assessment and Testing and Compliance Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler F.2 Security Awareness

72 72 Security Considerations for Cloud Computing Threat Description Information Security Governance Threats A. Physical security on all premises where data/applications are stored Figure 9 Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.) 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. Risk Factors Mitigation S1.H 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 (e.g., AICPA SSAE 16 SOC 2 report or ISO certification). Include in the contract language that requires the CSP to be aligned with the enterprise s security policy and to implement necessary controls to ensure it. Request the CSP s DRP and ensure that they contain the necessary countermeasures to protect physical assets during and after a disaster. Mapping to COBIT 5 for Information Security Appendix E. Detailed Guidance: Information Enabler E.6 Information Security Requirements Appendix A. Detailed Guidance: Principles, Policies and Frameworks Enabler A.2 Information Security Policy

73 Appendix C. Mapping Threats and Mitigating Actions 73 to COBIT 5 for Information Security Threat Description Information Security Governance Threats (cont.) B. Visibility of the security measures put in place by the CSP C. Media management Figure 9 Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.) The cloud is similar to any infrastructure in that security measures (technology and processes) should be in place to prevent security attacks. The security measures provided by the CSP should be aligned with the requirements of the enterprise, including management of security incidents. Data media must be disposed in a secure way to avoid data leakage and disclosure. Data wipeout procedures must ensure that data cannot be reproduced when data media support is designated for recycle or disposal. Controls should be in place during transportation (encryption and physical security). This should be specified in the CSP security policy. Risk Factors Mitigation S1.F Request the CSP s detailed schemes of the technical security measures in place and determine whether they meet the requirements of the enterprise. Request that the CSP provide proof of independent security reviews or certification reports (e.g., AICPA SSAE 16 SOC 2 report or ISO certification). Include in the contract language that requires the CSP to provide the enterprise with regular reporting on security (incident reports, IDS/IPS logs, etc.). Request the CSP s security incident management process be applied to the enterprise s assets and ensure that it is aligned with the enterprise s own security policy. S1.I Request the CSP s process and techniques in place for data media disposal and evaluate whether they meet the requirements of the enterprise. Include in the contract language that requires the CSP to comply with the enterprise s security policy Mapping to COBIT 5 for Information Security Appendix E. Detailed Guidance: Information Enabler E.6 Information Security Requirements E.8 Information Security Review Reports E.9 Information Security Dashboard Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler F.10 Monitoring and Alert Services for Security-related Events Appendix B. Detailed Guidance: Processes Enabler B.3 Build, Acquire and Implement (BAI). BAI08 Manage Knowledge.

74 74 Security Considerations for Cloud Computing Threat Description Information Security Governance Threats (cont.) D. Secure software SDLC E. Common security policy for community clouds Figure 9 Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.) When using SaaS services, the enterprise must be sure that the applications will meet its security requirements. This will reduce the risk of disclosure. Community clouds share resources among different entities that belong to the same group (or community) and thereby possess a certain level of mutual trust. This trust must be regulated by a common security policy. Otherwise, an attack on the weakest link of the group could place all the group s entities in danger. Risk Factors Mitigation S3.E Request the CSP s details about the software SDLC in place and ensure that the security measures introduced into the design are compliant with the requirements of the enterprise. Request the CSP to provide proof of independent security reviews or certification reports (e.g., AICPA SSAE 16 SOC 2 report or ISO certification). D2.C Ensure that a global security policy specifying minimum requirements is applied to all entities sharing a community cloud. Request that the CSP provide proof of independent security reviews or certification reports (e.g., AICPA SSAE 16 SOC 2 report or ISO certification). Mapping to COBIT 5 for Information Security Appendix B. Detailed Guidance: Processes Enabler B.3 Build, Acquire and Implement (BAI). BAI03 Manage Solutions Identification and Build. Appendix E. Detailed Guidance: Information Enabler E.6 Information Security Requirements Appendix F. Detailed Guidance: Services, Infrastructure and Applications Enabler F.3 Secure Development Appendix E. Detailed Guidance: Information Enabler: E.6 Information Security Requirements Appendix A. Detailed Guidance: Principles, Policies and Framework Enabler E.2 Information Security Strategy

75 Appendix C. Mapping Threats and Mitigating Actions 75 to COBIT 5 for Information Security Threat Description Information Security Governance Threats (cont.) F. Service termination issues Figure 9 Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.) Currently, there is very little available in terms of tools, procedures or other offerings to facilitate data or service portability from CSP to CSP. This can make it very difficult for the enterprise to migrate from one CSP to another or to bring services back in-house. It can also result in serious business disruption or failure should the CSP go bankrupt, face legal action, or be the potential target for an acquisition (with the likelihood of sudden changes in CSP policies and any agreements in place). Another possibility is the run on the banks scenario, in which there is a crisis of confidence in the CSP s financial position, resulting in a mass exit and withdrawal on first-come, first-served basis. If there are limits to the amount of content that can be withdrawn in a given timeframe, then the enterprise might not be able to retrieve all its data in the time specified. Another possibility may occur if the enterprise decides, for any reason, to end the relationship with the CSP. The complexity of the business logic and data models could make it literally impossible for the enterprise to extract its data, reconstruct the business logic and rebuild the applications. Risk Factors Mitigation S3.G Ensure by contract or SLA with the CSP an exit strategy that specifies the terms that should trigger the retrieval of the enterprise s assets in the timeframe required by the enterprise. Implement a DRP, taking into account the possibility of complete disruption of the CSP. Mapping to COBIT 5 for Information Security Appendix B. Detailed Guidance: Processes Enabler B.2 Align, Plan and Organize (APO). APO09 Manage Service Agreements. Appendix B. Detailed Guidance: Processes Enabler B.4 Deliver, Service and Support. DSS04 Manage Continuity. Appendix G. Detailed Guidance: People, Skills and Competencies Enabler G.3 Information Risk Management

76 76 Security Considerations for Cloud Computing Threat Description Information Security Governance Threats (cont.) G. Solid enterprise governance H. Support for audit and forensic investigations Figure 9 Cloud Threats and Mitigating Actions Mapped to COBIT 5 for Information Security (cont.) Enterprises turn to CSPs in search of solutions that can be implemented easily and at a low cost. This ease can be tempting, especially when the enterprise is facing urgent deadlines that require an urgent solution (like the expiration of application licenses, or the need of more computing capacity). This can become an issue because organizations may contract cloud applications without proper procurement and approval oversight, thus bypassing compliance with internal policies. 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 (e.g., to authenticate the CSP). This raises several issues because performing these actions requires having extensive access to the CSP s infrastructure and monitoring capabilities, which are often shared with other CSP s customers. The enterprise should have the permission of the CSP to perform regular audits and to have access to forensic data without violating the contractual obligations of the CSP to other customers. Risk Factors Mitigation S3.I Ensure that internal governance controls are in place within the enterprise to involve the necessary control organizations (legal, compliance, finance, etc.) during the decision process of migrating to cloud services. S1.F S1.L Request of the CSP the right to audit as part of the contract or SLA. If this is not possible, request security audit reports by trusted third parties. Request that the CSP provide appropriate and timely support (logs, traces, hard disk images) for forensic analysis as part of the contract or SLA. If this is not possible, request of the CSP to authorize trusted third parties to perform forensic analysis when necessary. Mapping to COBIT 5 for Information Security Appendix B. Detailed Guidance: Processes Enabler B.1 Evaluate, Direct and Monitor (EDM). EDM01 Ensure Governance Framework Setting and Maintenance. B.5 Monitor, Evaluate and Assess (MEA). MEA02 Monitor, Evaluate and Assess the System of Internal Control. Appendix B. Detailed Guidance: Processes Enabler B.2 Align, Plan and Organise (APO). APO10 Manage Suppliers. B.5 Monitor, Evaluate and Assess (MEA). MEA02 Monitor, Evaluate and Assess the System of Internal Control.

77 Abbreviations 77 Abbreviations Abbreviation BCM CAPEX CIO CISO CSP DDoS DRP IaaS IAM IDS/IPS ISM ISO OPEX OS PaaS QoS RPO RTO SaaS SDLC SIEM SLA SOA TCO VM Business continuity management Full Term Capital expenditures used to acquire or upgrade physical assets such as buildings, infrastructure and equipment Chief information officer Chief information security officer Cloud service provider Distributed denial of service Disaster recovery plan Infrastructure as a Service Identity and access management Intrusion detection system/intrusion prevention system Information security manager International Organization for Standardization Operating expenditures ongoing cost for running a product, business or organization Operating system Platform as a Service Quality of service Recovery point objective Recovery time objective Software as a Service Systems development life cycle Security incident and event manager Service level agreement Service oriented architecture Total cost of ownership Virtual machine

78 78 Security Considerations for Cloud Computing Page intentionally left blank

79 References 79 References ISACA, COBIT 5, USA, 2012 ISACA, COBIT 5 for Information Security, USA, 2012 ISACA, COBIT 5 Implementation, USA, 2012 ISACA, IT Control Objectives for Cloud Computing: Controls and Assurance in the Cloud, USA, 2011 ISACA, Risk IT Framework for Management of IT Related Business Risks, ISACA, 2009 Mell, Peter; Timothy Grance; The NIST Definition of Cloud Computing, US National Institute of Standards and Technology (NIST) Special Publication (SP) , USA, 2011

80 80 Security Considerations for Cloud Computing Page intentionally left blank