Unpacking the Shared Responsibility Model for Cloud Security: How To Avoid Coverage Gaps and Confusion

Confusion over the scope of customer responsibility for cloud security causes control gaps and exposes businesses to risks of attack and non-compliance. Secure configuration of customer-managed resources is the most critical factor for reducing cloud risk. However, it can only be achieved by first understanding the nuances of responsibility before identifying and applying appropriate controls.

In this post, I will break down the shared responsibility model (SRM) for cloud security - a core concept for cloud adoption, yet one fraught with confusion and difficulties. I will show how to effectively use this model, what its limitations are and how it can be improved by adding three key elements to better identify control gaps and protect business operations.

What is the shared responsibility model for cloud security?

The diagram below shows the AWS version of the shared responsibility model:

(Credit: Amazon AWS: AWS Shared Responsibility Model)

The "responsibility" is essentially split into two parts, shared between the cloud service provider (CSP) and the customer. The scope of responsibilities varies based on the cloud model. The traditional boundaries for IaaS, PaaS and SaaS are shown below:

The bottom shows the CSP’s responsibility for "security of the cloud" - including the infrastructure, hardware, software, networking, and facilities that underpin cloud services.

The top shows the customer’s responsibility for "security in the cloud". They must manage and secure access to the data they store, down to the operating system level in IaaS.

Effective use of the SRM

The SRM can help us design necessary controls and also identify areas where we can save time and resources. 

Public cloud providers hold multiple industry-specific compliance attestations, (e.g., the Health Insurance Portability and Accountability Act, or HIPAA, and the Payment Card Industry Data Security Standard, or PCI DSS), to meet the security requirements of their most demanding clients. These attestations can ease the burden of cloud compliance for your organization through:

1. Inheritance. When you host data or applications on a cloud platform that's already compliant with specific regulations, you 'inherit' a portion of that compliance. This doesn't mean you're automatically compliant, but it reduces the number of controls you are responsible for.
2. Transparency. These attestations provide assurance that the CSP is maintaining a high standard of security, validated by independent, third-party auditors.
3. Documentation. Leading cloud providers offer detailed compliance artifacts through online portals, simplifying the assurance process and helping align your security controls with internal policies and regulatory standards.

Each project is different and must be assessed at inception. The basic SRM allows us to define each project’s security requirements by listing the services required and applying established best practices to core components. Mature cloud native tools, such as those for cloud security posture management (CSPM), should be deployed to automate continuous compliance and monitor for insecure configurations. Moving to public cloud also offers us the opportunity to improve our established controls by embracing cloud native principles such as zero trust.

Limitations of the SRM

One central problem is the "dividing Line of responsibility". CSPs and customers struggle to delineate exactly where one's responsibility ends and the other's begins, leaving gray areas, which lead to control gaps. In addition, a number of key elements are not represented, leading to unidentified risk.

In particular, I continue to see confusion in the following areas:

1. Configuration
2. Visibility and monitoring
3. Identity and permissions

Adding these layers to the existing model helps us better identify control gaps and clarify our scope of responsibilities.

Updating the SRM

Configuration, visibility and monitoring, and identity and permissions are represented below:

With this updated model, we can now explore their nuances and recommend effective controls.

Configuration

The most critical area of the updated SRM is configuration. Below are some of the most common issues I encounter while working with clients:

• The vast majority of publicly disclosed cloud breaches are the direct result of insecure configurations or mistakes introduced at the customer layer.
• The number of objects, permissions and configuration settings combined with an increasing number of cloud services across multiple cloud providers have resulted in an exponential rise in complexity that cannot be quantified or managed by manual processes.
• Automated CI/CD pipelines reduce delivery times by replicating standardized patterns across multiple environments but also allow configuration mistakes to be deployed at scale.
• SaaS configuration remains largely overlooked. Due to the large number of disparate applications, best practices are impractical to establish and maintain.

To address these challenges, we have a number of options:

• CSPM tools have matured, providing extensive capabilities that ensure configuration errors are identified and remediated quickly.
• Increased automation enables continuous configuration assessments of increasingly complex cloud resources and their interactions across multiple platforms.
• Infrastructure as code (IaC) scanning should be deployed to "shift left" and integrate controls with the development pipeline to proactively identify risks before infrastructure is created.
• SaaS security posture management (SSPM) tools have emerged to provide security posture assessment for an increasing number of business critical applications.

Identity and access management

Identity and access management (IAM) practices have also changed in the cloud:

• Identity is now used as a perimeter to isolate accounts and provide strong separation in the event of a compromise. However, this increased reliance has driven attacks on identity stores (see SolarWinds) so additional protection is needed.
• The ability to assign granular identities and permissions to new types of objects further increases complexity.
• Stronger authentication must be combined with a zero-trust security model that requires us to continually monitor relative risk/trust signals after the user logs in. 

However:

• CSPs inherently enforce strong separation of multiple customers, and provide robust identity services and integration with third party services.
• Fine-grained authorization is built into cloud platforms, enabling role-based access control and delegation of administration.
• Authentication controls such as MFA and conditional access can be centrally mandated in all major IaaS/PaaS providers and leading SaaS applications by integrating with identity management software.
• CSPs and third-party vendors facilitate zero trust models by offering multiple tools to continuously monitor post-authentication user behavior, helping to protect from insider threats or compromised credentials.

Visibility and Monitoring

CSPs offer extensive analytical data, meaning visibility can be better than your on-premises capabilities. But this comes with its own set of challenges:

• Without a structured logging strategy, the data goes unmanaged and unanalyzed for risks.
• Dumping raw cloud telemetry into an enterprise SIEM means increased bills, higher bandwidth charges and arbitrary, contextless alerts.
• Cloud native applications are often created outside the visibility and control of traditional tools, leading to blind spots.

However:

• CSPs offer new cloud security capabilities, including cloud threat detection and response.
• Cloud services such as serverless functions provide built-in monitoring (typically integrated into CSP logs).
• Leading SaaS providers now offer increasingly detailed monitoring and logging.

Conclusion

The shared responsibility model, while essential, comes with its share of difficulties. Chief among them is the lack of detail and clarity about who is responsible for what. Understanding these challenges and taking measures to address them is critical for maintaining a robust cloud security strategy.

Above all, secure configuration, robust identity and access management controls, and comprehensive visibility and monitoring analysis are the most critical elements for avoiding coverage gaps and better protecting your business.

To learn more about this topic, watch our on-demand webinar “Deconstructing the Cloud Security Shared Responsibility Model. How to Avoid Coverage Gaps and Confusion to Better Protect Your Business.”