Security Guidance v5 2024 PDF

Security Guidance For Critical Areas of Focus in Cloud Computing v5 The permanent and official location for the CSA Security Guidance Working Group is https://cloudsecurityalliance.org/research/working-groups/security-guidance © 2024 Cloud Security Alliance – All Rights Reserved. You may download, store, display on your computer, view, print, and link to the Cloud Security Alliance at https://cloudsecurityalliance.org subject to the following: (a) the draft may be used solely for your personal, informational, noncommercial use; (b) the draft may not be modified or altered in any way; (c) the draft may not be redistributed; and (d) the trademark, copyright or other notices may not be removed. You may quote portions of the draft as permitted by the Fair Use provisions of the United States Copyright Act, provided that you attribute the portions to the Cloud Security Alliance. © Copyright 2024, Cloud Security Alliance. All rights reserved. 2 Acknowledgments Lead Authors Roberto Bonalumi Karl Brooks Jasper Brouwer Rich Mogull Amit Butail Mike Rothman Varun Carlay Dhanushraj Chandrahasan Senthilkumar Chandrasekaran Contributors Akshay Chandrasekaran Sekar Shankar Chebrolu Jackie Donnelly Anand Chirathadam Abraham Moshe Ferber John Chiu Larry Hughes Anand Choksi Michael Roza Vipul Dabhi Peter van Eijk Joseph Dacuma Michel-Ange Dagrain Thomas Defise Reviewers Neelima Devana Mankirat Dhodi Singh Balaram Dhulipudi Mohammad Aamir Dr. Ivan Djordjevic Frank Addo Ivan Djordjevic Daniel Adjorlolo Moses Dlamini Hafiz Ahmed Sheikh Adnan Keinaz Domingo N. Ilango Allikuzhi David Dorsey Shonnie Almeida J. Rob Doyon Babs Alo Vinay Dubey Aakash Alurkar Swapna Dulganti Agbu Amachundi Enoch Nielet D’Mello Stephen Amolo Mohamed Elbashir Divya Aradhya Mahmood Elrefai Robyn Bailey Joseph Emerick Adeel Bakht Dr. Marco Ermini Suramya Bakshi Kingsley Ezeocha Mohamed Balushi Al Ahmed Fawzy Vinay Bansal Lorena Ferreyro Robin Basham Kenneth Ferris Myriam Batista Jonathan Fessenden Allen Baylis Jose Figueredo-Maseda C. Renu Bedi Elaine Flesch Paul Benedek Fernando Fonseca Bachir Benyammi Park Foreman Jamie Beth Adame Frances Shirin Bhambhani Aadithya Francis © Copyright 2024, Cloud Security Alliance. All rights reserved. 3 André Gaio Alexandre Seshagirirao Lekkala Luca Gattobigio Yutao Ma Viktor Gazdag Stephen Macomber Jan Gerst Yuvaraj Madheswaran Hussein Ghazy Niclas Madsen Tulika Ghosh Ahmed Mahmoud Nabil Ricardo Giorgi Vaibhav Malik Andriana Gkaniatsou Mohamed Malki Saurabh Goswami Cecil Martin Trevor Gregorio Marcus Maxwell Nageswara Gude Rao Bilal Mazhar Madhu Guthikonda Mark McDonagh Ahmed Harris José Medina Carlos Vargas Lyle Hearne Santiago Medranda Johnny Hernandez Ashish Mehta Dirce Hernandez Eduardo Shobhit Mehta Aldo Hernández Villaseca Andre Mess Moreno Hill Sint Enida Metaj Matthew Hoerig Akhil Mittal Abdulsalam Ibrahim B. Adeeb Mohammed Ricci Ieong Victor Monga Frank Iheonu Kenneth Moras Arron Johnson Masahiro Morozumi Rahul K Andrew Morrow B. Prasannakumar K G Venkata Nedunoori Patrick Kabongo B. Harry Ngai Nithin Kadumberi Mohan Thattiot Fredrick Ogonda Ruchi Kandpal Esborn Okero Sivakumar Karthikeyan Opeyemi Onifade Shakthi Kathirvelu Priya Joseph Orsetto Sunil Katwal John Oseh B. Arpitha Kaushik Jed Owens Alon Kendler Iyiola Oyinloye Rohit Khosla Mayur Pahwa Vana Khurana Govindaraj Palanisamy Jari Kiero Meghana Parwate Brenda Killingsworth L. Vaibhav Patkar Morgan King Martino Pavone Samantha Kloos-Kilkens Eric Peeters Simon Kok Eliza Popa Vivek Krishnan Kunal Pradhan Sunil Kumar Ramon Quimesó Domingo Francois Laas Adnan Rafique Hadir Labib Sonali Rajesh ZolT R Daniel Lai Marappan Ramiah Raymond Lai Alex Rebo Law Lain Chamber Aldo Richner Sundas Latif Rangel Rodrigues © Copyright 2024, Cloud Security Alliance. All rights reserved. 4 Vishakha Sadhwani Vaishnav Vijayakumar Shahid Saleem Antonio Villamor Magallanes Jr Joshua Salvador Alex Webling Mukund Sarma Henry Werchan Patnana Sayesu Udith Wickramasuriya Davide Scatto Pawel Wilczynski Thomas Schmidt Rini Wilson Michael Schmitz Wai Wong Kong Kg.Seow Ben Woods Vikrant Shah Ezra Woods Rakesh Sharma James Yankelvich Alex Sharpe Tsutomu Yoneyama Akshay Shetty Bader Zyoud Dr. Ian Silvester Dennis de Caes Ryan Simon Peter van Loon Gurpratap Singh Tiaan van Schalkwyk Gaurav Singh Anamika Singh Serenity Smile CSA Global Staff Heinrich Smit Jorge Soboredo González Judy Bagwell Silvano Sogus Hillary Baron Mikhail Sokolov Marina Bregkou Dr. Chantal Spleiss Josh Buker Dr. Manish Srivastava Kumar Daniele Catteddu Kevin Stander Emily Everett Roy Stultiens Ryan Gifford Yuanji Sun Frank Guanco Pratibha Swamy Sean Heide Manjunath T A Erik Johnson Mohammed Tanveer Alex Kaluza Billy Teow Claire Lehnert Kim Tham Fui Stephen Lumpe Timothy Thatcher Cion Mensidor Michael Theriault Hannah Rock Larry Timmons Andy Ruth Chee Tiong Anna Schorr Campbell Ilia Tivin Stephen Smith Wiem Tounsi Adriano Sverko Micheal Troutman John Yeoh Nsikak-Abasi Una Shammah Pieter VanIperen Ashish Vashishtha Peter Ventura © Copyright 2024, Cloud Security Alliance. All rights reserved. 5 Table of Contents Acknowledgments........................................................................................................................................................3 Lead Authors......................................................................................................................................................... 3 Contributors...........................................................................................................................................................3 Reviewers............................................................................................................................................................... 3 CSA Global Staff...................................................................................................................................................5 Table of Contents.........................................................................................................................................................6 Introduction to Security Guidance v5.......................................................................................................................9 Domain 1: Cloud Computing Concepts & Architectures............................................................................. 10 Learning Objectives............................................................................................................................................. 11 1.1 Defining Cloud Computing............................................................................................................................. 11 1.2 Cloud Computing Models............................................................................................................................. 12 1.3 Reference & Architecture Models................................................................................................................15 1.4 Cloud Security Scope, Responsibilities, & Models.................................................................................... 21 Summary & Areas of Critical Focus - Governance & Operations................................................................ 25 Domain 2: Cloud Governance and Strategies................................................................................................28 Learning Objectives........................................................................................................................................... 29 2.1 Cloud Governance........................................................................................................................................ 29 2.2 Effective Cloud Governance...................................................................................................................... 34 2.3 The Governance Hierarchy......................................................................................................................... 37 2.4 Key Strategies & Concepts.........................................................................................................................49 Summary..............................................................................................................................................................54 Domain 3: Risk, Audit and Compliance............................................................................................................ 56 3.1. Cloud Risk Management............................................................................................................................. 56 3.2 Compliance & Audit..................................................................................................................................... 68 3.3 Governance, Risk, and Compliance: Tools & Technologies....................................................................78 Summary............................................................................................................................................................... 81 Domain 4: Organization Management............................................................................................................ 84 Introduction.........................................................................................................................................................84 Learning Objectives........................................................................................................................................... 85 4.1 Organization Hierarchy Models...................................................................................................................85 4.2 Managing Organization-Level Security................................................................................................... 90 4.3 Considerations for Hybrid & Multi-Cloud Deployments........................................................................96 Summary..............................................................................................................................................................101 Recommendations............................................................................................................................................ 102 Additional Resources........................................................................................................................................ 103 Domain 5: Identity and Access Management.............................................................................................. 104 Introduction....................................................................................................................................................... 104 Learning Objectives..........................................................................................................................................105 5.1 How IAM is Different in the Cloud............................................................................................................. 105 © Copyright 2024, Cloud Security Alliance. All rights reserved. 6 5.1 Fundamental Terms.....................................................................................................................................106 5.2 Federation....................................................................................................................................................108 5.3 Strong Authentication & Authorization.....................................................................................................113 5.4 IAM Policy Types for Public Cloud............................................................................................................ 119 5.5 Least Privilege & Automation................................................................................................................... 120 Summary............................................................................................................................................................. 122 Domain 6: Security Monitoring........................................................................................................................ 125 Introduction........................................................................................................................................................ 125 Learning Objectives.......................................................................................................................................... 125 6.1 Cloud Monitoring......................................................................................................................................... 125 6.2 Cloud Telemetry Sources.......................................................................................................................... 128 6.3 Collection Architectures............................................................................................................................134 6.4 Detection & Security Analytics.................................................................................................................138 6.5 Generative AI for Security Monitoring.................................................................................................... 143 Summary.............................................................................................................................................................145 Domain 7: Infrastructure & Networking........................................................................................................147 Introduction........................................................................................................................................................ 147 Learning Objectives.......................................................................................................................................... 147 7.1 Cloud Infrastructure Security..................................................................................................................... 148 7.2 Cloud Network Fundamentals...................................................................................................................154 7.3 Cloud Connectivity..................................................................................................................................... 163 7.4 Zero Trust & Secure Access Service Edge.............................................................................................. 170 Summary.............................................................................................................................................................177 Domain 8: Cloud Workload Security...............................................................................................................179 Introduction........................................................................................................................................................179 Learning Objectives..........................................................................................................................................179 8.1 Introduction to Cloud Workload Security.................................................................................................179 8.2 Virtual Machines......................................................................................................................................... 184 8.3 Securing Containers................................................................................................................................... 192 8.4 PaaS Security..............................................................................................................................................198 8.5 Securing Serverless or Function as a Service.......................................................................................200 8.6 AI Workloads.............................................................................................................................................. 204 Summary............................................................................................................................................................207 Domain 9: Data Security......................................................................................................................................211 Introduction......................................................................................................................................................... 211 Learning Objectives........................................................................................................................................... 211 9.1 Data Classification & Storage Types.......................................................................................................... 211 9.2 Securing Specific Cloud Workload Types............................................................................................... 215 9.3 Securing Specific Storage Types............................................................................................................ 224 Summary........................................................................................................................................................... 230 Domain 10: Application Security..................................................................................................................... 232 Introduction....................................................................................................................................................... 232 Learning Objectives......................................................................................................................................... 233 © Copyright 2024, Cloud Security Alliance. All rights reserved. 7 10.1 Secure Development Lifecycle............................................................................................................... 233 10.2 Secure Cloud Applications Architecture...............................................................................................238 10.3 Identity & Access Management Application Security......................................................................... 242 10.4 DevSecOps: CI/CD & Application Testing........................................................................................... 245 10.5 Serverless & Containerized Application Considerations....................................................................250 Summary............................................................................................................................................................ 252 Domain 11: Incident Response & Resilience.................................................................................................. 255 Introduction....................................................................................................................................................... 255 Learning Objectives......................................................................................................................................... 255 11.1 Incident Response...................................................................................................................................... 256 11.2 Preparation................................................................................................................................................. 258 11.3 Detection & Analysis................................................................................................................................. 263 11.4 Containment, Eradication & Recovery................................................................................................... 269 11.5 Post-Incident Analysis................................................................................................................................271 11.6 Resilience.................................................................................................................................................... 272 Summary............................................................................................................................................................ 275 Domain 12: Related Technologies & Strategies.......................................................................................... 278 Introduction....................................................................................................................................................... 278 Learning Objectives......................................................................................................................................... 278 12.1 Zero Trust.................................................................................................................................................... 278 12.2 Artificial Intelligence.................................................................................................................................289 12.3 Threat & Vulnerability Management...................................................................................................... 293 Summary............................................................................................................................................................297 © Copyright 2024, Cloud Security Alliance. All rights reserved. 8 Introduction to Security Guidance v5 Welcome to the fifth version of the Cloud Security Alliance’s Security Guidance for Critical Areas of Focus in Cloud Computing, or Security Guidance for short. The rise of cloud computing as an ever-evolving technology brings with it a number of opportunities and challenges. With this document, we aim to provide both guidance and inspiration to support business goals while managing and mitigating the risks associated with the adoption of cloud computing technology. The Cloud Security Alliance promotes implementing best practices for providing security assurance within the domain of cloud computing and has delivered a practical, actionable roadmap for organizations seeking to adopt the cloud paradigm. The fifth version of the Security Guidance is built on previous iterations of the Security Guidance, dedicated research, and public participation from the Cloud Security Alliance members, working groups, and the industry experts within our community. This version incorporates advances in cloud, security, and supporting technologies; reflects on real-world cloud security practices; integrates the latest Cloud Security Alliance research projects; and offers guidance for related technologies. The advancement toward secure cloud computing requires active participation from a broad set of globally-distributed stakeholders. CSA brings together this diverse community of industry partnerships, international chapters, working groups, and individuals. We are profoundly grateful to all who contributed to this release. Please visit cloudsecurityalliance.com to learn how you can work with us to identify and promote best practices to ensure a secure cloud computing environment. Best regards, Jim Reavis Chief Executive Officer (CEO) Cloud Security Alliance Illena Armstrong President Cloud Security Alliance © Copyright 2024, Cloud Security Alliance. All rights reserved. 9 Domain 1: Cloud Computing Concepts & Architectures This domain provides the conceptual framework for the rest of the Cloud Security Alliance (CSA) Security Guidance. It describes and defines cloud computing, sets out baseline terminology, and details the overall controls, deployment, and architectural models used in the rest of the document. Cloud computing can be viewed from various perspectives, such as a technology, a collection of technologies, an operational model, a business model, or an economic paradigm, just to name a few. Cloud computing is transformative and disruptive to legacy computing systems and has taken over as the dominant digital transformation model. While the reference models included in the early versions of the CSA CCSK Security Guidance are still relevant, they require updates to reflect ongoing advancements (e.g., new tools and technologies from cloud service providers (CSP), Zero Trust, AI, and evolving practices) as the industry matures. Even with this update, the ongoing rise of automation and artificial intelligence capabilities cannot account for all evolution in the coming years. Cloud computing can provide significant agility, resiliency, security, and economic benefits. However, these benefits are only materialized if cloud models are properly understood and adopted, and cloud architectures and practices are aligned with the features and capabilities of cloud platforms. A cloud service customer (CSC1) migrating an existing application or asset by simply moving it to a CSP without any changes (known as rehosting or "lift-and-shift”) will often not provide the expected agility, resiliency, and security, all while increasing costs. In short, the benefits of cloud computing are closely tied to understanding the proper use of cloud computing models, cloud-native capabilities, and services. This domain aims to build the foundation on which the rest of this guide and its recommendations are based. The intent is to provide a common language and understanding of cloud computing, while highlighting the differences between cloud and traditional computing. In addition to the already stated cloud benefits, this domain will help guide cloud security professionals and other relevant stakeholders toward adopting cloud-approaches that ensure a better security posture The Cloud Security Alliance is not setting out to create an entirely new taxonomy or reference model. Our objective is to distill and harmonize existing models — most notably the work in NIST SP 800-1452, ISO/IEC 22123-1:20233, and ISO/IEC 22123-2:20234 — focusing on the most relevant security considerations for professionals working within the cloud computing field. Additional references are provided to further enhance the understanding of the fundamental principles and explore specific topics and practical strategies for implementing cloud security practices. 1 The acronym CSC is used interchangeably to mean any cloud service customer, cloud service consumer, or cloud service client. 2 NIST. (2011) SP 800-145: The NIST Definition of Cloud Computing 3 ISO/IEC. (2023) 22123-1:2023: Information technology - Cloud computing Part 1: Vocabulary 4 ISO/IEC. (2023) 22123-2:2023: Information technology - Cloud computing Part 2: Concepts © Copyright 2024, Cloud Security Alliance. All rights reserved. 10 Learning Objectives In this domain, you will learn to: Define cloud computing. Identify cloud computing models. Recognize reference and architecture models in cloud computing. Understand cloud security scope, responsibilities, and models. 1.1 Defining Cloud Computing Cloud computing is an operational model and a set of technologies used to manage shared pools of computing resources through abstraction of compute, network, storage, etc. The cloud model envisions a world where components and resources can be rapidly orchestrated, provisioned, implemented, scaled up or down, and decommissioned, providing an on-demand utility-like model for allocation and consumption. Benefits include stakeholder collaboration, agility, elasticity, availability, resiliency, and cost reduction. The following are definitions of cloud computing according to The U.S. National Institute of Standards and Technology (NIST) and The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC): NIST SP 800-145 defines cloud computing as: “Cloud computing is 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.”5 ISO/IEC 22123-1:2023 defines cloud computing as: “Paradigm for enabling network access to a scalable and elastic pool of shareable physical or virtual resources with self-service provisioning6 and administration on-demand.”7 A simpler way of describing the cloud is that it takes a set of resources, such as processors and memory, and puts them into a big pool (in this case, using virtualization8). CSCs request resources they need out of the pool, based on their requirements (such as 8 CPUs and 16 GB of memory). The underlying cloud computing technology orchestrates those resources to the CSC, who then connects to and uses the resources over the network. When the CSC is done, they can release the resources back into the pool for others to use. A cloud can consist of nearly any computing resource, ranging from our raw infrastructure examples of processors, memory, and networks, to higher-level software resources like databases and applications. For 5 NIST. (2011) SP 800-145: The NIST Definition of Cloud Computing. 6 Self-service provisioning refers to the provisioning of resources provided to cloud services performed by CSCs through automated means. Examples of resources include servers, operating systems, networks, software, applications, and storage equipment. 7 ISO/IEC. (2023) Information Technology - Cloud Computing - Part 1: Vocabulary. 8 NIST. (2018) SP 800-125A: Security Recommendations for Hypervisor Deployment on Servers Virtualization. © Copyright 2024, Cloud Security Alliance. All rights reserved. 11 example, subscribing to a customer relationship management (CRM) application for 500 employees on a service shared by hundreds of other organizations is just as much cloud computing as launching 100 remote servers on a compute cloud. 1.1.1 Abstraction & Orchestration The key concepts that enable the cloud environment are abstraction and orchestration. Resources are abstracted from the underlying physical infrastructure to create pools of resources, and orchestration (and automation) is used to coordinate, allocate, and deliver resources from pools to CSCs. Intrinsic to this is a level of standardization, so that all CSCs are essentially getting the same functional service they can, then integrate in their own flexible way. As you will see, these two concepts create all the essential characteristics we use to define something as a “cloud.” Clouds are multi-tenant9 by nature. Multiple CSCs share the same pool of resources but are logically and at times physically segregated and isolated from each other. Segregation allows the CSP to divvy up resources to the different CSCs, and segregation ensures they cannot see or modify each other’s assets, which is fundamental for the confidentiality and integrity of CSC data. In addition, a CSP’s ability to measure and constrain the overuse of resources is critical for the democratic use and availability of the service delivered to each CSC. Multi-tenancy extends beyond inter-organizational use to facilitate resource distribution among various units within a single organization, often referred to as a "private cloud.” 1.2 Cloud Computing Models The CSA uses the NIST SP 800-145 model for cloud computing as it is the standard for defining cloud computing10. CSA also endorses the more in-depth ISO/IEC model 22123-1:2023 and 22123-2:2023, which also serves as a reference model. Throughout this domain, we will reference both. NIST describes cloud computing based on five essential characteristics, three cloud service models, and four cloud deployment models, which are summarized in the following sections. 9 In this reference to multi-tenant, a tenant is a cloud customer or CSC. 10 CSA has chosen to align with the NIST definition of cloud computing (NIST 800-145) to drive consensus for a common language and focus on use cases rather than semantics. This material is intended to be broadly usable and applicable to organizations globally. While NIST is a U.S. government organization, the selection of this reference model should not be interpreted to suggest the exclusion of other points of view or geographies. © Copyright 2024, Cloud Security Alliance. All rights reserved. 12 11 Figure 1: Overview of Cloud Computing Models Based on NIST and ISO/IEC Standards 1.2.1 Essential Characteristics The NIST model describes the cloud by five essential characteristics, which sets cloud computing apart from traditional hosting services or other types of cloud services, such as hosting and virtualization. Understanding these characteristics is critical for leveraging the full potential of cloud computing and for the strategic planning of cloud adoption. Following are the five essential characteristics described by NIST. Resource Pooling: Cloud computing pools various physical and virtual resources to serve multiple CSCs using a multi-tenant model. These resources, like storage, processors, memory, and network bandwidth, are dynamically assigned and reassigned according to demand. Broad Network Access: Services are available over the network and accessed through web browsers or specialized applications that promote use by heterogeneous thin or thick client platforms (e.g., servers, mobile phones, laptops, IoT devices, and tablets). Rapid Elasticity: Resources can be rapidly and elastically provisioned, in some cases automatically, to rapidly scale out and back. To the CSC, the provisioned capabilities often appear unlimited and can be purchased in any quantity at any time 11 Depiction of the NIST Model of Cloud Computing © Copyright 2024, Cloud Security Alliance. All rights reserved. 13 Measured Service: Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, bandwidth, active user accounts). Resource usage can be measured, monitored, controlled, and reported, providing transparency for both the CSP and the CSCs of the utilized service. This enables billing based on usage, which promotes cost efficiency and accountability (e.g. pay-as-you-go model). On-Demand Self-Service: A CSC can unilaterally request cloud resources on demand for automatic provisioning by the CSP and computing capabilities, such as computing time and network storage, as needed without requiring human interaction with each CSP. ISO/IEC 22123: 2023 lists six key characteristics, the first five being identical to the NIST characteristics listed above. The only addition is multi-tenancy, which is distinct from resource pooling. 1.2.2 Cloud Service Models NIST defines three service models describing the different foundational categories of cloud services: Software as a Service (SaaS) is an application that is managed and hosted by the CSP. CSCs access it using a web browser, mobile application, application programming interfaces (APIs), or lightweight client application. In this model, the CSC only worries about the application's configuration, not the underlying resources. Platform as a Service (PaaS) abstracts and provides platforms, such as application platforms (e.g., a place to develop and run code), databases, file storage, and collaborative environments. Other examples include application processing environments for machine learning, big data processing or API access to SaaS functions. The key differentiator is that, with PaaS, the CSC does not manage the underlying infrastructure. Infrastructure as a Service (IaaS) offers access to a resource pool of fundamental computing infrastructure, such as network, or storage. In IaaS the CSCis responsible for managing the underlying virtual infrastructure, such as virtual machines, networking, storage, and running applications. ISO/IEC 22123-3:2023 uses a more complex definition with a cloud capabilities type that maps closely to the SaaS, PaaS, and IaaS (also known as SPI) service model tiers (application, platform, and infrastructure capability types). It then expands into cloud service categories that are more granular, such as communications-as-a-service (CaaS), network-as-a-service (NaaS), data storage as a service (DSaaS), and data recovery as a service. These categories are somewhat permeable; some cloud services span the SPI tiers, while others do not fall neatly into a single service model. Practically speaking, there is no reason to assign everything into these three categories, or even the more granular categories in the ISO/IEC model. This is a descriptive tool, not a rigid framework. © Copyright 2024, Cloud Security Alliance. All rights reserved. 14 Both approaches are valid, but since the NIST model is more concise and broadly used, it is the definition predominantly used in CSA research. 1.2.3 Cloud Deployment Models NIST and ISO/IEC use the same four cloud deployment models; these are how the technologies are deployed, consumed, and applied across the entire range of service models. Public Cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by a CSP. Private Cloud: The cloud infrastructure is operated solely for a single organization. It may be managed by the organization or a third party and may be located on-premises or off-premises. Community Cloud: The cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policy, compliance considerations). It may be managed by the CSC(s) or a third party, and may be located on-premises or off-premises. Hybrid Cloud: The cloud infrastructure is a composition of two or more clouds (i.e., private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting12 for load balancing between clouds).13 Other deployment models: Multi-cloud: In a multi-cloud environment, a CSC utilizes multiple cloud services, such as applications and systems, from different CSPs. This approach is commonly adopted to reduce dependency on a single cloud provider and build technical resilience into the architecture design. Hybrid multi-cloud: A combination of public cloud and private resources, typically a connection to a traditional datacenter. 1.3 Reference & Architecture Models There is a wide range of evolving technologies and techniques used to build and operate cloud services, potentially rendering aspects of any single reference or architectural model obsolete. The objective of this section is to provide some fundamentals, and to provide a baseline for understanding complex and emerging models to help security professionals make informed decisions. We recommend ISO/IEC 22123 and NIST 500-29214 as in-depth reference architectural models, which complement the NIST cloud 12 A configuration setup where an application running in a private cloud or data center dynamically extends to a public cloud to access additional computing resources when the demand exceeds the capacity of the primary environment, ensuring consistent performance and availability. 13 Hybrid is also commonly used to describe a non-cloud data center bridged directly to a CSP. The original NIST definition refers to a mixture of cloud solutions. Since then it has become more narrowly focused on mixtures of cloud models. 14 NIST. (2011) NIST Cloud Computing Reference Architecture © Copyright 2024, Cloud Security Alliance. All rights reserved. 15 computing definitions. Additionally, we suggest exploring the CSA Enterprise Architecture Model,15 which aims to consolidate features from four discrete organizational architectures. One way of looking at cloud computing is as a stack where SaaS is built on PaaS, which in turn is built on IaaS. This is not representative of all (or even most) real-world deployment models, but it serves as a useful reference baseline. The SPI stack is evolving, and we are seeing overlaps and less clear distinctions between the service models as service offerings mature. So first, let us get a feel for the standard architectures of each cloud service model (layer in the SPI stack), and then some examples to show how the lines are blurring. Finally, we conclude with the CSA Enterprise Architecture Model, which can assist anyone who is developing cross-platform capabilities and patterns or is interested in an integrated, multi-cloud approach. 1.3.1 Infrastructure as a Service Physical facilities and infrastructure hardware form the foundation of IaaS. With cloud computing, we abstract and pool these resources, but at the most basic level, we always need physical hardware, networks, and storage to build on. These resources are pooled using abstraction and orchestration. Abstraction, often through virtualization, frees the resources from their physical constraints to enable pooling. Then a set of core connectivity and delivery tools (orchestration) ties these abstracted resources together, creates the pools, and provides the automation to assign and deliver them to CSCs. Orchestration is generally facilitated using APIs. APIs are typically the underlying communications method for components within the cloud, some of which are exposed to the CSC to manage resources and configurations. Most cloud APIs these days use Representational State Transfer (REST), which runs over the HTTP, making it well-suited for Internet services. In most cases, those APIs are both remotely accessible and wrapped into a web-based user interface. This combination is the cloud management or control plane, since CSCs use it to manage and configure cloud resources, such as launching virtual machine instances or configuring virtual software-defined networks. From a security perspective, it is the biggest difference from protecting on-premises infrastructure, since management interfaces are now facilitated over a network. If an attacker compromises a management plane, they have privileged access to the cloud infrastructure. 15 CSA. (2021) CSA Enterprise Architecture Reference Guide. © Copyright 2024, Cloud Security Alliance. All rights reserved. 16 Here is an extremely simplified architectural example of a compute IaaS platform. Figure 2: Simplified Architecture of an IaaS Compute Platform This example showcases an IaaS compute platform with physical servers running hypervisors16 and orchestration software. The cloud controller allocates resources, creates virtual instances, configures networking and storage, and brokers connectivity information for CSCs to access the instances. 1.3.2 Platform as a Service Of all the service models, PaaS is the hardest to definitively characterize due to the wide range of PaaS offerings and varying approaches. PaaS services generally integrate application development frameworks, middleware capabilities, and supporting services such as databases, message queues, and event logging. These services allow developers to build applications on the platform with programming languages and tools supported by the stack. One option, frequently seen in the real world and illustrated in our model, is to build a platform on top of IaaS. For example, integration, persistence, and middleware layers are built on an IaaS platform, then pooled together, orchestrated, and made accessible to CSCs through APIs as a PaaS service. 16 A hypervisor, also known as a virtual machine monitor (VMM), is a software, firmware, or hardware platform that creates and runs virtual machines by abstracting and managing the underlying physical hardware resources, allowing multiple operating systems to run concurrently on a single physical host. © Copyright 2024, Cloud Security Alliance. All rights reserved. 17 This could be a database as a service (DBaaS) built and deployed using modified database management system software instances. The CSC manages the database via API and/or a web console and accesses it through normal database network protocols and/or an API. In PaaS, the cloud user only sees the platform (or the application presentation layer that leverages it), but not the underlying infrastructure. In our example, the database service expands or contracts as needed based on utilization without the CSC having to manage individual servers, networking, patches, and so on. The following is a simplified architecture that shows a PaaS running on top of our IaaS architecture. Figure 3: Simplified Architecture of a PaaS Built on IaaS PaaS does not necessarily need to be built on top of IaaS; there is no reason it cannot be a custom-built, stand-alone architecture. The defining characteristic is that CSCs access and manage the platform, not the underlying cloud infrastructure. One potential example could be a custom AI and machine learning integration service supporting use cases like AI-powered development tools, machine learning operations (MLOps)17, and AI lifecycle management. Machine Learning Operations (MLOps) is a set of practices that streamline the entire lifecycle of machine learning models. It 17 unifies ML application development with ML system deployment and operations. © Copyright 2024, Cloud Security Alliance. All rights reserved. 18 1.3.3 Software as a Service SaaS services are complete applications, encompassing all the architectural complexities typical of any large software platform. Many SaaS CSPs build on top of IaaS and PaaS due to the increased agility, resilience, and economic benefits. Most modern cloud SaaS applications combine IaaS and PaaS, sometimes across different CSPs. Many also offer public APIs for some or all functionality. They are often needed to support various CSCs, especially web browsers, APIs, and mobile applications. SaaS services tend to have an application/logic layer and data storage, API and presentation layer services that commonly support web browsers and mobile application user interfaces, as well as Internet API access. The simplified architecture below is taken from a real SaaS platform, but generalized to remove references to the specific products in use. Figure 4: Simplified Architecture of a SaaS Platform Built on PaaS and IaaS 1.3.4 Anything as a Service Anything as a Service, or XaaS, represents a broad, encompassing term that captures the essence of various services delivered over the Internet, rather than provided locally or on-premises. This model is foundational to cloud computing, where "X" can represent virtually any service, application, or platform component delivered to users as a service, for example, Security as a Service, DBaaS, Directory as a © Copyright 2024, Cloud Security Alliance. All rights reserved. 19 Service, Identity as a Service, AI as a Service. These nearly always fit into the IaaS/PaaS/SaaS model but are more specific and descriptive in their naming. 1.3.5 Overlapping Service Models While the SPI cloud service model is frequently represented hierarchically, with each layer built upon the one below it (IaaS, PaaS, SaaS), the ways these services are implemented and utilized in practice can be much more flexible. The SPI stack is a useful guide for understanding the different cloud service models. It is important to recognize the inherent flexibility and overlapping layers. The SPI implementations do not need to be built on a strict hierarchy, and the lines are often blurred between the models, known as overlapping service models. Overlapping service models are not defined by a strict hierarchy and often encapsulate characteristics of multiple service models simultaneously For example, many services encapsulate characteristics of both SaaS (a fully delivered application in a web browser) and PaaS (APIs to integrate some of the platform's capabilities into customer architectures). 1.3.6 CSA Enterprise Architecture Model The CSA Enterprise Architecture (EA) is both a methodology and a set of tools. It is a framework, that is, a comprehensive approach for the architecture of a secure cloud infrastructure. It can be used to assess opportunities for improvement, create roadmaps for technology adoption, identify reusable security patterns, and assess various CSPs and security technology vendors against a common set of capabilities. To create the CSA EA, CSA Research has leveraged four industry standard architecture models across the following four domains: Business Operation Support Services (BOSS) — Sherwood Applied Business Security Architecture (SABSA) IT Operation Services (ITOS) — IT Infrastructure Library (ITIL) Technology Solution Services (TSS), including Infrastructure (InfraSrv), Information (InfoSrv), application (AS), and Presentation (PS) Services — The Open Group Application Framework (TOGAF) Security and Risk Management (SRM) — OpenGroup Security Forum (formerly known as the Jericho Forum) Figure 5: Building Blocks of the CSA Enterprise Architecture © Copyright 2024, Cloud Security Alliance. All rights reserved. 20 CSA combines the best architecture paradigms into a comprehensive approach to cloud security while merging business drivers. The CSA EA supports the value proposition of cloud services within an enterprise business model. The CSA EA was adopted by NIST SP 500-292, solidifying the importance of the CSA approach. 1.4 Cloud Security Scope, Responsibilities, & Models Cloud security and compliance includes everything a security team is already responsible for, just in the cloud. The iterative process of identifying security requirements, selecting appropriate cloud services, and implementing controls to mitigate risks effectively in cloud computing is delineated by the principle of shared responsibility. We describe the model based on this principle. We outline the division of security responsibilities, with CSPs accountable for infrastructure security, and CSCs responsible for their deployed applications and data. This separation of responsibilities varies across service models (IaaS, PaaS, SaaS) and CSPs, underscoring the importance for CSCs to understand their divided obligations. Additionally, we explore the role of frameworks and tools, such as the CSA Consensus Assessments Initiative Questionnaire (CAIQ) and CSA Cloud Controls Matrix (CCM), in facilitating compliance and alignment with security standards. All the traditional security domains remain, but the nature of risks, roles and responsibilities, and implementation of controls, change often and rapidly. Though the overall scope of security and compliance does not change, the portions any given cloud actor is responsible for certainly do. Think of it this way: Cloud computing is a shared technology model where different organizations are responsible for implementing and managing different parts of the stack. As a result, security responsibilities are also distributed across the stack and, thus, across the organizations involved. This is commonly referred to as the Shared Security Responsibility Model (SSRM), sometimes shortened to SRM. Think of it as a responsibility matrix that depends on the particular cloud provider and feature/product, service, and deployment model. 1.4.1 Shared Security Responsibility Model In cloud computing, security is a joint effort between CSPs and CSCs. The term “shared responsibility” is widely used by multiple CSPs and refers to the delineation where the CSP takes responsibility for security operations and controls. Below the line is the CSP’s responsibility; anything a CSC builds above the line is the CSC’s responsibility. This varies greatly as you change service models. This SSRM model outlines that CSPs are responsible for the security "of the cloud," including infrastructure, hardware, and network. CSCs, however, are responsible for what they deploy in the cloud. The delineation of responsibilities will differ for IaaS, PaaS, and SaaS and often between different CSPs. It is critical for CSCs to understand where the demarcation lies to ensure that they are appropriately protecting their own cloud tenants, applications, data, etc., and to provide baselines for holding CSPs accountable. © Copyright 2024, Cloud Security Alliance. All rights reserved. 21 At a high level, security responsibility maps to the degree of control any given actor has over the architecture stack. Software as a Service: The CSP is responsible for most of the security since the cloud user can only access and manage their use of the application, and cannot alter how the application works. Even if the CSC responsibilities are narrower and more limited in each security domain, they seldom drop to zero. For example, a SaaS CSP is responsible for perimeter security, logging/monitoring/auditing, and application security, whereas the CSC is still responsible for the management of authorization and entitlements. Platform as a Service: The CSP is responsible for the platform's security, while the CSC is responsible for everything they implement on the platform, including how they configure any offered security features. The responsibilities are thus more evenly split. For example, when using a DBaaS, the CSP manages fundamental security, patching, and core configuration at a given service level. The CSC is responsible for everything else, including which security features of the database to use, managing accounts, or even authentication methods. Infrastructure as a Service: Just like PaaS, the CSP is responsible for foundational security, while the CSC is responsible for everything they build on the infrastructure. Unlike PaaS, this places far more responsibility on the CSC. For example, the IaaS CSP will likely monitor their perimeter for attacks, but the CSC is fully responsible for how they define and implement their virtual network security based on the tools available on the service. As we move down the SPI stack, the CSP's responsibilities decrease, and the CSC's responsibilities increase. IaaS stops lower in the stack. Thus customers are responsible for securing the operating systems and applications. PaaS is in the middle and may offer some level of security within the platform, but the CSC would still be required to make the API calls within the application and maintain a secure configuration. SaaS is a bit different because the CSP is responsible for the entire stack. Thus, the burden is on them to protect any information within their service. As you can imagine, data security is very important to SaaS CSPs since a breach or failure could result in the proverbial “run on the bank” and put the entire business in danger. These roles are further complicated when using cloud brokers or other intermediaries and partners. Understanding where the CSP's responsibility ends and where the CSC's begins is crucial. It is not just about leveraging the cloud but doing so securely by recognizing the CSC’s role in the partnership. CSCs must regularly review and understand their obligations, especially in configuration and management, to ensure that security policies/measures align with the sensitivity of the data and resources in use in their organization. The following diagram illustrates SSRM, highlighting the division of responsibilities between CSPs and CSCs across different service models. This model underscores the varying degrees of control and responsibility each actor has over the architecture stack: © Copyright 2024, Cloud Security Alliance. All rights reserved. 22 18 Figure 6: Shared Security Responsibility Model The key to effective cloud security is understanding the division of responsibilities in any cloud project. Knowing precisely who is responsible for what is crucial, regardless of specific security controls offered by CSPs. This understanding allows organizations to fill control gaps with their measures or consider alternative CSPs. A user’s ability to directly control security is very high for IaaS, and less so for SaaS. To ensure clear allocation of security responsibilities in the cloud, we recommend the following: CSPs should thoroughly document internal security controls and CSC features so that they can make informed decisions. CSPs should also properly design and implement those controls. CSCs should build a roles-and-responsibilities matrix for their security responsibilities. This matrix should document who is responsible for implementing specific security controls and ensure alignment with relevant compliance standards. CSA provides tools to help meet these requirements: The CAIQ is a standard template for CSPs to document their security and compliance controls. The CCM lists cloud security controls and maps them to multiple security and compliance standards. The CCM can also be used to document security responsibilities. 18 CISA. (2021) Cloud Security Technical Reference Architecture © Copyright 2024, Cloud Security Alliance. All rights reserved. 23 Both documents will need tuning for specific organizational and project requirements but provide a comprehensive starting template and can be especially useful for ensuring compliance requirements are met. Additional resources and guidance on the SSRM include: CSA Enterprise Architecture - This framework provides a comprehensive approach towards the architecture of a secure cloud infrastructure. Please refer to the section above on CSA EA. Enterprise Architecture to CCM Shared Responsibility Model - The mapping helps users understand cloud security responsibilities. It shows which security controls (per CCM) are the responsibility of the CSP or the CSC for different service models (IaaS, PaaS, SaaS). CCM Implementation Guidelines - Control ownership and implementation guidelines for CSPs and CSCs as it pertains to the CCM. 1.4.2 Cloud Security Frameworks & Patterns Cloud security frameworks and patterns are tools to help guide security decisions. The term “model” can be somewhat unclear, so we break out the following types: Conceptual models or frameworks include visualizations and descriptions used to explain cloud security concepts and principles, such as the NIST model in this document. Control models or frameworks categorize and detail specific cloud security controls or categories of controls, such as the CSA CCM. Reference architectures are templates for implementing cloud security, typically generalized (e.g., an IaaS security reference architecture). They can be very abstract, bordering on conceptual, or they can be quite detailed, down to specific controls and functions. Design patterns are reusable solutions to particular problems. In security, an example is IaaS log management. As with reference architectures, they can be more or less abstract or specific, even down to common implementation patterns on particular cloud platforms. The lines between these models often blur and overlap, depending on the goals of the model developers. Even grouping these together under the heading “model” is probably inaccurate, but since we see the terms used so interchangeably across different sources, it makes sense to group them. CSA recommends the following models: The CSA EA19 The CSA CCM20 ISO/IEC CD 27017.221 19 CSA. (2024) Enterprise Architecture Working Group - Enterprise Architecture 20 CSA. (2024) Cloud Controls Matrix 21 ISO. (2024) Information Technology – Security Techniques – Code of Practice for Information Security Controls based on ISO/IEC 27002 for Cloud Services. This draft is under development and is meant to replace ISO/IEC 27017:2015. © Copyright 2024, Cloud Security Alliance. All rights reserved. 24 1.4.2.1 A Simple Cloud Security Process Model While the implementation details, necessary controls, specific processes, and various reference architectures and design models vary greatly depending on the specific cloud implementation, there is a relatively straightforward, high-level process for managing cloud security. Identify necessary security and compliance requirements and any existing controls Select the CSP, service, and deployment models Define the architecture Assess the security controls Identify control gaps Design and implement controls to fill the gaps Assess the effectiveness of the controls Manage changes over time Each cloud project, even within the same CSP, may require unique configurations and technologies. Therefore, it is important to evaluate each project on its specific requirements and characteristics. For example, the security controls for an application deployed on pure IaaS in one CSP may look very different than a similar project that uses more PaaS from the same provider. The key is to identify requirements, design the architecture, and then identify the gaps based on the capabilities of the underlying cloud platform. That is why it is essential to understand the CSP and architecture before implementing controls to meet the security requirements. This is typically an iterative process. Understanding when to use native cloud service controls and when to implement the controls externally to close the gaps, is an important consideration that can have a significant impact on the overall security architecture. Summary & Areas of Critical Focus - Governance & Operations The 11 other domains which comprise the remainder of the CSA Guidance highlight areas of concern for cloud computing and are tuned to address both the strategic and tactical security “pain points” within a cloud environment, and can be applied to any combination of cloud service and deployment model. The domains are divided into two broad categories: governance and operations. The governance domains are broad and address strategic and policy issues within a cloud computing environment, while the operational domains focus on more tactical security concerns and implementation within the architecture. © Copyright 2024, Cloud Security Alliance. All rights reserved. 25 Title Description Cloud Computing Learn cloud computing concepts and architectures for cloud security Concepts & professionals. Topics include cloud models, security frameworks, Architectures cloud-native capabilities, abstraction, orchestration, and multi-tenancy, emphasizing agility, resiliency, and security. Cloud Governance Learn cloud governance with a focus on security, covering strategies like DevOps, DevSecOps, Zero Trust, and AI/ML. Understand frameworks, risk management, compliance, and establish effective governance structures like CCoE and cloud registries. Risk, Audit & Covers risk management, audit processes, and compliance in cloud Compliance environments. Learn cloud risk evaluation, compliance requirements, laws, and audit processes. Topics include compliance inheritance and leveraging CSP compliance for regulatory standards. Organization Covers managing and securing cloud environments with major CSPs, Management focusing on organizational hierarchy, IAM, hybrid/multi-cloud security, and Zero Trust strategies. Learn to implement cohesive security controls and manage diverse cloud infrastructures. Identity and Access Covers Identity and Access Management (IAM) in cloud environments, Management focusing on federation, strong authentication, and authorization. Learners will explore advanced IAM models, Zero Trust strategies, and automation to enhance cloud security and compliance. Security Monitoring Covers cloud security monitoring challenges and solutions, including cloud telemetry, logs, hybrid/multi-cloud setups, and advanced monitoring tools. Topics include the SSRM, log storage, canaries, honey tokens, and the role of GenAI in enhancing cloud security. Infrastructure and Covers managing and securing cloud infrastructure, including secure Networking architecture design, SDNs, IaC, and secure cloud connectivity. It emphasizes Zero Trust, SASE, container security, and integrated security measures to protect cloud assets. Cloud Workload Covers securing cloud workloads, including VMs, containers, serverless Security functions, PaaS, and AI. Learn to secure VM images, manage container vulnerabilities, and implement encryption, access controls, runtime protection, and IAM best practices. Data Security Covers data security in cloud environments, focusing on data classification, encryption, access controls, and various cloud storage types. It addresses securing data at rest, in transit, and in use, along with AI system security and future data security technologies. Application Security Learn cloud application security, focusing on protecting apps from external threats. Learn about SDLC, threat modeling, secure coding, and testing. Topics include IaC, DevOps, third-party libraries, and emerging © Copyright 2024, Cloud Security Alliance. All rights reserved. 26 cloud security technologies. Incident Response & Covers incident response and resilience in cloud environments, crucial for Resilience organizational security. Learn CIR strategies, tools, and practices based on CSA and NIST guidelines. Topics include preparation, detection, containment, recovery, and resilience strategies. Related Technology Covers cloud security strategies, focusing on Zero Trust, AI integration, & Strategies and Threat and Vulnerability Management. Learn to secure cloud apps, systems, and data through multi-factor authentication, encryption, AI threat detection, and continuous monitoring. Table 1: List of Security Guidance Domains Recommendations Understand the differences between cloud computing and how abstraction and orchestration impact security. Become familiar with the NIST model for cloud computing and the CSA reference architecture. Use the SSRM tool to apportion and place responsibility and accountability/obligations for security between the CSC and CSP. Use tools and documents like the CSA CAIQ to evaluate and compare cloud providers. Cloud providers should document their security controls and features and publish them using tools like the CSA CAIQ. Use tools like the CSA CCM to assess and document cloud project security and compliance requirements and controls, as well as who is responsible for each. Use a cloud security process model to select providers, design architectures, identify control gaps, and implement security and compliance controls. Additional Guidance CCSK PrepKit | CSA Cloud Security Alliance Glossary | CSA CSA Cloud Controls Matrix (CCM) | CSA CCM-Lite and CAIQ-Lite | CSA CCM v4 Implementation Guidelines | CSA CSA Enterprise Architecture Reference Guide | CSA Enterprise Architecture to CCM Shared Responsibility Model | CSA © Copyright 2024, Cloud Security Alliance. All rights reserved. 27 Domain 2: Cloud Governance and Strategies This domain focuses on cloud governance with an emphasis on the role of security. Governance is based upon a framework of policies, procedures, and controls that are designed to promote transparency and accountability to defined standards. Strong governance practices address strategic guidance, risk management and mitigation, compliance monitoring and remediation, budget allocation and cost controls. IT governance ensures that information and related technology support and enable the enterprise strategy and the achievement of enterprise objectives. ISACA22 defines governance as: "The method by which an enterprise evaluates stakeholder needs, conditions and options to determine balanced, agreed-upon enterprise objectives to be achieved. It involves setting direction through prioritization, decision making and monitoring performance and compliance against the agreed-upon direction and objectives.” Organizations can follow various and industry-specific governance standards and frameworks23 to enhance their governance practices. For example, the ISO/IEC 38500:2024 standard provides guidance on the governance of IT for organizations. ISACA COBIT framework offers a comprehensive guide for the governance and management of enterprise IT. For more information on governance standards: ISO/IEC 38500:2024 - Information Technology - Governance of IT for the Organization ISACA - COBIT - A Business Framework for the Governance and Management of Enterprise IT ISO/IEC 27014:2020 - Information Technology - Security Techniques - Governance of Information Security The Open Group Cloud Computing Governance Framework Here are some examples of laws and regulations that affect IT governance requirements: Gramm-Leach-Bliley Act (GLBA) Sarbanes-Oxley Act(SOX) The Health Insurance Portability and Accountability Act (HIPAA) General Data Protection Regulation (GDPR) 22 ISACA. (2024) Glossary - Governance 23 Frameworks are discussed in detail in 2.3 The Governance Hierarchy © Copyright 2024, Cloud Security Alliance. All rights reserved. 28 Learning Objectives In this domain, you will learn to: Identify the purpose of cloud governance. Define the governance hierarchy in cloud governance. Explore key strategies and concepts affecting governance in cloud computing. 2.1 Cloud Governance Cloud computing’s multi-tenancy nature, shared responsibility, redistribution of sensitive data, hosting of critical applications and infrastructure, security, and privacy concerns require effective governance to manage. Compliance is another major concern when storing data in the cloud, with various regulations, jurisdictions, security, and privacy requirements. Without a sound governance approach, security, financial, and operational risks associated with cloud operations can exponentially grow and make the cloud an insensible option for businesses. One of the primary drivers for cloud adoption is cost efficiency and speed to market. Many organizations perceive cloud computing as a way to achieve cost savings by shifting away from a capital expenditure data center model to an operational expenditure model (e.g., pay-as-you-go and subscription-based). As a result, a common migration strategy is to "lift and shift" existing applications and infrastructure to the cloud. Governance of security and privacy is critical in migrations like this since the shift to a new technology platform can introduce new technical risks, even (and especially) if the architecture stays the same. Furthermore, the application now has shared responsibilities with a cloud service provider (CSP) in the picture. Strategic innovation is another significant driver of cloud adoption. Many organizations view software as a strategic asset that can provide a competitive advantage. Cloud offers the ability to rapidly develop and deploy software, enabling organizations to quickly bring new products and services to market. However, from a governance perspective, managing rapid change from accelerated deployments introduces risks such as misconfigurations and software supply chain hazards. It is crucial to have robust secure-by-design processes to ensure that software development, testing, and deployment in the cloud are secure and reliable. Key takeaways from this discussion include: Cloud adoption is driven by factors including cost savings, operational expenses models, the objectives of the organization, and desire to achieve strategic innovation. Governance considerations in cloud adoption include managing information risk (data, applications, host operating systems, network, and supply chain), and physical risk, to acceptable levels (known as risk appetite). This is done by evaluating whether the IT objectives are aligned © Copyright 2024, Cloud Security Alliance. All rights reserved. 29 with business objectives, and by ensuring compliance with legislative and regulatory requirements, including privacy obligations. Organizations should tailor their migration strategies to align with their specific business objectives, ensuring that they choose the right cloud services and implement appropriate governance measures. 2.1.1 Cloud Adoption & Governance There are two primary ways cloud affects security governance: 1. The introduction of the Shared Responsibility Mode (SRM). Security governance responsibilities are now shared between the CSP and the CSC. To further complicate matters, in some cases, third-party service providers are introduced into the supply chain, each bearing their own security risks. Even if some of the responsibilities are offloaded to such a third party, the accountability remains with either the CSP or CSC. 2. The technical and operational differences created by the inherent nature of cloud computing. Before the cloud, IT security governance relied extensively on the inherent nature of operating primarily within data centers. Data centers have limited resources – there is only so much space, computers, networking, etc. – that are in relatively isolated physical environments. The organization structures, policies, and controls are all aligned around the resource scarcity of these facilities. Public cloud is the complete opposite. While cloud providers do not have infinite capacity, it is in their interest to always have enough capacity for their customers’ requirements. Cloud is decentralized and different teams can provision entire stacks of resources with a login and credit card, none of which will be under any kind of central management without effective governance controls. Cloud also fundamentally changes how we manage those resources. While resources can be decentralized, in a public cloud, the core management and administrative interfaces are unified and open to the Internet. There is no physical network perimeter and anyone with the right credentials can access the management plane and restructure the entire virtual infrastructure. This combination of decentralized usage, with a unified management plane that is open to the Internet, requires new, cloud-specific governance approaches. In conclusion, the cloud revolutionizes IT governance by decentralizing infrastructure management, providing unified administrative access, and enabling access to resources. Organizations must embrace these changes while ensuring security and control to fully leverage the benefits of cloud computing. 2.1.2 Cloud Governance Complexities As organizations increasingly adopt cloud services, they face unique governance challenges due to new business models, technologies, and management approaches. These challenges require organizations to update their governance frameworks to fit the cloud environment. Common considerations across Paas, © Copyright 2024, Cloud Security Alliance. All rights reserved. 30 SaaS, and IaaS include control and accountability, legal and regulatory compliance, and the relationship between CSPs and Cloud Service Consumers (CSCs). This section lists these considerations, highlighting the challenges as well as governance adjustments needed to manage cloud environments effectively. The following considerations outline the key governance challenges and necessary adjustments organizations must address when managing cloud environments: Control and Accountability Cloud might impose a loss of direct control over the IT infrastructure, forcing an organization to adopt a new governance framework and processes. Using cloud solutions does not necessarily mean outsourcing the accountability of controls to a third or fourth party. Cloud uses a number of different SRMs, which vary depending on the CSP and the technology stack. In turn, this requires a clear allocation of controls and responsibilities between the cloud service provider and the customer. CSCs have to rely more on assessment activities rather than actual testing. Legal and Regulatory Compliance Cloud services and data may span multiple jurisdictions, forcing customers to comply with more laws and regulations, especially for privacy. Data ownership rights and classification, as well as privacy control, might not be intuitively clear and may need careful examination. Visibility and Transparency Visibility and transparency into some cloud services can be challenging. Customization and Standardization CSPs may have a standard offering that cannot be customized according to a CSC’s specific requirements. CSPs might demonstrate different levels of maturity, and variety of services, licenses, and models, which complicates adoption of a one-size-fits-all cloud policy. Governance Complexity Cloud services are often built on a chain of CSPs, which makes scoping of governance activities challenging (e.g., a SaaS provider that is running on the infrastructure of another IaaS provider). © Copyright 2024, Cloud Security Alliance. All rights reserved. 31 Hybrid cloud models can complicate governance due to the complexities of producing clear boundaries between CSP and CSC responsibilities. CSP and CSC Dynamics CSPs may change rapidly, which has to be accounted for in governance models. Utilization of the cloud services may require additional skills that may not currently be present in the CSC, such as cloud auditing skills or cloud security skills, as well as knowledge of cloud-oriented security tools. The following figure outlines the specific complexities associated with different cloud service models, highlighting unique governance challenges and responsibilities for each model. Figure 7: Service Model Specific Complexities Effective cloud governance requires a flexible and robust strategy to address the unique challenges of IaaS, PaaS, and SaaS models. By understanding and managing these complexities, organizations can ensure security, compliance, and operational efficiency in their cloud environments. © Copyright 2024, Cloud Security Alliance. All rights reserved. 32 2.1.2.1 Cloud Governance Complexities: Deployment Models Moving forward, it's also essential to consider the governance complexities associated with different cloud deployment models. The following section explores these deployment models, highlighting unique governance challenges and responsibilities for each. Figure 8: Deployment Model Specific Complexities Public cloud: Public cloud is the most popular cloud deployment model, offering standard services to all customers. Providers typically resist customization requests, complicating governance as they manage their own infrastructure, services, and employees. Governance challenges arise from customer configurations, both initially and over time. Public cloud relies on multi-tenancy, which brings governance challenges like segmentation and isolation. This often limits actions such as security scanning or penetration testing and reduces visibility into the infrastructure. These challenges require new governance approaches, using vendor risk management, service level agreements (SLAs), third-party audits, and compliance reports.The effectiveness of this new approach will be measured based on the cloud consumer’s ability to mitigate the unique risks that cloud computing introduces. Private cloud: Private clouds can be owned, managed, or hosted by the organization or a third party. Governance of self-managed private clouds is similar to traditional IT governance but must also address cloud-specific issues like attack vectors, multi-tenancy, and automation. Governance of private clouds © Copyright 2024, Cloud Security Alliance. All rights reserved. 33 that are managed by third parties is the closest to traditional outsourcing models we already know. Governance challenges include understanding the shared responsibility matrix, setting SLAs, and building third-party monitoring capabilities to track policy breaches and insider threats. A major challenge is keeping the platform updated with the latest services, requiring special attention. Hybrid cloud: Hybrid cloud services combine private and public cloud models. They can be implemented in various ways, complicating policy guidelines and SRMs. Governance challenges include aligning SLAs and responsibilities between provider and customer, protecting internal perimeters, scaling security configurations, and addressing skill gaps in cloud security and maturity. Community cloud: Community cloud refers to a range of services managed and hosted by third parties, shared by multiple organizations but not fully public, reducing multi-tenancy challenges. Governance challenges include identifying stakeholders, building the correct SRM, and focusing on relationships and risks among organizations using the same community cloud. 2.2 Effective Cloud Governance Effective cloud governance involves establishing a robust framework and set of policies to ensure effective, secure and compliant usage of cloud resources. It requires the implementation of a strong control framework and policies for secure, compliant, and efficient management of cloud resources. This includes: Defining roles and responsibilities Establishing a Cloud Center of Excellence (CCoE) or similar Conducting requirements gathering Risk-based planning Management of risks and remediations Classifying data and digital assets Complying with legal and regulatory requirements Maintaining a cloud registry24 Establishing a governance hierarchy25 Leveraging cloud-specific security frameworks Defining cloud security policies Setting control objectives and specifying control specifications By implementing these components, organizations can maximize the benefits of cloud computing while mitigating potential risks. Below we explore some key components of effective cloud governance. 24 Additional details provided later in this section - Domain 2: Cloud Governance. 25 Additional details provided later in this section - Domain 2: Cloud Governance. © Copyright 2024, Cloud Security Alliance. All rights reserved. 34 2.2.1 Cloud Governance Implementation Models Cloud Center of Excellence (CCoE) and Cloud Advisory Council (CAC) models are widely adopted approaches for implementing effective cloud governance. The CCoE includes working members and evangelists. The CAC provides executive sponsorship and endorsement. More specifically: A CCoE is a centralized team or department that provides guidance, best practices, and support to the rest of the organization regarding cloud adoption and usage. The CCoE helps ensure consistency, standardization, and alignment with the CSC’s goals and objectives. The CAC can include a group of senior leaders from IT, risk management, compliance, security, and general business functions that are responsible for setting the vision and direction of the CSC’s cloud strategy and operating plan. The CAC is not covered in depth here but is important to be aware of. CCoE and CAC are recommended components of IT governance and security within the CSC. They serve as a centralized hub, responsible for leading cloud initiatives and driving strategic, secure, compliant, and effective cloud adoption. Not all CSCs use the same terminology, but from a functional standpoint, these structures highlight the key elements required for effective cloud governance. 2.2.1.1 The Cloud Center of Excellence One of the key functions of the CCoE is to provide strategic guidance. It ensures that cloud initiatives are aligned with the CSC’s overall business objectives. By doing so, the CCoE ensures that cloud adoption supports the CSC’s direction and contributes to its success. The CCoE also develops and enforces a governance framework for cloud usage. This includes creating policies and standards that comply with external regulations and internal best practices. The CCoE is responsible for managing risks, ensuring data privacy and security, and maintaining compliance in the cloud environment. The CCoE disseminates knowledge regarding cloud technologies and security measures. It provides training opportunities and resources to other departments, promoting a consistent level of cloud proficiency across the organization. This ensures that employees have the necessary skills and knowledge to leverage cloud services effectively and securely. Amongst those responsibilities, security is a primary focus of the CCoE. It takes the lead in embedding security into the cloud infrastructure, ensuring that cloud deployments are secure by design. The CCoE ensures that the CSC’s security and privacy requirements are met and responds to the evolving threat landscape. The CCoE fosters cross-functional collaboration which involves various departments, such as (but not limited to) IT, security, compliance, and finance. This collaborative approach ensures that cloud decisions are made holistically, considering cost, security, compliance, and business needs. The CCoE also fosters innovation and adaptability. It encourages the exploration of new cloud services and technologies and promotes a culture of innovation within the organization. At the same time, the CCoE remains adaptable to changes in technology and business environments, ensuring that the CSC can effectively leverage the latest advancements in cloud technology. © Copyright 2024, Cloud Security Alliance. All rights reserved. 35 Ultimately a CCoE is useful for CSCs seeking to leverage cloud technologies effectively and securely. They go beyond technology and focus on aligning cloud adoption with business strategy, while ensuring governance, security, and compliance in the cloud environment. The following figure illustrates the key roles within a CCoE. Figure 9: Key Roles in CCoE 2.2.2 Security Champions In addition to having a CCoE, CSCs can also appoint Security Champions within business units including compliance, enterprise risk, legal, human resource, finance, and IT. These are individuals who understand the importance of cloud security and therefore can act as advocates for security, helping drive the implementation of security best practices and controls. Security Champions should be appointed from within a team and have a hands-on role. They are typically not members of the security organization, but rather members of their own teams. This distinction allows them to focus on practical security implementation within their specific team dynamics. It is essential to differentiate the role of Security Champions from that of the Business Information Security Officer (BISO), Chief Information Security Officer (CISO) or Information Security Officer (ISO). For example, in the DevOps team, the ideal candidate for the role of Security Champion is typically a developer, system administrator, or a DevOps or Platform Engineer who is already part of the team. This familiarity with the team dynamics and technical skills allows them to effectively advocate for security from the inside. They have the knowledge and expertise to understand the specific security challenges and solutions in cloud services and DevOps practices. © Copyright 2024, Cloud Security Alliance. All rights reserved. 36 The role of Security Champions is crucial in the integration of security practices within the DevSecOps process. Acting as liaisons between security teams and development teams, they play a pivotal role in decentralizing responsibilities. By advocating for security within their teams, Security Champions promote a security culture within cloud and DevOps/Site Reliability Engineering (SRE) teams. Security Champions are more common in development-related teams but can also play an important role in other business units. To cultivate the skills and interests of Security Champions, it is important to provide them with engaging and interactive security training. Workshops on ethical hacking, for example, can be an effective way to enhance their practical security skills. It is important, however, not to push Security Champions to become full-time security experts. They are developers and administrators who receive additional security training to serve as liaisons and experts within their teams. The goal of empowering Security Champions is to enable them to play an advisory role rather than burdening them with additional duties better served by dedicated security teams. It is important to avoid burnout. By empowering Security Champions, CSCs can effectively bridge the gap between security and development, fostering a culture of security within cloud and DevOps teams. In summary, Security Champions are essential in promoting a security culture within cloud, DevOps teams and business teams. By empowering them with the right mix of experience, training, and authority, CSCs can effectively integrate security practices within the development process. This ultimately leads to improved security outcomes. 2.3 The Governance Hierarchy A key aspect of cloud governance is the establishment of a governance hierarchy. This involves defining decision-making processes and escalation paths for cloud-related issu

Security Guidance v5 2024 PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue