CSA's Cloud Trust Summit 2024 featured an expert panel discussion about v2 of our CCM v4.0 Implementation Guidelines. Led by CSA's Lefteris Skoutaris, the panelists included:

• David Skrdla, Senior IT Auditor, Internal Audit, American Fidelity Corp/CamGen Partners
• Kerry Steele, Principal, Payments and Cloud Advisory, Coalfire
• John B. Oseh, Information Security Consultant, Handelsbanken Plc, UK

Below, read a summary of their insightful conversation. Learn about the Cloud Shared Security Responsibility Model and how both cloud customers and providers can utilize the CCM to clearly define security responsibilities. Alternatively, watch the full panel on-demand here.

Lefteris Skoutaris: Good day everyone and welcome to our presentation of the “Cloud Controls Matrix (CCM) v4.0 Implementation Guidelines: Securing the Cloud with the Shared Security Responsibility Model.” Joining us today are three of our distinguished experts from the CCM Working Group. They all played a pivotal role in shaping the development of the guidelines. They will be sharing their insights about the project, as well as its significance to the cloud industry.

A Quick Overview of the Cloud Controls Matrix (CCM)

Lefteris: I'll get started with an overview of the CCM. Currently, CSA manages over 25 active working groups that are conducting research in cloud computing and cloud security. One of these is the Cloud Controls Matrix Working Group. This group drives the development and evolution of the Cloud Controls Matrix and its underlying components, such as the Implementation Guidelines.

The CCM is a comprehensive cybersecurity controls framework developed by our subject matter experts in the CCM Working Group. It aids cloud organizations in assessing and managing risks related to the adoption of cloud services. It provides a set of 17 structured and standardized cloud security domains. The domains further break down into 197 more granular control specifications.

The CCM Working Group has delivered extensive implementation guidelines that are tailored to these 197 controls. They have been developed with the Shared Security Responsibility Model in mind. This assists cloud service providers and customers with defining a demarcation line of their responsibilities for the implementation of the controls on either end.

Version 2 of the Implementation Guidelines is going to completely replace the previous version. V2 is a far superior document, as our experts will illustrate shortly. It's going to be available for free in three formats: within the CCM spreadsheet, as a PDF, and machine readable.

The Shared Security Responsibility Model in the Cloud

Lefteris: Here I would like to invite one of our experts to help us understand what the Shared Security Responsibility Model means for the cloud.

David Skrdla: A rather well-known analogy for the ownership of responsibilities between the cloud service provider and the cloud service customer is the Pizza-as-a-Service model.

This model is commonly used to compare the different allocations of the technology ownership and responsibilities found in the fully on-premises infrastructures compared to the big three cloud service models: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS).

Most of us agree that this model presents a very helpful picture of the general responsibilities in our modern cloud environments. However, security controls are neither always equally the responsibility of the CSP and the CSC, nor are they always divided along well-defined lines.

The next slide presents the typical security responsibilities in the cloud.

We can say that the cloud service provider is responsible for security of the cloud. The cloud service customer is responsible for its security within the cloud. We also know that there are responsibilities where both the CSP and the CSC have a part. This area of shared responsibility is often the most interesting, and sometimes the most ambiguous.

And of course we also know that the specific responsibilities depend on the cloud service offering itself, the particular controls in question, and unique agreements among the parties. An exact and specific allocation of security responsibilities can't be identified. And there isn’t a document in one place for every CSP/CSC cloud offering and control available in the market today.

Guidance for the Shared Security Responsibility Model

David: Considerable thought can be given and very well-reasoned principles identified for each of the specific controls of the CCM. That's what the SSRM Guidance is aimed to provide. On the next slide we see how the SSRM is involved with different components of the overall control framework.

Within the CCM, controls are specified for SSRM policies and procedures, SSRM supply chain, SSRM guidance, SSRM control ownership, SSRM documentation review, and SSRM control implementation, among others. The matrix also indicates a typical control applicability and ownership of the control that is applied for the IaaS, PaaS, and SaaS models. We also have a column for service providers to indicate the control ownerships and responsibilities within the supply chain as applied to their service offerings.

So that brings us to the Implementation Guidance v2. This guidance has been extended to include the details of the Cloud Shared Security Responsibility Model. This effort has spanned almost a year and is culminating with the guidance that we're presenting today. Kerry and John will share some highlights of that project.

Kerry Steele: This was no small endeavor. The implementation guidelines were developed over a 14 month period. The project reflects the contributions from multiple stakeholders, including CSPs, CSCs, SMEs, and the broader community. During the final open peer review phase, the guidelines were reviewed by each of the major hyperscalers and their feedback was integrated into the final version.

One of the primary objectives of the project was to identify the CCM control ownership, implementation, and responsibilities across each of the cloud service delivery models. This included defining responsibilities and best practices for both the CSPs and CSCs. And as David described earlier, depending on how you'd like to make pizza, the responsibilities can vary widely.

Structuring the Guidance

John B. Oseh: I will give you an overview of the structure of the CCM Implementation Guidelines.

Table 1 is the CCM controls, consisting of a high level and sourcing control title. Now in this particular example, this control falls under the Audit and Assurance domain, abbreviated as A&A. And further down, you've got the control ID and a unique ID that actually identifies each control within a domain. Then finally, still on Table One, you've got control specification.

Table 2 is the Shared Security Responsibility Model. The focus here is on control ownership by cloud architecture type. So here we have determined if a particular control applies to any or all of the three cloud service models.

Additionally, there is no handoff as far as this particular control is concerned. Hence, the control implementation is independent. I'm going to elaborate more on that later.

Table 3 is basically the SSRM Rationale Loss Implementation Guidelines. This to me is the most crucial section of the Implementation Guidelines. It amplifies four key things:

1. Managing security rigs and controls in the cloud is a shared responsibility between the provider and consumer. However, the point where responsibility transitions from the provider to the consumer can be a gray area. This is especially true when you've got multiple vendors and managed service providers involved in operating those controls.
2. Different cloud service models affect the ways that responsibilities are shared between the CSPs and the customers.
3. When it comes to managing ongoing relationships with providers, it is vitally important to establish from the outset clear roles and responsibilities.
4. Implementation and operation of security controls requires cooperation and a clear dedication of responsibility between the customer and the cloud service provider.

Now a control can be owned exclusively by the cloud service provider or the cloud service customer. In between that, a control can additionally be shared between the CSP and the CSC but independent, or it can be shared but dependent. In other words, there is a kind of handoff of how the control will be implemented.

Leveraging the Guidelines when Implementing Mappings and Other Standards

Kerry: “Can I leverage the guidelines to guide the implementation of controls in multiple frameworks?” The short answer is absolutely. Once the CCM has been mapped to a framework, CSCs can leverage the SSRM. It provides guidance on how CSP services could support the CSC's responsibilities to maintain compliance for their environment.

For example, the CCM was recently mapped to the latest version of the Payment Card Industry Data Security Standard, or PCI DSS. With this mapping, there's 62 controls where there's partial alignment and 90 controls where there's a full one-to-one alignment. And that means that through this project, CSCs have guidance on how they could implement, inherit, or partially inherit the responsibilities of PCI DSS control requirements from their CSP.

Leveraging the Guidelines for Implementation Assessments

Kerry: "As a CSC, what should I expect the CSP to have implemented?" The Cloud Security Alliance maintains the STAR Registry. That's for organization cloud service providers, where they want to attest that they are aligned with the Cloud Controls Matrix. All the major hyperscalers have submitted their STAR Level 1 certification and many have obtained STAR Level 2. So CSCs should ensure that their CSPs are STAR Level 1 or Level 2 certified and listed in the STAR Registry.

The Implementation Guidelines provide CSPs guidance on best practices, as well as CSCs on how they can vet their CSPs.

Conclusion

Lefteris: It is important to note that the guidelines are a result of collaboration between the community, cloud service customers, and providers. This ensured that the guidelines set realistic expectations for both parties regarding their security responsibilities.

Feel free to reach out either to me or our support team. I invite anyone to continue our discussion within our CCM Working Group calls. Thank you for your time.