A look at the shared responsibility model of cloud providers

Many cloud providers now offer a shared responsibility model for their customers. Expert Dave Shackleford looks at the major providers' models and what they might be missing.

As the use of cloud computing has grown, so has the concept of the shared responsibility model for data protection and cybersecurity in general. While not a new concept -- we've shared security responsibilities with most outsourcing arrangements for many years -- the nature of shared security responsibilities has changed with the advent of the cloud. In a recent whitepaper, Microsoft made it clear that it supports shared responsibility in the cloud, but not all shared responsibility models are created equal. Microsoft stated that defining data classification and protection controls are the responsibility of the customer, and progress down through the cloud computing stack, describing application and operating system controls, network capabilities and the underlying host infrastructure that includes hypervisors, storage components, redundancy and scalability tools and more. The following breaks down the basic responsibility model Microsoft describes in its paper:

 

• Data protection and classification: Customer responsibility in all models;
• Endpoint and client protection: These are the responsibility of the customer except in software as a service environments, where the responsibility is shared. An example would be mobile device security when using Microsoft InTune;
• Identity and access management: With SaaS and platform as a service (PaaS) offerings, identity and access management is shared, but is the responsibility of the customer entirely in IaaS environments;
• Application level control: Naturally, application level controls within SaaS offerings are secured by the providers. PaaS offerings are shared, and infrastructure as a service (IaaS) requires the customer to secure the application stacks they deploy;
• Network control: This is very limited, and only partial network configuration is available within IaaS; the provider controls everything else; and
• Host infrastructure: Much like the network, the underlying computer stack is largely managed by providers entirely -- only in IaaS environments will consumers have any access to or control over some of these capabilities.

Shared responsibility models in other cloud providers

Amazon Web Services follows a similar model. AWS breaks down the responsibility model into two primary categories: security in the cloud, and security of the cloud. Security in the cloud is the responsibility of the customer, and this includes data protection, identity and access management, operating system configuration, network security -- access controls -- and encryption. AWS is responsible for the underlying pieces of the infrastructure, including the compute elements, storage infrastructure, databases and networking.
Most other cloud providers follow a similar model to Microsoft's and Amazon's. CenturyLink has a published shared responsibility model that also includes secure coding as one of its core responsibilities. Google does not have a public site or document describing its shared responsibility model for the Google Cloud platform, but it does have a document specifically outlining shared responsibility in its cloud for meeting PCI DSS compliance. All cloud providers are wholly responsible for physical security of their data center environments.

What's missing from the shared responsibility model?

One area that shared responsibility models rarely cover is in security processes and workflows. For example, who is responsible for what aspects of incident response in the cloud? Microsoft attempts to address this in another recently published whitepaper that describes its concept of shared responsibility for incident response. For any areas of customer responsibility -- within a VM running in the Azure IaaS cloud, for example -- Microsoft does not perform intrusion monitoring or incident response. For Microsoft's areas of responsibility, it details the roles and responsibilities of all team members, as well as notifications and communications for each stage and steps taken within the internal incident response teams.

Currently, most other providers offer little guidance in the way of security process responsibilities, leaving this somewhat of a mystery to many until contracts are reviewed. Hopefully, more large providers will follow Microsoft's lead and document all responsibility aspects of both security controls maintenance and security processes and workflows in the near future.