For IT tech guys to understand the shared responsibility model of cloud services is however one of the most important aspects of cloud security. Oh yes, knowledge of this model allows organizations to operationalize security programs rooted in a proper understanding of what resources and settings they have control over and visibility into once they migrate to the cloud. While the shared responsibility model is not new, it is often a lesson that companies new to the cloud may learn the hard way.
This is usually through the painful process of reactively addressing data leaks, breaches, and cloud misconfigurations. This is a fact not just borne out in headlines, but by statistics revealed by groups like Gartner suggesting that through 2025, 99% of all cloud security failures will be the customer’s fault.
With COVID-19 accelerating the need for cloud technologies, organizations no longer have the luxury of delaying cloud adoption until some hypothetical point in time when they deem the cloud safe. Thoroughly understanding the shared responsibility model will allow teams to confidently adopt cloud technologies and work more effectively with their cloud service providers.
Where does the shared responsibility model come from?
The shared responsibility model is a cloud service provider’s way of addressing major cloud security concerns. Providers like AWS have led the way in setting the expectations for customers regarding the infrastructure and practices used to provide cloud services. Just like companies have standards for their on-prem assets–from the servers they install to the maintenance of the software running on these servers–the shared responsibility model illustrates that cloud providers take into account these same considerations when delivering their services.
What is the shared responsibility model?
As lcan be seen above, the shared responsibility model is the splitting of security and compliance responsibilities between a cloud service provider and its customers. As a matter of fact, this can generally be broken into two aspects:
- Security of the cloud. This simply refers to the processes, practices, and procedures that cloud service providers conduct to secure the assets they use to deliver cloud services. Good Examples of this include physical security and access, as well as managing the network protocols, uptime, and anything else having to do with physical and network level operations. For a full list of what types of security and operational practices a cloud service provider offers, check their documentation.
- Security in the cloud. This second part refers to security within the cloud environment itself. Some Examples of this may include application access permissions and security, as well as any tools used to provide protections to data at the application layer.
The division of cloud security into these two areas of responsibility is not an afterthought for cloud security providers; it stems from the fact that providers do not have visibility within customers’ environments. Their visibility ends at the hypervisor, the space where users’ operating environments are partitioned within a host machine. Customers have visibility beyond the hypervisor at the operating system and application levels, which means that it has to be their job to deploy the appropriate settings and tools to secure their data and environments.
Does the shared responsibility apply to SaaS cloud services as well?
The shared model absolutely applies to SaaS applications as well as public cloud environments. Within SaaS environments, the responsibilities don’t map in the exact same way as they do within IaaS environments, with SaaS providers taking responsibility for things like application security. But even here customers must take responsibility for application permissions and settings, as well application data itself.
Related Internet searches
- what is aws trusted advisor?
- in the shared responsibility model, for which aspect of securing the cloud is aws responsible?
- aws shared responsibility model white paper pdf
- what aws service is best suited for storing objects?
- saas shared responsibility model
- who is responsible for security of the cloud according to the shared responsibility model
- cloud security shared responsibility model
- under the shared responsibility model, which of the following is better?
Putting the shared responsibility model into action
What does the shared responsibility model look like in action? Whether you’re using SaaS or IaaS platforms, there are three key must-haves that matter when it comes to securing your cloud environments.
You have to understand configurations and accessibility settings appropriate for your data
All cloud services and applications have default security, permissions, and privacy settings that will impact who has access to your data and what security controls are in place within your environments. Furthermore, it is your organization’s responsibility to determine whether these default settings are sufficient for meeting its specific security and compliance requirements. For example, if teams within your organization have recently adopted Slack due to COVID, it might make sense to harden the application by enforcing 2FA, and limiting what applications users can install within Slack.
In a like manner, these considerations are even more important when it comes to IaaS security. Take for explanation, a 2018 study found that of the AWS S3 Buckets that are publicly available, almost 40% are at least partially writable or readable. So, adopting practices like the principle of least privilege and having an understanding of how to secure your credentials are going to be critical. This is to make sure you modify security defaults to appropriately reflect your organization’s security requirements.
You have to understand the appropriate uses of your data in a given environment
Setting and carefully configuring your permissions and security settings are a significant part of improving your organization’s security posture in the cloud. On the other hand, doing this is only half the battle. In the light of this, for you to combat insider error and insider threats. In a word, it’s critical that security teams develop an understanding of behaviors and activities that potentially violate data policies and leverage tools. This includes like data loss prevention, that can detect and prevent these from taking place.
You have to have eyes on your data at all times
Ensure that your organization has documentation surrounding its security and data governance policies and these policies are readily accessible to employees. Do not forget that it is important that security teams understand that in order to enforce these policies they need to have eyes on data in the cloud. You need tools that automate data classification as well as data policy violation enforcement are a way to ensure you know what data you have and where it is. It should be able to respond quickly and effectively to incidents threatening the confidentiality of that data.
Stick to best practices for shared responsibility model enablement
We wrote a post titled “Deriving best practices from a security-first, cloud native mindset” we highlighted best practices for keeping a security-first mindset top of mind as your organization migrates to the cloud. In sequential with leveraging best of breed cloud-native security tools that allow your security team to automatically enforce policies in the cloud, this mindset will help your organization abide by the shared responsibility model as it adopts new cloud services.
