Starting with version 9 of the CSF, HITRUST introduced the related concepts of shared responsibility and control inheritance. Both concepts were incorporated into the CSF to address the growing demand from cloud providers and cloud customers for a better way to manage compliance controls on the cloud. The concept of cloud shared responsibility has gained adoption rapidly over the last 5-7 years. A basic understanding of cloud infrastructure is important to understand shared responsibility and how it is used in the HITRUST CSF.
☁️ For the purposes of this lesson, "cloud" is synonymous with public cloud services offered by Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).
The cloud as a computer in somebody else's data center is not accurate today. AWS, Azure, and GCP deliver cloud infrastructure to cloud customers as software, not hardware. This software allows cloud customers to interact with and leverage physical infrastructure (processors, storage, transmission, etc.) on demand.
The software layer that cloud providers offer on top of physical infrastructure is a layer of abstraction. This layer of abstraction prevents cloud customers from accessing the physical infrastructure directly. And, as cloud providers have launched more and more specialized cloud services, cloud customers are being abstracted further and further from the underlying infrastructure. Most cloud services today abstract customers completely from the physical and operating system levels and partially from the networking and software package levels. Abstraction opens up interesting issues when it comes to compliance.
In order to become HITRUST Certified, or complete a PCI, GDPR, SOC 2, and most other types of security audits, a company needs to attest to, and be accountable for, a set of controls. Cloud customers are abstracted away from the hardware, and increasingly the software, controls that are requirements for HITRUST (and other regulations).
🌩️ How do cloud customers take responsibility for controls when they have no access to the hardware or software where the controls reside? Enter shared responsibility.
Shared responsibility is the concept in which responsibility, in this case specifically for hardware and software layers in cloud services, are shared. It is now a widely accepted concept for cloud services. The problems with shared responsibility stem from 1) different cloud services having various levels of abstraction and 2) most cloud customers are running multiple cloud services. Compounding those problems in compliance is that most auditors are not very tech or cloud savvy.
The result is opacity and ambiguity at the level of control detail that would normally be required by auditors.
The HITRUST Shared Responsibility program attempts to solve the problems with shared responsibility on the cloud. HITRUST created the concept of control inheritance, or the ability to inherit controls from other vendors. The inheritance of controls is explicit, meaning that both companies, the one inheriting the control and the one allowing inheritance of its control, have to acknowledge the inheritance.
Let's use physical security as an example. Since cloud providers manage all of the physical security for their cloud offerings, an AWS customer doing a HITRUST assessment could choose to inherit each physical security control from AWS. This would happen in the CSF. An approved AWS HITRUST CSF user would then have to explicitly choose to allow that AWS customer to inherit those controls.
This goes a long way to resolving most of the opacity and ambiguity of shared responsibility. While it is not a perfect solution that addresses all cases of shared responsibility, it does help. Challenges remain based on the complexity of cloud environments and the constantly changing nature of cloud services.
HITRUST Shared Responsibility and CSF control inheritance specifically solve the challenge of accountability, transparency, and control of cloud infrastructure.