CCSK Study Guide.pdf

Certificate of Cloud Security Knowledge Official Study Guide © 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 Rick Doten Peter van Eijk Moshe Ferber Nick Kael Rich Mogull Mike Rothman Graham Thompson Contributors Jackie Donnelly Larry Hughes CSA Global Staff Judy Bagwell Daniele Catteddu Ryan Gifford Claire Lehnert Stephen Lumpe Hannah Rock Andy Ruth Anna Schorr Stephen Smith Adriano Sverko John Yeoh © Copyright 2024, Cloud Security Alliance. All rights reserved. 3 Table of Contents Acknowledgments........................................................................................................................................................3 Developers............................................................................................................................................................. 3 Editors.....................................................................................................................................................................3 Reviewers............................................................................................................................................................... 3 Staff........................................................................................................................................................................ 3 Table of Contents.........................................................................................................................................................4 Introduction to the CCSK v5...................................................................................................................................... 9 Domain 1: Cloud Computing Concepts & Architectures............................................................................. 10 Learning Objectives............................................................................................................................................ 10 1.1 Defining Cloud Computing............................................................................................................................. 11 1.2 Cloud Computing Models............................................................................................................................. 12 1.3 Cloud Security Scope, Responsibilities, & Models....................................................................................18 Domain 2: Cloud Governance and Strategies............................................................................................... 20 Learning Objectives........................................................................................................................................... 20 2.1. Cloud Governance....................................................................................................................................... 20 2.2 The Governance Hierarchy......................................................................................................................... 22 2.3 Cloud Security Frameworks........................................................................................................................24 2.4 Policies...........................................................................................................................................................26 Domain 3: Risk, Audit and Compliance............................................................................................................ 27 Learning Objectives........................................................................................................................................... 27 3.1. Cloud Risk Management..............................................................................................................................27 3.2 Compliance & Audit..................................................................................................................................... 32 3.3 Governance, Risk, Compliance Tools & Technologies............................................................................ 37 Domain 4: Organization Management.............................................................................................................39 Introduction......................................................................................................................................................... 39 Learning Objectives........................................................................................................................................... 39 4.1 Organization Hierarchy Models...................................................................................................................39 4.2 Managing Organization-Level Security Within a Provider.....................................................................42 4.3 Considerations for Hybrid & Multi-Cloud Deployments........................................................................44 Domain 5: Identity and Access Management................................................................................................ 47 Introduction......................................................................................................................................................... 47 Learning Objectives........................................................................................................................................... 47 5.1 How IAM Is Different in the Cloud.............................................................................................................. 48 5.2 Fundamental Terms..................................................................................................................................... 48 5.3 Federation..................................................................................................................................................... 50 5.4 Strong Authentication & Authorization.....................................................................................................53 Domain 6: Security Monitoring..........................................................................................................................55 Introduction......................................................................................................................................................... 55 Learning Objectives........................................................................................................................................... 55 © Copyright 2024, Cloud Security Alliance. All rights reserved. 4 6.1 Cloud Monitoring...........................................................................................................................................55 6.2 Beyond Logs - Posture Management....................................................................................................... 56 6.3 Cloud Telemetry Sources........................................................................................................................... 56 6.4 Collection Architectures............................................................................................................................. 59 6.5 AI for Security Monitoring........................................................................................................................... 61 Domain 7: Infrastructure & Networking..........................................................................................................62 Introduction......................................................................................................................................................... 62 Learning Objectives........................................................................................................................................... 62 7.1 Cloud Infrastructure Security.......................................................................................................................62 7.2 Cloud Network Fundamentals.................................................................................................................... 65 7.3 Cloud Network Security & Secure Architectures.................................................................................... 68 7.4 Infrastructure as Code................................................................................................................................. 69 7.5 Zero Trust for Cloud Infrastructure & Networks...................................................................................... 70 7.6 Secure Access Service Edge........................................................................................................................71 Domain 8: Cloud Workload Security................................................................................................................ 72 Introduction......................................................................................................................................................... 72 Learning Objectives........................................................................................................................................... 72 8.1 Introduction to Cloud Workload Security.................................................................................................. 72 8.2 Securing Virtual Machines.......................................................................................................................... 73 8.3 Securing Containers.................................................................................................................................... 77 8.4 Securing Serverless and Function as a Service........................................................................................81 8.5 Securing AI Workloads................................................................................................................................ 84 Domain 9: Data Security...................................................................................................................................... 88 Introduction.........................................................................................................................................................88 Learning Objectives........................................................................................................................................... 88 9.1 Primer on Cloud Storage............................................................................................................................. 88 9.2 Data Security Tools and Techniques.........................................................................................................90 9.3 Cloud Data Encryption at Rest...................................................................................................................92 9.4 Data Security Posture Management.........................................................................................................97 9.5 Object Storage Security............................................................................................................................. 97 9.6 Data Security for Artificial Intelligence.....................................................................................................97 Domain 10: Application Security....................................................................................................................... 99 Introduction.........................................................................................................................................................99 Learning Objectives......................................................................................................................................... 100 10.1 Secure Development Lifecycle................................................................................................................100 10.2 Architecture’s Role in Secure Cloud Applications................................................................................ 103 10.3 Identity & Access Management and Application Security..................................................................104 10.4 Dev Ops & DevSecOps............................................................................................................................ 106 Domain 11: Incident Response & Resilience................................................................................................... 110 Introduction.........................................................................................................................................................110 Learning Objectives...........................................................................................................................................110 11.1 Incident Response..........................................................................................................................................111 11.2 Preparation................................................................................................................................................... 112 © Copyright 2024, Cloud Security Alliance. All rights reserved. 5 11.3 Detection & Analysis................................................................................................................................... 114 11.4 Containment, Eradication, & Recovery.....................................................................................................117 11.5 Post Incident Analysis................................................................................................................................. 118 Domain 12: Related Technologies & Strategies............................................................................................................................................................120 Introduction........................................................................................................................................................120 Learning Objectives..........................................................................................................................................120 12.1 Zero Trust.....................................................................................................................................................120 12.2 Artificial Intelligence.................................................................................................................................. 124 Next Steps.......................................................................................................................................................... 127 © Copyright 2024, Cloud Security Alliance. All rights reserved. 6 Introduction to the CCSK v5 Welcome to the fifth version of the Cloud Security Alliance’s Certificate of Cloud Security Knowledge (CCSK). 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 CCSK is built on Cloud Security Allaince’s Security Guidance for Critical Areas of Focus in Cloud Computing v5, 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. 7 Domain 1: Cloud Computing Concepts & Architectures This domain provides the conceptual framework for the rest of the Cloud Security Alliance (CSA) Certificate of Cloud Security Knowledge (CCSK) Study Guide. 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 offers agility, resiliency, security, and economic benefits, but these are only realized with proper understanding and adoption of cloud models. Simply rehosting applications to a Cloud Service Provider (CSP) without changes (“lift-and-shift”) often fails to deliver the expected benefits and can increase costs. Effective cloud computing relies on understanding and utilizing cloud-native capabilities and services. This domain provides the foundation for this guide, offering a common language and understanding of cloud computing for Cloud Service Customers (CSC1). It highlights the differences between cloud and traditional computing and guides security professionals and stakeholders in adopting cloud-native approaches for better security. The Cloud Security Alliance aims to harmonize existing models, particularly NIST SP 800-145, ISO/IEC 22123-1:2023, and ISO/IEC 22123-2:2023, focusing on key security considerations for cloud professionals. 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 The acronym CSC is used interchangeably to mean any cloud service customer, cloud service consumer, or cloud service client. © Copyright 2024, Cloud Security Alliance. All rights reserved. 8 1.1 Defining Cloud Computing Cloud computing manages shared resources through abstraction, enabling rapid orchestration, provisioning, scaling, and decommissioning. It provides an on-demand utility model with benefits like 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), the International Organization for Standardization (ISO), and the International Electrotechnical Commission (IEC): NIST SP 800-145 defines cloud computing 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.”2 ISO/IEC 22123-1:2023 defines cloud computing as: “[A] paradigm for enabling network access to a scalable and elastic pool of shareable physical or virtual resources with self-service provisioning3 and administration on-demand.”4 Both quotes lead to the same idea: The cloud pools resources like processors, memory, and storage using virtualization. The CSC requests needed resources, uses them over the network, and releases them back into the pool when finished. 1.1.1 Abstraction & Orchestration Cloud environments rely on abstraction and orchestration to manage resources. For example, abstraction involves creating virtual machines (VM) from physical servers, while orchestration automates and coordinates the provisioning of these VMs and their networking to CSCs. Clouds are multi-tenant, with multiple CSCs sharing resource pools while being segregated and isolated for confidentiality and integrity. Segregation and isolation ensure that CSCs cannot see or modify each other’s assets. CSPs ensure fair resource use and availability by measuring and constraining overuse. 2 NIST. (2011) SP 800-145: The NIST Definition of Cloud Computing 3 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. 4 ISO/IEC. (2023) Information Technology - Cloud Computing - Part 1: Vocabulary. © Copyright 2024, Cloud Security Alliance. All rights reserved. 9 1.2 Cloud Computing Models CSA uses the NIST SP 800-145 model for cloud computing as it is the standard for defining cloud computing.5 CSA also endorses the more in-depth ISO/IEC models 22123-1:2023 and 22123-2:2023, which also serve as a reference model. Throughout this domain, we reference both. NIST describes cloud computing based on five essential characteristics, three cloud service models, and four cloud deployment models. We summarize them below. 6 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 set cloud computing apart from traditional hosting services or 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. 5 CSA has chosen to align with the NIST 800-145 definition of cloud computing to bring consensus around a common language and focus on use cases, rather than on semantics. This study guide is intended to be broadly applicable to organizations globally. While NIST is a U.S. government organization, the selection of this reference model should not be interpreted as excluding other points of view or geographies. 6 Depiction of the NIST Model of Cloud Computing © Copyright 2024, Cloud Security Alliance. All rights reserved. 10 Resource Pooling: Cloud computing pools various physical and virtual resources to serve multiple CSCs through 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 while using heterogeneous thin client platforms (e.g., servers, mobile phones, laptops, IoT devices, and tablets). Rapid Elasticity: Resources are rapidly and elastically provisioned, in some cases automatically. To the CSC, the provisioned capabilities often appear unlimited and can be purchased in any quantity at any time. 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 (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. These categories are flexible; some cloud services span these tiers, while others don't fit a single model. It's a descriptive tool, not a rigid framework. Cloud technologies evolve rapidly, making some reference models obsolete. This section provides fundamentals to help security professionals understand emerging models. We recommend ISO/IEC 22123 and NIST 500-292 for in-depth reference architectures. Both approaches are valid, but since the NIST model is more concise and broadly used, it is the definition predominantly used in CSA research. Cloud computing can be viewed as a stack: Software as a Service (SaaS) on Platform as a Service (PaaS) on Infrastructure as a Service (IaaS). While this is not representative of all real-world deployments, it is a useful model. 1.2.2.1 Infrastructure as a Service IaaS offers access to a resource pool of fundamental computing infrastructure, such as network, or storage. In IaaS the CSC is responsible for managing the underlying virtual infrastructure, such as VMs, © Copyright 2024, Cloud Security Alliance. All rights reserved. 11 networking, storage, and running applications. IaaS relies on physical infrastructure, abstracted and orchestrated into resource pools. Abstraction through virtualization frees resources from physical constraints, while orchestration uses APIs to tie these resources together and deliver them to CSCs. APIs facilitate orchestration and are often accessible through web-based interfaces, forming the cloud management plane. This management plane allows CSCs to manage resources such as VMs and networks. Security-wise, it differs from on-premises protection, as management interfaces are network-accessible, posing risks if compromised. 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 hypervisors 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.2.2.2 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 with IaaS is that, with PaaS, the CSC does not manage the underlying servers. © Copyright 2024, Cloud Security Alliance. All rights reserved. 12 Often, PaaS is built on IaaS, where integration, persistence, and middleware layers are orchestrated and accessed through APIs. For example, Database as a Service (DBaaS) lets CSCs manage databases via API or web console without handling the underlying infrastructure. In PaaS, CSCs see only the platform, not the infrastructure. The database service scales with use, removing the need for CSCs to manage and patch servers, networking, or patches. The following is a simplified architecture diagram that shows a PaaS running on top of an IaaS architecture. Figure 3: Simplified Architecture of a PaaS Built on IaaS PaaS can be a custom-built, stand-alone architecture, not necessarily on IaaS. CSCs manage the platform, not the underlying infrastructure. An example is a custom AI and ML service for AI development tools, MLOps, and AI lifecycle management. 1.2.2.3 Software as a Service SaaS services are complete applications, encompassing all the architectural complexities typical of any large software platform. It is managed by the CSP. SaaS CSPs often build on top of IaaS and PaaS due to the increased agility, resilience, and economic benefits. CSCs access it using a web browser, mobile application, APIs, or lightweight client applications. In this model, the CSC only worries about the application's configuration, not the underlying resources. © Copyright 2024, Cloud Security Alliance. All rights reserved. 13 SaaS services typically include an application/logic layer, data storage, APIs, and presentation layers supporting web browsers, mobile apps, and Internet API access. The architecture diagram is generalized from a real SaaS platform. Figure 4: Simplified Architecture of a SaaS Platform Built on PaaS and IaaS 1.2.3 Cloud Deployment Models NIST and ISO/IEC use the same four cloud deployment models; these define 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, and 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 bursting for load balancing between clouds). © Copyright 2024, Cloud Security Alliance. All rights reserved. 14 While these are the official definitions, the common use of these terms has shifted. In particular, private cloud is now being used more often to just denote a private datacenter, independent of the level of automation in provisioning that it offers, and hybrid cloud mostly refers to where such data centers are combined with one or more public cloud solutions. 1.2.4 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) Information Technology Operation Services (ITOS) — Information Technology 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 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. © Copyright 2024, Cloud Security Alliance. All rights reserved. 15 1.3 Cloud Security Scope, Responsibilities, & Models In cloud computing, security is a joint effort known as “shared responsibility.” CSPs handle the security “of the cloud,” covering infrastructure, hardware, and network. CSCs manage security “in the cloud,” and are responsible for their deployments. Responsibilities vary with service models. 1.3.1 Shared Security Responsibility Model The delineation of responsibilities differs for IaaS, PaaS, and SaaS, and often between different CSPs. CSCS must 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. At a high level, security responsibility maps to the degree of control a given actor has over the architecture stack. SaaS: The CSP handles most security, while the CSC manages authorization and entitlements. Example: The CSP manages perimeter security and logging, and the CSC manages user permissions. PaaS: The CSP secures the platform, and the CSC secures its implementations. Example: The CSP handles patching and core configuration, and the CSC manages database security features and authentication. IaaS: The CSP handles foundational security, and the CSC manages all built infrastructure. Example: The CSP monitors the perimeter, and the CSC defines virtual network security. Roles become complex with cloud brokers and intermediaries. Knowing where a CSP's responsibility ends and its CSC's begins is crucial. CSCs must understand their obligations, especially in configuration and management, to ensure security policies align with data sensitivity. © Copyright 2024, Cloud Security Alliance. All rights reserved. 16 Figure 6: Shared Security Responsibility Model7 Effective cloud security requires understanding the division of responsibility in cloud environments. Knowing who is responsible is crucial, allowing CSCs to fill control gaps or consider alternative CSPs. Direct security control is highest for IaaS and lower for SaaS. To ensure a clear allocation of security responsibilities in the cloud, we recommend the following: CSPs should document security controls and CSC features, and design and implement them properly. Often such a document is called a “shared security responsibility matrix.” CSCs should create a roles-and-responsibilities matrix to track security responsibilities and ensure compliance alignment. CSA provides tools to help meet these requirements: The Consensus Assessments Initiative Questionnaire (CAIQ) is a standard template for CSPs to document their security and compliance controls. The Cloud Controls Matrix (CCM), discussed in more detail in Domain 2, lists cloud security controls and maps them to multiple security and compliance standards. The CCM can also be used to document security responsibilities. Both documents provide a comprehensive starting template and can be especially useful for ensuring compliance requirements are met. CISA. (2021) Cloud Security Technical Reference Architecture. 7 © Copyright 2024, Cloud Security Alliance. All rights reserved. 17 Domain 2: Cloud Governance and Strategies This domain focuses on cloud governance with an emphasis on the role of security. Enterprise governance plays a key role in an organization's success and helps in aligning the strategic, tactical, and operational capabilities of information and technology with the business objectives. ISACA8 defines governance as: "Governance ensures that stakeholder needs, conditions and options are evaluated to determine balanced, agreed-on enterprise objectives to be achieved; setting direction through prioritization and decision making; and monitoring performance and compliance against agreed-on direction and objectives." As information technology (IT) is moving from supporting back-office functions to becoming front and center of most organizations' strategy and operations, a comprehensive perspective on all stakeholder needs is required. This requires that IT and cloud decisions are embedded in the organization’s governance. 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, shared responsibility, distributed supply chains, legal and regulatory complexity, and security concerns require effective governance. Cost efficiency and speed to market are key drivers for cloud adoption. Organizations save costs by moving from Capital Expenditure (CapEx, or investments) to Operational Expense (OpEx, subscription) models, often using lift and shift strategies, which require strong security governance to manage new risks from more complex cloud architectures and shared service models. 8 ISACA. (2024) Glossary - Governance © Copyright 2024, Cloud Security Alliance. All rights reserved. 18 Strategic innovation drives cloud adoption as it enables rapid software development and deployment. However, accelerated deployment cycles introduce governance risks, such as misconfigurations, software supply chain issues, and potential compliance changes. Governance is required to balance between the requirement for speed and the need to control risks. There are two primary ways cloud affects security governance: 1. The introduction of the Shared Responsibilities Model. Security governance responsibilities are now shared between the cloud provider and the cloud customer. To complicate matters, third-party service providers are sometimes introduced into the security responsibility supply chain. Even if some of the responsibilities are offloaded to a third party, the accountability of the control remains with the cloud service provider (CSP) or cloud service customer (CSC). Compliance risk is always with the CSC. 2. The technical and operational differences are created by the inherent nature of cloud computing. This includes multi-tenancy, geography of data, and platform failover to other regions. Here are some of the complexities that effective cloud governance has to address: Cloud might impose a loss of direct control over the IT infrastructure, forcing an organization to adopt a new governance framework and process. Cloud services and data may span multiple jurisdictions, forcing customers to comply with more laws and regulations, especially privacy requirements. Visibility and transparency in some cloud services can be challenging. Using cloud solutions does not mean outsourcing the organizational accountability of its controls to a third or fourth party. Data ownership rights and classification as well as privacy control might not be intuitively clear and need careful examination. Most providers have a standard offering that cannot be customized according to all customer’s specific requirements. Cloud providers might demonstrate different levels of maturity and a variety of services, licenses, and models, which complicates the adoption of a one-size-fits-all cloud policy. Cloud services are often built on a chain of providers, which makes scoping governance activities challenging (e.g., a Software as a Service (SaaS) provider that is running on the infrastructure of an Infrastructure as a Service (IaaS) provider). Cloud services employ various shared responsibility models, which differ based on the provider and the technology stack. This necessitates a clear delineation of controls and responsibilities between the cloud service provider and the customer. Adding to the complexity of cloud governance, the shared responsibility model often involves multiple parties. These parties may include cloud platform integrators or brokers, software development companies for applications running on cloud services, different Development and Operations (DevOps) teams, and other stakeholders. Hybrid cloud models can complicate governance due to the complexities of producing clear boundaries between provider responsibilities and customer responsibilities. Cloud customers have to rely more on compliance and assessment activities rather than actual testing. This will depend on what layers fall into the customer's responsibility. The customer is still responsible for security testing applications in an IaaS model for example. Primarily the customers © Copyright 2024, Cloud Security Alliance. All rights reserved. 19 would have to rely on third-party security assessment reports and certifications of the CSP and understand the shared responsibilities that the customer has to abide by for the total compliance coverage. CPSs may change rapidly, which has to be accounted for in governance models. Utilization of cloud services may require additional skills that may or may not currently be present in the organization, such as cloud auditing skills or cloud security skills, as well as knowledge of cloud-oriented security tools. Effective cloud governance requires the implementation of a strong framework and policies for secure, compliant, and efficient management of cloud resources. Cloud governance includes: Defining roles and responsibilities Conducting requirements and information gathering Managing risks Classifying data and assets Complying with legal and regulatory requirements Maintaining a cloud registry Establishing a governance hierarchy Leveraging cloud-specific security frameworks The rest of this Study Guide introduces these topics in more detail and also gives insight into some developments that challenge historical assumptions on IT governance. DevOps and Development, Security, and Operations (DevSecOps) (see Domain 10) drive the automation of security controls, which changes organizational structures. Zero Trust (ZT) (see Domain 12) drives a fundamentally more comprehensive approach to things like network security, which requires policies to be defined on a different level. Artificial Intelligence (AI) and Machine Learning (ML) (Domain 12 and others) open up entirely new fields of applications for which there are few existing governance practices. 2.2 The Governance Hierarchy A key aspect of cloud governance is establishing a governance hierarchy and defining decision-making processes and escalation paths. This ensures appropriate decision levels and clear accountability. It’s important to use one or more Frameworks to set a road map for your program and security controls. This makes it easier to show compliance. At the top of the hierarchy is a Risk Framework, providing guidelines for evaluating cybersecurity risks. Examples include NIST 800-30, ISO 27005, CIS RAM, and FAIR. Next is the Program framework, which defines the components of your security program; examples include NIST Cybersecurity Framework (CSF), ISO 27001, or Control Objectives for Information and Related Technology (COBIT), and then there are Control Frameworks, which provide a list of technical and procedural controls to apply to the infrastructure; these include NIST 800-53, Center for Internet Security Critical Security Controls (CIS CSC), and Cloud Security Alliance Cloud Controls Matrix (CSA CCM). © Copyright 2024, Cloud Security Alliance. All rights reserved. 20 The output of these frameworks are tiers of governance documents that define specific structures and actions for your organization. These include: Policies outline an organization's security requirements, translating framework guidelines into actionable statements. They ensure adherence to regulatory and compliance requirements. Control Objectives, or Guidelines, more specific than policies, focus on desired security control outcomes to minimize risk and maintain a secure environment, for example, requiring multi factor authentication (MFA) for all cloud platform logins. They provide clear security goals for organizations. Control Specifications and Technical Standards or Guidance are technical implementations to meet control objectives. For example, a specification might require enabling MFA for user access and applying a technical policy to enforce it. Figure 7: Structured Security Governance Hierarchy 2.2.1 Aligning with Requirements, Standards, Best Practices, & Contractual Obligations To establish a robust governance framework, it is important to align with established standards, best practices, and contractual obligations. Understanding the contractual obligations of your CSP is crucial to knowing the shared security responsibilities between your organization and the CSP, as well as any specific security requirements outlined in the contract. Additionally, consider contractual obligations with customers and partners, as they may impact your cloud plans. Stay informed about current best practices. CSPs often provide recommended practices through their well-architected frameworks. While deviations may be necessary, these frameworks are valuable references for establishing a secure cloud environment. © Copyright 2024, Cloud Security Alliance. All rights reserved. 21 2.2.2 Consulting with Key Stakeholders for Cloud Security Strategy Alignment A non-exhaustive list of stakeholders to align with for cloud includes the IT department, security team, compliance and legal team, finance department, business unit leaders, development team, operations team, project management office, vendors and service providers, and end users. 2.3 Cloud Security Frameworks A cloud security framework organizes and prioritizes security control objectives to achieve desired security outcomes. Frameworks categorize these objectives, enabling a systematic approach to cloud security. Cloud-specific frameworks consider the unique characteristics of cloud computing, addressing aspects like on-demand resource allocation, shared responsibility models, and rapid elasticity. Using these frameworks ensures security programs align with cloud requirements and challenges. There are many frameworks relevant to cloud security. The major examples are the CSA Cloud Controls Matrix (CCM)9, ISO/IEC 27017:201510, BSI C511, NIST 800-5312, Payment Card Industry Security Standards Council (PCI SSC) Cloud Computing Guidelines13, NIST CSF V214, and the CSA Cloud Security Maturity Model (CSMM)15. For additional details about cloud frameworks, we recommend the Certificate of Cloud Auditing Knowledge (CCAK) course available through ISACA. 2.3.1 Cloud Controls Matrix An example of a cloud-specific framework is the CSA Cloud Controls Matrix v4 (CCM v4), which is a library of control objectives that structures 17 control domains. It offers comprehensive coverage of a wide array of security topics, ranging from governance and risk management to operational security and data privacy. This makes it a valuable resource for organizations looking to enhance their cloud security. One of the key strengths of the CCM is its alignment with leading standards, such as ISO/IEC 27001/27002, PCI Data Security Standard (DSS) (v3.2.1/v4.0), NIST, and so on. By harmonizing with 9 CSA. (2024) Cloud Controls Matrix (CCM) 10 ISO/IEC (2015) 27017:2015 - Information technology - Security techniques - Code of practice for information security controls based on ISO/IEC 27002 for cloud services. 11 BIS (2020) Federal Office for Information Security - Cloud computing C5 criteria catalogue. 12 NIST (2020) SP 800-53 Rev 5 - Security and Privacy Controls for Information Systems and Organizations. 13 PCI (2013) PCI Data Security Standard (PCI DSS) - Information Suppliment: PCI DSS Cloud Computing Guidelines. 14 NIST. (2024) The NIST Cybersecurity Framework (CSF) 2.0 15 CSA (2023) Publication Peer Review - Cloud Security Maturity Model 2023. © Copyright 2024, Cloud Security Alliance. All rights reserved. 22 these established frameworks, the CCM ensures that organizations can achieve compliance across multiple standards and regulations. The CCM is tailored to cloud environments, making it well-suited for securing multi-tenant, distributed, and dynamic cloud systems. The focus on the unique challenges of cloud computing sets it apart from more generic security frameworks like NIST CSF. Additionally, the CCM allows for control customization, enabling organizations to adapt the security controls to their specific cloud architectures, delivery models (IaaS, PaaS, SaaS), and compliance needs. Another key benefit of the CCM is its support for cloud governance. It assists organizations in establishing and maintaining a solid cloud governance program that effectively manages and oversees cloud risks. This is valuable in ensuring that cloud deployments are aligned with organizational objectives and comply with relevant regulations. The CCM is continuously updated to reflect the latest cloud security best practices. Organizations can rely on the CCM as a reliable and relevant resource for their cloud security needs by staying up to date. Based on the CCM, the Consensus Assessment Initiative Questionnaire (CAIQ) provides a checklist to evaluate controls. 2.3.2 CSA Security, Trust, Assurance, and Risk (STAR) Registry The Security, Trust, Assurance, and Risk (STAR) Registry is a publicly accessible registry that documents the security and privacy controls provided by popular cloud computing offerings. Cloud providers can submit completed CAIQ documents to the CSA STAR Registry. The CSA initiated this program to advance transparency and confidence in cloud services. The program offers a framework for CSPs to document their security practices and for CSCs to evaluate the security posture of cloud services. The CSA STAR program comprises two primary components: 1. CSA STAR Certification: This entails an independent third-party evaluation of a cloud service provider's security controls against the CSA Cloud Controls Matrix (CCM) and other recognized industry standards like ISO/IEC 27001. Achieving CSA STAR Certification indicates that a cloud service provider has implemented robust security measures and practices. 2. CSA STAR Attestation: Here, CSPs self-assess their security controls against the CSA CCM and publicly disclose the results of their assessments. This allows transparency into a provider's security posture and enables customers to make informed decisions about utilizing their services. By facilitating standardized security assessments and promoting transparency, the CSA STAR program empowers organizations to assess the security, privacy, and compliance practices of cloud service providers. This, in turn, helps them make risk-aware decisions when selecting and utilizing cloud services, fostering trust and reliability in the cloud industry. © Copyright 2024, Cloud Security Alliance. All rights reserved. 23 2.4 Policies Information security policies are crucial for establishing a strong security framework. They govern the protection of an organization's information assets, outline necessary control objectives, and should require business leadership sign-off to ensure alignment with strategic goals. There are several key examples of information security policies organizations commonly implement: The Information Security policy is a top-level policy defining how the information security program will be run. It ideally refers to other policies and documents, such as control objectives, rather than trying to include all the specific technical requirements. Additional policies underneath the core policy that define specific areas, such as Acceptable use, data protection, identity management, endpoint and mobile device protections, use of cloud services, third-party risk management, and so on. There are many online sources of security policy libraries and templates from sites such as SysAdmin, Audit, Network and Security (SANS), and CIS. © Copyright 2024, Cloud Security Alliance. All rights reserved. 24 Domain 3: Risk, Audit and Compliance This domain focuses on cloud security, risk, audit, and compliance. It covers evaluating cloud service providers and establishing cloud risk registries. It also discusses different types of compliance requirements and introduces tools and technologies to support cloud governance and risk management. Overall, it provides insights into managing the complex landscape of cloud computing risks and compliance. Learning Objectives In this domain, you will learn to: Define, categorize, and use tools to manage risk. Identify the regulatory and compliance constraints for which your cloud-based environment must undergo audits. Identify a set of technical and non-technical tools used when managing governance, risk, and compliance. 3.1. Cloud Risk Management Effective cloud risk management is mandatory in today's digital landscape, where organizations increasingly rely on cloud services. This section delves into the importance of understanding cloud risks and provides insights on establishing a cloud risk profile, assessing cloud service providers, maintaining a cloud risk register, and conducting risk assessments, threat intelligence, and threat modeling. 3.1.1 Cloud Risks Let’s start with an example. A company has a cloud storage bucket filled with personal information on customers. We call this an asset, which to an attacker (also known as a threat actor) is a target. One of the weaknesses of a cloud storage bucket is that it may be misconfigured. We call that a vulnerability, and to an attacker, this represents an attack vector. A risk is that the personal data in the bucket leaks out, and the company gets fined by a regulator. Another risk could be that, through some action, the data becomes unavailable or corrupted. © Copyright 2024, Cloud Security Alliance. All rights reserved. 25 A control or countermeasure is a way to reduce the risk. Typical controls here would be any policy that prevents these storage buckets from being accessible to the whole internet, or more specifically: the threat actor. Ideally, we’ll have enough controls to reduce the risk down to an acceptable level. This involves understanding what the important assets and threat actors are. This process is called threat modeling and is discussed in other places in this guidance, such as application security. Threat modeling, in a cloud world, starts with identifying the various places and cloud services where data is stored, and how data flows between them. See also CSA research16. The following examples show some of the most common risk factors and categories, both general and security risks. We also recommend reviewing the Cloud Security Alliance’s Top Threats17 research report. In the 2022 edition, the ‘Pandemic Eleven’, these were the top categories: Insufficient Identity, Credentials, Access, and Key Management Insecure Interfaces and APIs Misconfiguration and Inadequate Change Control Lack of Cloud Security Architecture and Strategy Insecure Software Development Unsecured Third-Party Resources System Vulnerabilities Accidental Cloud Data Disclosure Misconfiguration and Exploitation of Serverless and Container Workloads Organized Crime/Hackers/Advanced Persistent Threat (APT) Cloud Storage Data Exfiltration There are many other sources of cloud threat intelligence. Consult the CSA website for up-to-date information. Additionally, the MITRE ATT&CK®18 framework provides a comprehensive matrix of threat actor tactics. 3.1.2 Understanding Cloud Risk Management Risk management involves a structured approach to identifying, assessing, and addressing risks associated with cloud computing. The risk management and methodologies used in cloud computing are not different from the ones adopted in the on-premises world and in other technologies, what does change are some of the specific actions taken during the definition of the scope and environment and the risk evaluation and treatment process. The European Network and Information Security Agency (ENISA) Risk Management Process19 provides a framework that organizations can adapt to manage these risks effectively within their cloud environments. This process is designed to be integrated into an organization's broader operational processes, ensuring a broad approach to risk management. Here's an expansion on the key components of this process. 16 CSA. (2021) Publications: Cloud Threat Modeling 17 CSA. (2021) Research Topic: Top Threats 18 MITRE. (2024) Cloud Matrix 19 ENISA. (2022) The Risk Management Process © Copyright 2024, Cloud Security Alliance. All rights reserved. 26 Figure 8: Comprehensive Cloud Risk Management Framework 3.1.2.1 Corporate Risk Management Strategy These days, cloud usage serves a variety of corporate objectives with wildly varying risk appetites. The corporate risk management strategy sets the stage for risk management, in general, which helps translate business risk management to cloud risk management. 3.1.2.2 Risk Assessment Identify and analyze relevant risks to understand their potential impact on the organization. This involves evaluating each risk to determine the likelihood of occurrence and the severity of its consequences. 3.1.2.3 Risk Treatment After assessing risks, develop and approve an action plan to mitigate, transfer, avoid, or accept each risk. Implement these action plans and identify any residual risks that remain. © Copyright 2024, Cloud Security Alliance. All rights reserved. 27 3.1.2.4 Interface to Other Operational & Product Processes Risk management should not be siloed; it must interface with other business processes to ensure that risk considerations are embedded throughout the organization's operations and product lifecycle. 3.1.2.5 Monitoring & Review (Plans, Events, Quality) Continuously monitor risk management plans, events, and the quality of risk management activities. Regular reviews ensure that risk management processes remain effective and adapt to any changes in the business environment. 3.1.3 Assessing Cloud Services One of the first steps in managing cloud risks is having a systematic process to assess cloud providers and services. This assessment should align with your business needs and risk tolerance. The following process is designed to account for these differences: Business requests Review Cloud Service Provider (CSP) documentation Review external sources Map to compliance requirements Map to data classification Define required and compensating controls Approval process Figure 9: Systematic Process for Evaluating and Approving Cloud Services 3.1.3.1 Business Requests Whether or not the business unit has a specific cloud service in mind, it is important to understand the business need and the data involved. This helps to understand risk appetite and any relevant policies and regulations. © Copyright 2024, Cloud Security Alliance. All rights reserved. 28 3.1.3.2 Review CSP Documentation Most cloud service providers (CSPs) have the following categories of documentation: Security and privacy documentation: Review the CSP’s published security policies, privacy policies, and data handling practices to ensure they align with your organization's standards. Service level agreements (SLA) and contracts: SLAs outline the performance and uptime commitments of the CSP, while contracts detail the terms of service, including responsibilities and liabilities. Terms of service (ToS): Understanding the ToS is important to avoid legal or operational surprises post-adoption. These may be the only legal contracts between you and the provider. CAIQ and certifications: The CSA Consensus Assessments Initiative Questionnaire (CAIQ), based on the Cloud Controls Matrix (CCM) provides a comprehensive set of questions that CSPs answer to disclose their security controls. CSP certifications (e.g., ISO/IEC 27001, SOC 2) offer third-party validation of their security practices. 3.1.3.3 Review External Sources Research: Investigate external reviews, reported vulnerabilities, and any past security and operational incidents involving the CSP to gauge their security posture and response capabilities. 3.1.3.4 Map to Compliance Requirements When selecting a CSP, it is essential to align their features and policies with the organization's compliance needs, such as the General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act (HIPAA), or Payment Card Industry Data Security Standard (PCI DSS). This ensures that regulatory requirements are met and that the organization's data remains secure. 3.1.3.5 Map to Data Classification Not all data needs the same risk management. Providers and services should be approved based on data types, which allows flexibility, so not all providers and services need to meet the same standards for the most sensitive data. It’s acceptable to use a riskier service with less valuable or public data. Data sensitivity assessment: Assess the sensitivity of data in transit and at rest. Not all data carries the same risk; thus, not all cloud services are required to meet the highest security standards. Service approval based on data type: Approve CSPs and their services based on the classification of data they will handle. This approach allows for flexibility and efficient use of resources. © Copyright 2024, Cloud Security Alliance. All rights reserved. 29 3.1.3.6 Define Required & Compensating Controls Before final approval, security defines any required controls (e.g., configuration settings within the CSP) and any compensating controls (e.g., third-party tools) needed to use the service with the designated data types. 3.1.3.7 Approval Process Based on the gathered information and mapping, decide whether the CSP's services are appropriate for the intended data types. If they meet all criteria, approve their use and incorporate them into the organization's cloud register, ensuring visibility and control over cloud adoption. 3.1.4 The Cloud Register A cloud register is a central repository of approved cloud services, and what kind of data they are approved to handle at a given level of risk. This guides internal decisions on which providers and services to use for which projects. It also helps ensure that data is only used with compliant services, and thus plays a role in compliance as well. Provider Service Data Types Risk Expiration ABC Object storage Public, sensitive Low Annual ABC Virtual networks All Low Annual GHI CRM SaaS PII Moderate Quarterly Table 1: Cloud Registry Example This fictitious example shows three specific services from two providers and lists the data types that are allowed to be processed. Based on that, risk is assigned, and the required review frequency. This allows teams to accelerate risk assessment. 3.2 Compliance & Audit Compliance is the adherence to a set of requirements stemming from internal policies, applicable laws and regulations, sector-specific codes of conduct and codes of practices, standards, and best practices. Complying with applicable requirements allows organizations to satisfy internal policies and code of ethics, safely operate in the market, and in some cases (e.g., adhere to international standards), gain a competitive advantage. © Copyright 2024, Cloud Security Alliance. All rights reserved. 30 Compliance requirements can stem from: National and international standards and regulations can regulate the processing, storing, and transfer of certain types of data. Industry standards, such as PCI, for credit card handling. Many standards have cloud-specific guidance. Contracts. Internal policies and standards. These may need updating if they are too specific for on-premise environments. Compliance is demonstrated through audits and conformity assessments that evaluate the suitability of the system of controls to satisfy the applicable requirements. 3.2.1 Jurisdictions Many cloud deployments may span different legal and regulatory jurisdictions. The complexity of compliance becomes magnified when operations extend across multiple regions, each with its own legal and regulatory frameworks governing data privacy, security, and other critical factors. Let's delve deeper into the factors influencing jurisdictional considerations in the cloud environment. Cloud providers and cloud consumers operating in multiple regions will face a matrix of jurisdictions where various laws and regulations apply. This is affected by: The location of the cloud provider. The location of the cloud consumer. The location of the data subject. The location where the data is stored. The legal jurisdiction of the contract, which may be different than the locations of any stakeholders. Any treaties or other legal frameworks between those various locations. An example could be the requirement to issue a breach notification in the country you are operating in, even if the data was hosted in a different region. © Copyright 2024, Cloud Security Alliance. All rights reserved. 31 Figure 10: Factors Influencing Cloud Jurisdiction Compliance 3.2.2 Cloud-Relevant Laws & Regulations Examples There are a myriad of laws and regulations to navigate, and each organization has the obligation to understand its own specific set of legal and regulatory requirements. The following are some representative examples of regulations and industry standards that commonly affect cloud security and compliance. 3.2.2.1 Privacy Laws & Regulation EU GDPR: Sets a high standard for data protection, emphasizing individuals' rights over their personal data, requiring consent for data processing, and imposing strict penalties for non-compliance. US Regulations (CCPA/COPPA): Focus on specific sectors, protecting ○ Children's Online Privacy (COPPA) ○ California Consumer Privacy Act (CCPA), and other State-level acts with detailed requirements for handling and safeguarding data Brazil LGPD: Stands for General Personal Data Protection Law in English, strongly based on the EU GDPR. Like European law, it also sets a high standard for data protection, emphasizing individuals’ rights over their data, requiring consent for data collecting and processing, and imposing strict penalties for violations. © Copyright 2024, Cloud Security Alliance. All rights reserved. 32 Japan Act on the Protection of Personal Information, Australian Privacy ACT: National laws that regulate the collection, use, and disclosure of personal information, focusing on user consent, data accuracy, and cross-border data flow restrictions. 3.2.2.2 Other Relevant Laws & Regulations US Regulations: ○ Gramm-Leach-Bliley Act (GLBA), imposes requirements on financial institutions in the United States to protect consumer information. ○ Health information (HIPAA), safeguards medical privacy by establishing regulations on how healthcare providers, insurers, and others who handle data can use and disclose personal health information. EU Laws and Regulations: ○ EU Digital Operational Resilience Act (DORA), which ensures operational resilience for critical financial market infrastructures operating in public cloud platforms. ○ EU AI Act establishes essential regulations to ensure the trustworthiness of Artificial Intelligence (AI) systems. ○ NIS 2, the recently enforced update to the Network and Information Systems (NIS) Directive, strengthens cybersecurity measures for critical services across the EU ○ EU Cybersecurity Act aims to fortify the digital defenses of European Union institutions themselves. ○ EBA Guidelines on outsourcing arrangements by the European Banking Authority Cybersecurity Law of the People's Republic of China: Focuses on protecting the country's online infrastructure and data by outlining security obligations for companies, promoting public awareness of cyber threats, and granting authorities broad powers to monitor and regulate cyberspace. Payment Card Industry Data Security Standard (PCI DSS): A cross-jurisdictional standard for organizations that handle and process cardholder information, emphasizing financial data protection through comprehensive security measures. 3.2.2.3 Compliance in the Cloud In general, some of the factors that are common across several laws and regulations are: Secure handling: Ensuring that access to sensitive data is tightly controlled and that data is processed to maintain its confidentiality and integrity. Secure storage: Implementing encryption and other protective measures to safeguard data at © Copyright 2024, Cloud Security Alliance. All rights reserved. 33 rest and in transit, ensuring proper data retention and deletion practices. Due care: Adhering to industry best practices and security standards to protect data from threats and vulnerabilities. Audit trails: Maintaining comprehensive records of data processing activities to demonstrate compliance with regulatory requirements and facilitate audits. 3.2.2.4 Adherence to Standards Cloud providers often achieve conformity against a variety of regulations, industry, and national standards through certifications, attestation, and other forms of authorization. The most important ones are as follows. ISO/IEC 27001 is an international standard for information security management systems (ISMS). It provides a systematic approach to managing sensitive company information so that it remains secure. It includes people, processes, and IT systems by applying a risk management process. ISO/IEC 27001 is designed to help organizations of any size or industry to protect their information systematically and cost-effectively by adopting a comprehensive set of information security controls and management practices. System and Organization Controls (SOC) is a compliance standard for service organizations developed by the American Institute of CPAs (AICPA). It focuses on five Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy. SOC reports are designed to provide detailed information and assurance about a service organization's controls relevant to these criteria. It is particularly important for Software as a Service (SaaS) and technology companies that handle customer data to ensure they have the necessary controls in place to protect that data. The Security Trust Assurance and Risk (STAR)20 Registry was developed by the CSA. Through the STAR program, cloud providers can publish their adherence to these standards enhanced with cloud-specific controls from the CCM. 3.2.3 Compliance Inheritance Cloud compliance typically follows a shared responsibility model, where the cloud service provider (CSP) and the cloud service customer (CSC) are each responsible for certain aspects of compliance. Compliance inheritance aims to relieve some of the burden on the customer by allowing the customer to acquire a control set from a compliant provider. Consider a cloud infrastructure provider who is PCI DSS-compliant. A customer using their infrastructure services will inherit this set of controls and will be PCI DSS-compliant at the infrastructure level. The customer, however, will be additionally responsible for ensuring that the software built on this infrastructure is also PCI DSS compliant. Both the CSP and CSC are audited independently, and each must ensure that all their respective controls are compliant. 20 STAR is covered in greater detail in Domain 2: Cloud Governance & Strategies. © Copyright 2024, Cloud Security Alliance. All rights reserved. 34 Figure 11: Audit Scope: Provider vs. Customer Responsibilities 3.2.4 Artifacts of Compliance Compliance artifacts include the logs, documentation, and other materials needed for audits and compliance; they serve as evidence to support compliance activities. Customers are ultimately responsible for providing the necessary artifacts for their audits. Therefore, they need to understand what the provider offers and create their own artifacts to cover any gaps. For example, they might need to enhance the logging within an application if server logs on a PaaS platform are not accessible. The following are examples of compliance artifacts: Audit Logs: These logs are detailed records of events, actions, and changes within the cloud environment. Activity Reporting: Reports summarizing user activities, access patterns, and system interactions. Activity reports can help identify unauthorized access, track user actions, and ensure that operational practices align with compliance requirements. System Configuration Details: Documentation of system configurations, including network settings, access controls, and security measures. Change Management Details: Records of changes made to the system, including updates, modifications, and patches. These details are critical for ensuring that changes are authorized, tested, and implemented in a manner that maintains the integrity and security of the environment. 3.3 Governance, Risk, Compliance Tools & Technologies In the governance, risk, and compliance (GRC) tool kit, are technical and non-technical tools. This includes clear documentation of responsibilities, contracts, and repositories that store maintained risk © Copyright 2024, Cloud Security Alliance. All rights reserved. 35 registers and service registries. The content can also be documentation describing frameworks and processes that have been adapted for their business context and adoption process for the teams across the organization. There is also a wide variety of technical tools that are used to automate tasks that would be too labor-intensive for humans to do using manual processes. Many tools for implementing Governance, Risk, and Compliance are described throughout this Study Guide. Examples include the Shared Security Responsibility Model (Domain 1), contracts (Domain 3), risk register (Domain 3), cloud provider policies (Domain 4), and automation (Domains 5 and 10). © Copyright 2024, Cloud Security Alliance. All rights reserved. 36 Domain 4: Organization Management Introduction Most organizations use multiple Software as a Service (SaaS) Cloud Service Providers (CSPs) and have various deployments within Infrastructure as a Service (IaaS)/Platform as a Service (PaaS) CSPs. Many cloud footprints develop organically, including mergers, acquisitions, and consolidations, making cloud sprawl common. Organization Management involves managing an entire cloud footprint, including securing and validating CSP deployments. These top-level security concerns include structuring deployments for optimal scope and security control. Despite differences in CSP technologies, there is enough feature parity for consistent management. Learning Objectives In this domain, you will learn to: Manage organization-level security within a CSP. Leverage organization hierarchy for managing critical aspects of cloud deployments. Recognize security considerations for hybrid/multi-cloud deployments. Identify different cloud organization hierarchy models. 4.1 Organization Hierarchy Models There are various models of organization hierarchy utilized in cloud environments, each having their own complexities of managing cloud resources across different CSPs. As cloud service customers (CSCs) expand their use of cloud technologies, understanding the structural differences and terminology used by major CSPs like AWS, Azure, and Google Cloud is crucial. This section aims to clarify these concepts and present a standardized approach to discussing and implementing organizational structures in the cloud. 4.1.1 Definitions Different CSPs use different words for similar organizational structures. Here are the terms that are used in this study guide: © Copyright 2024, Cloud Security Alliance. All rights reserved. 37 An "organization" denotes the highest level of structure within a CSP cloud provider. A "group" represents a collection of deployments. A "deployment" refers to an isolated environment within a CSP cloud provider. Below is a brief overview of the different terminology used by the major CSPs. Cloud Service Organization Group Deployment Provider AWS Organization Organization Units Accounts GCP Organizations Folders Projects Microsoft Azure Tenant Resource Group Subscription Table 2: Cloud Service Provider Terminology Comparison Utilizing multiple deployments is a strategic approach to reducing the impact of adverse events or breaches, adhering to service limits imposed by CSPs, and facilitating the logical separation of different technology stacks. This approach highlights the importance of using a structured and hierarchical system to organize cloud resources. This method improves security and makes it easier to manage resources in different cloud environments. The figure below illustrates the hierarchical structure for cloud resource management across different CSPs, helping to visualize the similarities and differences: Figure 12: Hierarchical Structure for Cloud Resource Management © Copyright 2024, Cloud Security Alliance. All rights reserved. 38 4.1.2 Organization Capabilities Within a Cloud Service Provider Segmentation and segregation of organization units and different application environments are important for resilience and reducing the 'blast radius' ( potential extent) of a security breach. There are four main capabilities that all major CSPs offer that enable CSCs to significantly enhance security across their cloud environments: Groups allow CSCs to structure their deployments into an isolation hierarchy. Policies are sets of security rules that can apply to a group or a deployment. These typically enable and disable features, often down to specific API calls or even individual parameters. Identity and Access Management (IAM) centralization and/or federation supports centralized management of an organization’s users and their entitlements. Each CSP supports their own set of shared security services. These vary greatly, but support for central logging is nearly always available. In order to maintain consistency over many deployments in an organization, a CSP landing zone or account factory can be used. This is a pre-configured template that sets up and manages cloud accounts with standardized configurations, security policies, and governance controls. By automating the creation and setup of new accounts, it ensures that each deployment adheres to the CSC’s best practices and compliance requirements from the start. This approach simplifies management, enhances security, and ensures uniformity across multiple accounts and projects within the cloud infrastructure. 4.1.3 Building a Hierarchy Within a Provider CSCs typically adopt one of three models to define their hierarchy, each with its own advantages and operational implications. No single model is universally superior, and some CSCs may combine elements from different models to best reflect their operational realities: Business Unit and Application-Based: This model structures the cloud hierarchy with business units at the top, followed by applications within these units, and then environments (e.g., production vs. development). It aligns well with business-unit-focused IAM hierarchies but may be less efficient for policy management unless cloud features closely align with business units and applications. Environment-Based: Prioritizes environments (eg., development, production, testing) at the top, followed by business units or applications. It benefits policy management by establishing baseline security and operational policies for different environments but may not align well with IAM hierarchies or billing and cost management needs. Geography-Based: This model starts with geographic regions (e.g., EMEA, NA, specific countries) at the top, followed by business units or environments. It benefits global CSCs with diverse security and regulatory requirements specific to each region. © Copyright 2024, Cloud Security Alliance. All rights reserved. 39 4.2 Managing Organization-Level Security Within a Provider Organization-level security refers to controls set at the organization or group level, outside individual deployments. The goal of cloud security is to maintain acceptable risk without introducing friction that reduces or eliminates the benefits of cloud computing. It Is important to maintain control of the cloud footprint without impeding business objectives. CSPs offer a range of capabilities to support governance and security outside traditional security domains like network or application security. This starts with a well-defined tenant structure, which can be extended with additional controls. 4.2.1 Identity Provider & User/Group/Role Mappings As mentioned above, the highest level of aggregation of deployments is the Organization. At this level, identity management determines who can access and manage deployments. These capabilities are defined by an identity provider and a set of user/group role mappings. This is potentially separate from IAM inside the deployment21. At this highest level, there are two important factors to consider: Minimize root access to limit high-level alterations or privilege escalations. Restrict who can create deployments, but enable teams to easily create new deployments for their environments (e.g., development, sandbox, production) that match the policies in the team’s hierarchy. This is where the landing zones and account factories can accelerate those teams. Within the organization hierarchy that is enabled by these CSPs, technical policies can define security parameters across deployments. This external positioning ensures that even administrators with complete control over a specific deployment cannot modify or delete the policies. CSP policies can be categorized into three levels based on their scope: 1. Organization-wide policies are defined by the customer and apply to every deployment within the CSC. Typically, this category includes a limited set of policies due to the challenges in managing exceptions on such a broad scale. 2. Group-level policies that cover all deployments within a specific group. This level is most commonly used for policy application, with the ability for policies at this level to accumulate and reinforce one another, especially when applied to sub-groups. The combined set of policies is enforced by the CSP, with policies that deny actions almost always taking precedence over policies at lower levels. 3. Deployment-level policies are tailored for individual deployments, allowing for precise security adjustments. While applying policies at the group level is generally considered better 21 Additional material is provided in Domain 5: Identity and Access Management. © Copyright 2024, Cloud Security Alliance. All rights reserved. 40 management practice, certain scenarios necessitate deployment-level policies, particularly for deployments with specific and granular security requirements. Policies can be used in various scenarios, including: Enabling and disabling specific services, such as prohibiting the use of an unapproved platform service for deployment. Blocking particular API calls to prevent unauthorized or harmful operations. Disabling regions to comply with geographic regulatory requirements and maintaining data residency and sovereignty requirements. Defining conditions like permitting specific API calls only from authorized network sources/IP addresses. However, this requires both CSP and service-level support, representing one of the more inconsistent capabilities across providers. Implementing IAM practices to secure organization-level access and operational tools, including preventing a deployment administrator from restricting access to critical visibility and control accounts (e.g., in the event administrator credentials are compromised). 4.2.2 Common Organization Shared Services While individual deployments are isolated from one another, CSCs typically strive to have a degree of policy and risk management consistency across them. Until this point, we have discussed policies as a tool for that. In this section, we review a number of shared services that can be used across deployments to support those policies. Arguably the single most important shared service for cloud security and governance is consolidated IAM across deployments. This is discussed in more detail throughout this study guide. Centralized logging and security telemetry collect security feeds to a single destination, simplifying security monitoring, threat detection, analysis, and compliance. This is useful for sending telemetry to a Security Information and Event Management (SIEM) platform or security data lake22. CSP Threat Detection services continuously monitor for malicious activities and unauthorized behaviors, safeguarding deployments by identifying threats in real-time for prompt response23. Centralized cost management is often implemented through tagging policies, which allow for allocation of costs to specific applications, or business functions. Finally, a relevant organizational tool is account factories. These are facilitated by Infrastructure as Code (IaC)24. 22 Additional material is provided in Domain 6: Security Monitoring. 23 Additional material is provided in Domain 6: Security Monitoring and Domain 11: Incident Response. 24 Additional material is provided in Domain 7: Infrastructure & Networking. © Copyright 2024, Cloud Security Alliance. All rights reserved. 41 4.3 Considerations for Hybrid & Multi-Cloud Deployments In today's diverse IT landscape, CSCs often rely on both hybrid and multi-cloud environments to meet their operational needs. Hybrid cloud deployments connect on-premises data centers with public cloud services, enhancing flexibility and scalability while presenting unique security challenges. Multi-cloud strategies, on the other hand, involve using multiple CSPs to avoid vendor lock-in and optimize performance – but they also increase complexity in security management. This section explores the key considerations for securing hybrid and multi-cloud environments, focusing on effective organization management, IAM, network security, and the strategic use of security tools. 4.3.1 Organization Management for Hybrid Cloud Security A hybrid cloud integrates an existing data center or facility with a public cloud provider using a virtual private network (VPN) or dedicated network link. Domain 7 provides a detailed exploration of the networking aspects involved in this integration. To achieve strong hybrid cloud security, CSCs should ensure robust security measures in both cloud and data center environments. If there are weaknesses in either area, they are isolated and compartmentalized to prevent vulnerabilities from affecting the other environment. Key areas to focus on for hybrid cloud security include: 1. Identity and Access Management (IAM): A compromised identity provider can impact both the cloud and data center environments. Therefore, maintaining a strong IAM system is crucial. 2. Network Security: Weak network security can increase the attack's blast radius across both environments. Stringent network security measures should be implemented to protect against such threats. It is important not to normalize security controls between hybrid cloud environments, as cloud technologies and data centers have significant differences. Using a single set of controls for both can create security gaps and failures. Instead, appropriate tools and strategies should be tailored to each environment. Hybrid cloud sprawl, resulting from connecting multiple data centers to numerous cloud deployments through various VPNs or dedicated links and multiple identity providers, can increase security challenges. To mitigate this, connection sprawl should be minimized. Mature CSCs often consolidate connectivity into a central “bastion network” to govern all traffic flows between deployments, simplifying management and enhancing security. © Copyright 2024, Cloud Security Alliance. All rights reserved. 42 4.3.2 Organization Management for Multi-Cloud Security The concept of multi-cloud is often used to describe the usage of multiple IaaS/PaaS CSPs. Attempting this strategy before achieving maturity with one creates significant security challenges. Each CSP is fundamentally different, requiring a deep understanding of its unique characteristics. Supporting multiple CSPs with shared security services is very difficult. CSCs should not move to a second IaaS CSP until they have an effective security program for their primary CSP. However, mergers, acquisitions, or business requirements often result in multi-cloud environments. This challenge can be managed with adequate expertise, effective management strategies, and key security-shared services designed for multi-cloud. There are three strategies for organizing for multi-cloud: Single provider: The organization uses one CSP for IaaS deployments. If an additional CSP is added due to merger or acquisition, that deployment is migrated to the primary CSP. Primary/secondary: All new deployments go to a primary CSP, representing the CSC’s main cloud footprint. Additional CSPs are used for limited or isolated deployments, approved only if the primary CSP cannot meet specific needs or due to merger or acquisition. Secondary CSPs are tightly locked down and use minimal services to reduce security and operational complexity. Full multi-cloud support: The CSC equally supports two or more major CSPs. Ideally, a CSC starts with a single CSP and then adds compartmentalized islands as additional CSPs as needed, until mature enough to support multiple CSPs. However, many CSCs are forced into multi-cloud situations before maturity due to practical realities, internal politics, and business relationships. For CSCs adopting containers25, one common misperception of multi-cloud is that a cloud-agnostic container strategy will support fully portable workloads that allow the CSC to pick any CSP at any point in time, possibly for dynamic cost management. In reality, there are significant obstacles to achieving a cloud-agnostic implementation. These are as much operational as security challenges: Containers create workload portability but not management infrastructure portability. There is still considerable overhead in building out the runtime and orchestration environments for the containers. Shared services are typically less portable unless they are also fully stateless and containerized. Databases, message queues, notification buses, and other services that underlie modern applications are typically better served by a CSP service on dedicated, non-portable resources, A CSC may lose economic, security, and operational benefits provided by PaaS services from the CSP. 25 Additional material is provided in Domain 8: Cloud Workload Security. © Copyright 2024, Cloud Security Alliance. All rights reserved. 43 4.3.2.1 Tooling & Staffing for IaaS/PaaS Multi-Cloud Many CSCs transition to the cloud without increasing staffing, forcing existing staff to develop cloud skills while supporting traditional infrastructure. Each CSPr demands specific domain knowledge. The more services consumed, the wider the knowledge needed. CSCs should have at least one subject matter expert for each significant cloud platform. A primary/secondary strategy can reduce the need for dedicated experts. Smaller organizations often shift the burden of skilled staffing to Managed Service Providers (MSPs), but this does not shift accountability for security and governance. The MSP's vision, strategy, and capabilities should align with the desired future state of the CSC. 4.3.3 Organization Management for SaaS Hybrid & Multi-Cloud CSCs leverage various SaaS CSPs to enhance operations and innovation. Unlike IaaS, where consolidation and CSC security responsibilities are higher, SaaS presents challenges due to diverse offerings and diverging security maturity. Effective SaaS security management starts with diligent portfolio management. SaaS CSPs should be evaluated for security and compliance measures before authorization to handle specific data types. This process should be documented in a central registry. New SaaS CSPs within an already serviced category should require strong business justification. SaaS solutions often require integrations with other applications, facilitating data flow. Governance over these integrations is required to maintain security and control over data movement. Three types of tools can help management of multiple SaaS CSPs within a security program: 1.

CCSK Study Guide.pdf

Document Details

Tags

Related

Full Transcript

Upgrade to continue