Cloud and the shared responsibility model misconceptions
One of the most common concepts working with cloud services is the “Shared responsibility mode”.
The model is aim to set the responsibility boundaries between the cloud service provider and the cloud service consumer, depending on the cloud service model (IaaS, PaaS, SaaS).
In this post, I will review common misconceptions regarding the shared responsibility model.
Misconception #1 — My cloud provider’s certifications allow me to comply with regulations
This is a common misconception for companies (and new SaaS providers) who fail to understand the shared responsibility model while deploying their first workload.
Reviewing cloud providers’ compliance pages, we can see that the providers have already certified themselves for most regulations and local laws, and in some cases even offer customers special environments that are already in compliance with regulations such as PCI-DSS or HIPAA.
If you are planning to store sensitive customers’ data (from PII, healthcare, financial, or any other types of sensitive data) in a public cloud, keep in mind that according to the shared responsibility model, the cloud provider is responsible only for the lower layers of the architecture:
· IaaS — the CSP is responsible for all layers, from the physical layer to the virtualization layer
· PaaS — the CSP is responsible for all layers, from the physical layer to the guest operating system, middleware, and even runtime
· SaaS — the CSP is responsible for all layers, from the physical layer to the application layer
Bottom line — the fact that a CSP has all the relevant certifications, means almost nothing when talking about compliance with regulations or protecting customers’ data.
Each organization storing sensitive data in the cloud must conduct a risk assessment, review which data is stored in the cloud (before storing data in the cloud), and set the proper controls to protect customers’ data.
Misconception #2 — Who is responsible for protecting my data?
When customers (either organizations or personal customers) store their data in public cloud services, they sometimes mistakenly think that if they store their data in one of the major CSPs, their data is protected.
This is a misconception.
All major CSPs offer their customers a large variety of services and tools to protect their customers’ data (from network access control lists, encryption in transit and at rest, authentication, authorization, auditing, and more), however, according to the shared responsibility model, it is up to the customer (mostly organizations storing their data in the cloud), to decide which security controls to implement.
In most cases, the CSPs don’t have access to customers’ data stored in the cloud, whether organizations decide to use managed storage services (from object storage to managed CIFS/NFS services), managed database services (from relational databases to NoSQL databases) and more.
The most obvious exception to the mentioned above is SaaS services, where we allow CSP service accounts access to our data, to allow us to perform queries, get insights about our data or even perform regular backups — the access is mostly strict to specific actions, to a specific role or service account, and usually shouldn’t be used by the CSP employees.
At the end of the day, the customer is always the data owner, and as a data owner, the customer must decide whether or not to store sensitive data in the cloud, who should have access to the data stored in the cloud, what access rights do we allow people to access and update/delete our data, and more.
Misconception #3 — Availability is not my concern since the cloud is highly available by design
The above headline is true, mainly for major SaaS services.
When looking at availability and building highly available architectures, specifically in IaaS and PaaS, it is up to us, as organizations, to use the services and the service capabilities that CSPs offer us, to build highly available solutions.
Just because we decided to deploy our application on a VM or store our data in a managed database service, but we failed to deploy everything behind a load-balancer or in a cluster, will not guarantee us the availability that our customers expect.
Even if we are using managed object storage services and we choose a low redundancy tier, using a single availability zone, the CSP does not guarantee high availability.
To achieve high availability to our workloads, we need to review cloud providers’ documentation, such as “Well architected frameworks” and design our workloads to fit business needs.
Misconception #4 — Incident response in the cloud is an impossible mission
This part is a little bit tricky.
Since as AWS always mention, they are responsible for the security of the cloud — they are responsible for the incident response process of the cloud infrastructure, from the physical data center, the host OS, the network equipment, the virtualization, and all the managed services.
We, as customers of cloud services, are responsible for security within our cloud environments.
In IaaS, everything within the guest OS is our responsibility as customers of the cloud.
It is our responsibility to enable auditing as much as possible, and send all logs to a central log repository and from there to our SIEM system (whether it is located on-premise or in a managed cloud service).
There are also documented procedures for building a forensics environment, made out of snapshots of our VMs or databases, for further analysis.
It is not perfect; we still don’t control the entire flow of the packet from the lower network layers to the application layer, and on managed PaaS services we only have audit logs and we can’t perform memory analysis of managed services (such as databases).
In SaaS services, it gets even worse since, in at best case, the SaaS provider is mature enough to allow us to pull audit logs using API and send them to our SIEM system for further analysis — unfortunately, not all SaaS providers are mature enough to provide us access to the audit logs.
Bottom line — challenging, but not completely impossible. Depending on the cloud service model and the maturity of the cloud provider.
Summary
It is important to understand the shared responsibility model, but what is more important is to understand the cloud service model and services or tools available for us, to enable us to build secure and highly available cloud environments.
References
· AWS Compliance Programs
https://aws.amazon.com/compliance/programs
· Azure compliance documentation
https://docs.microsoft.com/en-us/azure/compliance
· GCP Compliance offerings
https://cloud.google.com/security/compliance/offerings
· AWS Well-Architected Framework
https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
· Forensic investigation environment strategies in the AWS Cloud
https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud
· Computer forensics chain of custody in Azure
https://docs.microsoft.com/en-us/azure/architecture/example-scenario/forensics
About the Author
Eyal Estrin is a cloud and information security architect, the owner of the blog Security & Cloud 24/7 and the author of the book Cloud Security Handbook, with more than 20 years in the IT industry.
You can connect with him on Twitter and LinkedIn.
