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.

(Credit: Tenable)

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

Configuration

Configuration is the updated SR model’s most critical area. Issues I see clients encounter include:

• Most cloud breaches result from insecure configurations or customer mistakes.
• The many objects, permissions and configuration settings combined with multi-cloud services have created complexity that can’t be manually managed.
• Automated CI/CD pipelines reduce delivery times but also deploy configuration mistakes at scale.
• SaaS configuration remains overlooked. Due to many disparate applications, best practices are impractical to establish and maintain.

To address these challenges, we have these options:

• CSPM tools have matured, and can ensure that configuration errors are identified and remediated quickly.
• Automation enables continuous configuration assessments of complex cloud resources and their interactions across multiple platforms.
• IaC scanning should be deployed to "shift left" and integrate controls with the development pipeline toidentify risks before infrastructure creation.
• SSPM tools provide security posture assessment for an increasing number of business critical applications.

Identity and access management

• Identity is now used as a perimeter to isolate accounts and provide strong separation. However, this has driven attacks on identity stores.
• Assigning 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 you tomonitor relative risk/trust signals after the user logs in.

However:

• CSPs 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 administration delegation.
• Authentication controls can be centrally mandated in all major IaaS/PaaS providers and SaaS apps 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.

Visibility and monitoring

CSPs offer extensive analytical data but this has its own challenges:

• Without a structured logging strategy, the data goes unmanaged and unanalyzed for risks.
• Dumping raw cloud telemetry into a SIEM means higher bandwidth charges and arbitrary alerts.
• Cloud native apps are often created outside the control of traditional tools, creating blind spots.

However:

• CSPs offer new capabilities, including cloud threat detection and response.
• Cloud services such as serverless provide built-in monitoring.
• Leading SaaS providers offer detailed monitoring and logging.

To learn more about this topic, watch Tenable’s on-demand webinar “Deconstructing the Cloud Security Shared Responsibility Model.”

About the Author

Tom Croll is an Advisor at Lionfish Tech Advisors and a Tenable consultant. As a former Gartner analyst, he co-authored the original research on CNAPP, defining the requirements for effective application security in public cloud. With over 20 years of industry experience, he was also a pioneer of DevSecOps methodologies. He currently provides advisory services in cloud application and infrastructure security (IaaS, PaaS and SaaS), security service edge (SSE), secure access service edge (SASE) and security posture management (SSPM).