Aaron’s protects data in custom applications built on ServiceNow with the Developer Platform – Watch the story.
Keeping the Shared Responsibility Model in Mind When Adopting AWS (and Other Cloud Services)
Understanding the shared responsibility model of cloud services is perhaps one of the most important aspects of cloud security. 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.
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.
As lightly touched on above, the shared responsibility model is the splitting of security and compliance responsibilities between a cloud service provider and its customers. This can generally be broken into two aspects:
- Security of the cloud. This refers to the processes, practices, and procedures that cloud service providers conduct to secure the assets they use to deliver cloud services. 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. Examples of this 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.
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.
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. 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.
These considerations are even more important when it comes to IaaS security. For instance, a 2018 study found that of the AWS S3 Buckets that are publicly available, almost 40% are at least partially writable or readable. Adopting practices like the principle of least privilege and having an understanding of how to secure your credentials are going to be critical for making 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
Configuring your permissions and security settings are a significant part of improving your organization’s security posture in the cloud; however, doing this is only half the battle. In order to combat insider error and insider threats, it’s critical that security teams develop an understanding of behaviors and activities that potentially violate data policies and leverage tools, like data loss prevention, that can detect and prevent these from taking place.
You have to have eyes on your data at all times
Even assuming your organization has documentation surrounding its security and data governance policies and these policies are readily accessible to employees, it’s important that security teams understand that in order to enforce these policies they need to have eyes on data in the cloud. Tools that automate data classification as well as data policy violation enforcement are a way to ensure you know what data you have, where it is, and can respond quickly and effectively to incidents threatening the confidentiality of that data.
In our guest post for ITProPortal 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 tandem 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.
Nightfall is a best of breed cloud-native data loss prevention platform that can automatically discover, classify, and protect data within SaaS and IaaS cloud environments. With over 100+ machine learning detectors for sensitive data and customizable remediation workflows, Nightfall is an easy to deploy cloud security solution that can quickly address data leakage within platforms like AWS, Slack, Jira, and many others. Learn more by scheduling a demo with us below:
Subscribe to our newsletter
Receive our latest content and updates
Nightfall is the industry’s first cloud-native DLP platform that discovers, classifies, and protects data via machine learning. Nightfall is designed to work with popular SaaS applications like Slack, Google Drive, GitHub, Confluence, Jira, and many more via our Developer Platform. You can schedule a demo with us below to see the Nightfall platform in action.
Schedule a Demo
Select a time that works for you below for 30 minutes. Once confirmed, you’ll receive a calendar invite with a Zoom link. If you don’t see a suitable time, please reach out to us via email at email@example.com.