Shared responsibility on the cloud: a solution for managed services or opacity for cloud customers?
The cloud utility has been built. We are in a post-cloud world. Now that the hardware foundation of the cloud has been laid down, managed services have emerged as the future mode of cloud consumption.
As hardware is broken up and offered as specific software primitives, or managed services by CSPs, cloud customers move further away from the underlying hardware layer. Increasingly, the cloud is consumed as a software utility, not a hardware utility. Led by CSPs blending the lines between IaaS, PaaS, and SaaS, customers are now being abstracted away from the underlying layers of the technology stack. More abstraction means greater customer convenience but less control.
To grapple with the increase of abstracted services, CSPs provide the concept of Shared Responsibility, an idea Microsoft and AWS, in particular, have pioneered since the 2000s. Shared Responsibility essentially outlines which compliance liabilities associated to which abstractions are taken on by the CSP versus the customer of the CSP. AWS elegantly delineates their responsibility as Security of the Cloud while AWS customers are responsible for Security in the Cloud. Microsoft lists obligations across seven definable and easy to understand tiers. All told, CSPs take on the responsibility of the physical layer, like data centers, while prompting customers to meet compliance requirements at the operating system level and higher.
Shared Responsibility leads to inheritance
With Shared Responsibility, a concept emerges in cloud compliance today called control inheritance. The concept, pioneered by HITRUST, is now generally accepted as a model for approaching the different layers of the cloud technology stack and the responsibility of controls therein. While still early and not yet universally adopted, control inheritance helps organizations to ensure full-stack compliance. Control inheritance explicitly addresses the need to inherit certain security and compliance controls in layers managed by third parties, in this case CSPs and cloud services providers.
The easiest control inheritance example is physical security. In every compliance regime multiple requirement exist on the physical security for technology assets. CSP data centers have physical security controls, such as badge ID or biometric authentication, to prevent unauthorized access to physical technology assets. When CSP customers leverage those data centers for IT resources, those customers inherit the physical security controls of the CSPs.
While physical security is the easiest example, the abstracted nature of the cloud today makes inheritance of some compliance controls a bit murky. Additionally, some compliance requirements, such as access controls, are multi-layer across the technology stack, meaning some of the responsibility for access controls falls to the cloud providers and some fall to the cloud customers. To account for this, different types of inheritance can now be found.
Complete Inheritance. In this case, the entire control is inherited by the cloud customer. Physical security is a good example.
Partial Inheritance. With this type of inheritance, the control at some layer of the technology stack is managed by the cloud provider and at other layers the control is managed by the cloud customer. Access controls and password management are a good example because those controls are spread across the entire cloud environment.
No Inheritance. The cloud customer is fully responsible for the compliance control. Workforce training is an example of this.
While HITRUST has control inheritance baked into the CSF, it has beenrather informal in most cases. The most common scenario for inheritance is when a CSP, or consultant or other cloud service provider, completes a security questionnaire for an audit or a customer and takes responsibility for a specific control. This is not a very powerful use of inheritance and the subtlety of the informal nature is lost on most organizations.
The future of compliance inheritance should be more explicit. Organizations should attest to ownership of compliance controls, either partially or completely, with an explicit tie to privacy agreements and liability.
Sharing the (work)load
Without question, employing the Shared Responsibility model is the best way to identify compliance responsibilities with cloud workloads.
The key challenge for cloud users is the space between the physical layer at the bottom and the end user of applications at the top. Effectively, the entirety of the operating system layer, along with all managed and microservices on top of it, is the responsibility of the CSP customer. This stark realization should prompt the new reality of compliance on the cloud: the cloud is increasingly becoming software-based, but CSPs inherently do not own risk at the operating system level and higher.
HITRUST just announced it’s own HITRUST Shared Responsibility Program and our hope is that it addresses some of these gaps in CSP shared responsibilities model. We’re very excited to learn more as this program gains adoption.
