Every organization using cloud services needs to understand and implement a Shared Security Responsibility Model (SSRM). This involves documenting, communicating and enforcing policies and procedures that clearly delineate the security responsibilities of the cloud service provider (CSP) versus those of the cloud service customer (CSC). These SSRM policies should be regularly reviewed and updated, at least annually.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10, released on 2023-09-26. You can download the full CCM here. The CCM provides a comprehensive set of security controls specifically designed for cloud computing. For more background, check out the AWS Shared Responsibility Model documentation.

Who should care?

• CISOs and security leaders responsible for overall cloud security strategy and governance
• Cloud architects designing secure solutions that span on-prem and cloud environments
• DevOps teams deploying and managing workloads in the cloud
• Compliance managers ensuring cloud usage adheres to relevant standards and regulations

What is the risk?

Without a well-defined and enforced SSRM, there can be dangerous gaps and blind spots in an organization's cloud security posture. Misconfigurations and vulnerabilities could creep in from either the CSP or CSC side. Data breaches, compliance violations, service outages and other security incidents become more likely. The severity depends on the sensitivity of the data and criticality of the cloud workloads.

What's the care factor?

For most organizations using cloud, implementing a robust SSRM should be a high priority foundational practice. It's essential for avoiding costly security mistakes and demonstrating compliance. However, very small or low-risk cloud footprints may be able to start with lightweight informal processes and dial up maturity over time as usage grows.

When is it relevant?

Having SSRM policies and procedures makes sense for practically any organization adopting cloud computing. It's especially crucial for highly-regulated industries, those with sensitive data, or running mission-critical workloads in the cloud. It may be less relevant in very limited basic cloud use cases (e.g. just using cloud-based office apps).

What are the trade-offs?

Developing and maintaining comprehensive SSRM documentation does require ongoing time and effort from various teams. It constrains teams to operate within certain guardrails. Over-emphasis on strict policies could slow down agility and innovation if not balanced well. However, this is generally a worthwhile investment compared to the major risks of an undefined SSRM.

How to make it happen?

1. Assign clear ownership for developing and maintaining SSRM policies
2. Review shared responsibility documentation from your CSP(s)
3. Work with security, compliance, and technical leads to draft policies covering key domains (e.g. data security, incident response, logging, vulnerability management, etc)
4. Delineate specific CSP vs CSC responsibilities and procedures for each area
5. Have policies reviewed and approved by leadership
6. Communicate and train all relevant personnel on SSRM policies
7. Translate policies into technical standards, guardrails, and defaults where possible
8. Assess and audit compliance with policies on a regular basis
9. Review and update policies at least annually

What are some gotchas?

• SSRM can vary significantly across different cloud service models (IaaS, PaaS, SaaS) and products - one size doesn't fit all
• Shared responsibilities still exist even in "fully managed" services
• Specific roles and responsibilities should be documented, not just high-level policies
• Technical guardrails (e.g IAM permissions boundaries) are needed to enforce policies
• Policy on paper isn't enough - you need practical implementation and auditing

What are some alternatives?

There aren't really alternatives to having an SSRM. It's a fundamental cloud security practice. However, implementation can look different based on an organization's maturity and risk profile. Smaller shops may start with more basic informal policies and processes vs. enterprise-grade formal governance frameworks. Tools like AWS Config can help automate some policy enforcement and auditing.

Explore Further

• AWS Shared Responsibility Model documentation
• Shared Responsibility Models for other major CSPs
• CIS Controls v8 - #4: Secure Configuration of Cloud Platforms and Enterprise Assets

‍