The Shared Security Responsibility Model (SSRM) is a critical concept in cloud computing that delineates the security obligations of the cloud service provider (CSP) and the cloud service customer (CSC). Understanding and properly implementing the SSRM is essential for secure cloud deployments. The STA-04 control from the Cloud Security Alliance Cloud Controls Matrix provides guidance on how to clearly define and communicate the shared ownership of security controls between CSPs and CSCs.

Where did this come from?

This article is based on the STA-04 control from the CSA Cloud Controls Matrix v4.0.10, released on September 26, 2023. The Cloud Controls Matrix (CCM) is a cybersecurity control framework for cloud computing, composed of 197 control objectives structured in 17 domains. It can be downloaded from the Cloud Security Alliance website.

The CCM is considered a de-facto standard for cloud security assurance and compliance. Many CSPs align their security controls and certifications with the CCM framework. For more background, refer to the CSA Security Guidance v4.0.

Who should care?

This control is relevant for:

• Cloud architects designing secure cloud solutions
• Security engineers implementing cloud security controls
• Compliance officers validating adherence to the SSRM
• Procurement teams evaluating CSP security postures
• IT leaders making strategic decisions about cloud adoption

What is the risk?

Failure to properly understand and implement the shared responsibility model can lead to dangerous gaps in an organization's cloud security posture. Common pitfalls include:

• Assuming the CSP covers more security responsibilities than they actually do
• Not implementing required security controls on the customer side
• Lack of communication and coordination between the CSP and CSC
• Ambiguity over the exact delineation of duties

These gaps can make cloud assets vulnerable to threats like unauthorized access, data breaches, denial of service, and non-compliance with regulations. The consequences can be severe - reputational damage, financial losses, legal penalties, and disruption to operations.

What's the care factor?

For organizations with business-critical cloud workloads, the care factor for the SSRM should be very high. Even a minor security incident in the cloud can snowball into a major crisis.

However, the level of concern will vary based on the sensitivity of the data and criticality of the cloud systems involved. An e-commerce app storing PII and processing payments needs to sweat the details of the shared responsibility matrix much more than a startup using the cloud for dev/test environments.

When is it relevant?

The SSRM is relevant for practically any use of public cloud services, across IaaS, PaaS and SaaS models. It's a foundational element of cloud security.

That said, the specific shared responsibilities will differ significantly based on the cloud model:

• For IaaS, the CSP secures the underlying infrastructure, but the customer is responsible for securing the OS, apps, and data
• With PaaS, the CSP also takes on securing the development environment
• For SaaS, most security responsibilities lie with the provider, but the customer still needs to handle access management and some config

The SSRM is less relevant for pure private cloud deployments where the organization owns the full stack. Although many of the same security principles still apply.

What are the trade offs?

Establishing a robust SSRM requires an upfront investment of time and resources:

• CSPs need to clearly document and communicate their security responsibilities
• Customers have to carefully review the shared responsibility matrix and address any ambiguity
• Security engineers need to step through each control and ensure all bases are covered

There's also an ongoing overhead to keep the SSRM current as the use of cloud services evolves. Some customers may find the additional security responsibilities burdensome compared to traditional on-prem models.

However, these costs are far outweighed by the security benefits. A well-implemented shared security model provides the foundation for compliant, resilient, and secure cloud operations. It surfaces gaps and drives the right risk conversations.

How to make it happen?

For CSPs:

1. Document the division of security responsibilities for each cloud service in your portfolio
2. Specify which controls are owned by the provider, the customer, or shared
3. Provide detailed guidance to help customers understand and fulfill their obligations
4. Incorporate the shared responsibility model into customer agreements and SLAs
5. Use frameworks like the CSA CCM to standardize your controls and make customer assessments easier

For CSCs:

1. Carefully review the CSP documentation on shared responsibilities
2. Map each required security control to an owner - CSP, internal team, or third party
3. Highlight any gaps or areas of ambiguity and resolve them with the CSP
4. Document all customer-side responsibilities and ensure they are assigned and implemented
5. Set up processes to keep the shared responsibility model current as cloud usage evolves
6. Verify the CSP maintains their side of the bargain through control assessments and audits

What are some gotchas?

• Not all CSPs are transparent and detailed about shared responsibilities. Some might downplay customer obligations. Always dig into the fine print.
• Legacy security tools and processes may not directly translate to the cloud. The SSRM requires cloud-native guardrails.
• Shared responsibilities can get complicated with multi-cloud setups. Using a cloud security posture management (CSPM) solution is recommended.
• Customers often underestimate the work involved in properly configuring CSP security services like IAM, security groups, logging etc. Don't assume defaults are enough.
• Third-party SaaS solutions procured directly by business units can fly under the radar. Make sure the SSRM accounts for shadow IT.
• Documentation isn't enough. Responsibilities have to be socialized and practiced through training, runbooks, fire drills etc.

What are the alternatives?

There isn't a direct alternative to the SSRM - it underpins most cloud security efforts. Attempting to transfer full responsibility to the CSP via contract is unrealistic beyond a narrow set of fully-managed services.

For organizations uncomfortable with the public cloud shared model, options include:

• Private cloud / on-prem deployments with full ownership of the security stack
• Virtual Private Cloud offerings from some CSPs that minimize the attack surface
• Cloud security overlays and managed detection and response services to offload some responsibilities

However, these approaches come with trade-offs in agility, cost, and in some cases security, compared to embrace the shared model.

Explore further

• AWS Shared Responsibility Model
• Microsoft Azure shared responsibility in the cloud
• Google Cloud security shared responsibilities
• CSA Security Guidance v4.0 - Domain 1: Cloud Computing Concepts and Architectures
• NIST SP 500-292 - NIST Cloud Computing Reference Architecture

The STA-04 control is closely related to these CIS controls:

• CIS Control 19: Incident Response and Management
• CIS Control 15: Service Provider Management
• CIS Control 2: Inventory and Control of Software Assets

‍