The shared responsibility model explained and what it means for cloud security

Cloud adoption has accelerated in the past year as organizations scrambled to support a remote workforce. Despite this rapid adoption and growth, companies often misunderstand a key cloud concept: the shared responsibility model (SRM).

Many business leaders still ask, “Is the cloud secure”? This is the wrong question. A more appropriate question would be, “Are we, as a security team and organization, securing our share of the cloud?” The overwhelming majority of cloud data breaches/leaks are due to the customer, with Gartner predicting that through 2025, 99% of cloud security failures will be the customer’s fault. For this reason, it is imperative that all security practitioners understand their responsibilities.

What is the shared responsibility model?

The shared responsibility model delineates what you, the cloud customer is responsible for, and what your cloud service provider (CSP) is responsible for. The CSP is responsible for security “of” the cloud—think physical facilities, utilities, cables, hardware, etc. The customer is responsible for security “in” the cloud—meaning network controls, identity and access management, application configurations, and data.

That said, this division of responsibilities can change depending on what service model you use. At a basic level, the NIST Definition of Cloud Computing defines three primary cloud service models:

• Infrastructure as a service (IaaS): Under the IaaS model, the CSP is responsible for the physical data center, physical networking, and physical servers/hosting.
• Platform as a service (Paas): In a PaaS model, the CSP takes on more responsibility for things such as patching (which customers are historically terrible at and serves as a primary pathway to security incidents) and maintaining operating systems.
• Software as a service (SaaS): In SaaS, the customer can only make changes within an application’s configuration settings, with the control of everything else being left to the CSP (think of Gmail a basic example).

Each comes with a tradeoff, with the customer relinquishing control in exchange for more of a turnkey/managed experience with the CSP handling more of the operational activities and letting the customer focus on their core competencies.

Each CSP has varying versions of the SRM. Below is an example from Microsoft Azure’s SRM:

Microsoft

How security practitioners can prepare for the SRM

While the SRM involves non-security issues such as contracts and financial implications, it also includes several security considerations. Security practitioners must understand what they are responsible for in the SRM based on the services they are consuming and their organizations’ implementations and architectures. Remember how nearly all cloud data incidents occur on the customer side of the SRM? This is a major reason to understand the SRM and ensure you are doing your part of the model.

Your responsibilities depend on which of two primary security role perspectives you have: the technical security practitioner or security executive. Technical security practitioners, such as cloud security engineers or cloud security architects, need to understand what cloud services your organization is using, how to securely architect those solutions, and what configurations, settings, and controls are under your purview that you can influence and lead to a more robust security posture.

Technical security professionals should be intimately familiar with the platforms and services their organization is using and understand how to implement them securely. Cloud security engineers/architects often work with engineering and development teams. If you are not able to guide them to secure solution, or spot risky configurations (remember how these account for most cloud data incidents), you could be exposing your organization to tremendous risk.

Look to your CSP for security resources. Amazon Web Services (AWS), for example, offers an incredible database of security documentation, broken down by categories (e.g., compute, storage, security, identity, and compliance) where you can find specifics associated with each of the services your organization is using. This includes myriad information from how to securely configure the services, what configurations you can manipulate, and troubleshooting guidance.

Key considerations for security executives include inventorying service usage (you must know what is being used within your organization or you cannot secure it), ensuring the services you use are compliant with your applicable regulatory frameworks, and understanding contractual/legal aspects such as CSP service level agreements (SLAs), especially when it comes to things such as incident response planning.

Many organizations enter into a partnership with the CSP and share responsibilities. This includes ensuring the services you’re using meet the regulatory frameworks you must adhere to. The hyperscale CSPs make this information easy to find, with by AWS and Microsoft Azure providing “services-in-scope” pages where you can determine what services comply with what frameworks and which are still in approval processes. This helps ensure your team not only builds robust and secure architectures and workloads in the cloud, but also uses services that are compliant with your applicable frameworks to avoid compliance or regulatory issues.

Security practitioners of all levels should strive to implement secure standards and best practices in their cloud environments. This could mean implementing security best practices from your respective CSPs or implementing something such as the Center for Internet Security (CIS) benchmark for your respective cloud environments.

The customer responsibility matrix

A fundamental artifact when dealing with the SRM is the customer responsibility matrix (CRM), which lays out what controls are being provided by the CSP and what responsibilities are left to the cloud consumer. A great place to find a template CRM and learn more about them is the US’s Federal Risk and Authorization Management Program (FedRAMP). FedRAMP is a program that handles the authorization of cloud service offerings for consumption across the federal government.

A CRM is a critical tool for security practitioners to use. In the SRM, security controls are either provided entirely by the CSP, a hybrid control (with responsibility falling on both the CSP and cloud customer), or entirely left to the customer. Security practitioners can leverage CRMs to get a clear understanding of this security control delineation.

Consuming cloud services can shift responsibility of some security controls and activities to the CSP and let organizations focus on their core competencies. That said, it creates a relationship of responsibilities that security professionals must understand and handle appropriately. Remember, most cloud data breaches will occur on the customer side of the SRM and at the end of the day, you own the full responsibility of your organization’s reputation.