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

Originally published by Tenable.

Written by Tom Croll, Advisor at Lionfish Tech Advisors.

Cloud security’s shared responsibility model (SRM) concept is key for cloud adoption, yet it’s very confusing. In this post, you’ll learn how to use this model, what its limitations are and how to improve it with three elements to identify control gaps.

What is the shared responsibility model for cloud security?

In the SRM, the "responsibility" is shared between the cloud service provider (CSP) and the customer, as this AWS diagram shows.

(Credit: Amazon AWS: AWS Shared Responsibility Model)

The scope of responsibilities varies based on the cloud model. These are the traditional boundaries for IaaS, PaaS and SaaS:

(Credit: Tenable)

The bottom shows the CSP’s responsibility for "security of the cloud" while the top shows the customer’s responsibility for "security in the cloud".

Effective use of the SRM

The SRM can help you design controls and identify areas to save time and resources.

(Credit: Tenable)

Public cloud providers hold compliance attestations, such as HIPAA or PCI DSS, which ease your cloud compliance burden through:

1. Inheritance. When the cloud platform you use is compliant with specific regulations, you 'inherit' a portion of that compliance.
2. Transparency. Compliance attestations provide assurance that the CSP maintains a high security standard, validated by independent auditors.
3. Documentation. Cloud providers that offer detailed compliance artifacts simplify the assurance process and help align your security controls with internal policies and regulatory standards.

The basic SRM allows you to define each project’s security requirements. You can use cloud native tools, such as those for CSPM, to automate compliance and monitor configurations. Moving to public cloud also lets you improve your established controls by embracing principles such as zero trust.

SRM limitations

CSPs and customers often struggle to delineate the "dividing line of responsibility" –where the customer’s responsibility ends and the CSP's begins. This can create control gaps. Also, some key elements are not represented.

I see confusion in these areas:

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

Adding these layers to the existing model helps you identify control gaps and clarify your responsibilities.