Skip to content ↓ | Skip to navigation ↓

Over the past few months, the security industry has witnessed several major cloud data breaches. The Deep Root Analytics leak sent shockwaves across the cybersecurity community in June, as sensitive information on 197 million American voters was exposed.

A few weeks later, data on six million Verizon users was exposed by Nice systems, a third-party vendor working with Verizon. Before the dust had settled on that breach, personal information of 2.2 million Dow Jones customers was leaked a week later.

In the past, when information technology was deployed on-premises, the enterprise held sole responsibility for securing its IT infrastructure. The advent of the cloud has required a new paradigm for IT security. While enterprises still need to apply the same set of security controls to the cloud as they had on-premises, they now have a partner that they must rely on for part of the security.

The three leaks above have a few traits in common. They all occurred due to publicly available AWS S3 buckets, but more importantly, all three leaks were caused by human error on the customer’s part.

Cloud security’s shared responsibility model at a glance

CSPs have worked hard to develop their security capabilities. Providers are generally large companies with dedicated teams to securing their infrastructures and products, something that the typical enterprise can’t match in terms of resource dedication.

As an example, Microsoft has consistently spent over $1 billion per year on improving the security of its products. Salesforce, on the other hand, continues to expand the security of its SaaS platform with the introduction of Salesforce Shield. Box, for its part, released its data classification feature in 2016 to further empower customers with critical security capabilities.

The CSPs, generally speaking, are responsible for the security “of” their SaaS, PaaS and IaaS products. More specifically, they protect the underlying infrastructure of the service from threats, vulnerabilities, abuse and fraud. They’re also responsible for providing their customers with key security capabilities, such as data encryption at rest, identity and access management and multi-factor authentication.

The customers are responsible for the security “in” the cloud, which includes proper configuration of the security features, installing updates and ensuring employees aren’t exposing sensitive data to unauthorized parties. There is some overlap, specifically around compliance requirements, but for the most part, the provider and customer have separate responsibilities.

This relationship is known as the shared responsibility model, and it is the basis for how modern cloud security operates.

Security “in” the cloud

As data continues to move to the cloud, it is incumbent on the customer to ensure that they continue to meet their security, governance, and compliance requirements. The CSP may be able to protect against brute-force login attempts, for example, but it’s the customer’s responsibility to ensure that employees use unique and secure passwords across all cloud services to minimize the risk of an account compromise.

And while the cloud can simplify sharing and collaboration, the CSP can’t be held responsible for when the customer accidentally shares sensitive data to third-parties in a non-compliant manner. Protection against internal malicious users (i.e. employee downloads all records in Salesforce right before leaving for a competitor) also falls in the domain of the customer.

Lastly, properly configuring the myriad of native security capabilities (DLP, access control, activity monitoring) and following basic security best practices is yet another area that the cloud service customer is responsible for.

Case in point, AWS recommends that users should only be given the least amount of privileges that still allows them to fulfill their job duties. There is nothing AWS can do to protect its customers if they unnecessarily provision users with admin privileges.

Security “of” the cloud

CSPs have the responsibility to ensure that their infrastructure is free from vulnerabilities. They’re also responsible for the physical security of the cloud service and ensuring that unauthorized physical access to the hardware or software is prevented, as well as disaster and incident response.

Disaster and incident response includes two main areas. The first one is business continuity management, which means that the CSP has to ensure availability and incident response. Essentially, the service has to be up and running, and if anything goes wrong, the CSPs have to work to fix it.

The second category includes accounting for environmental or unpredictable scenarios. This includes securing the data centers against power outages, floods, earthquakes and other disasters.

If you delineate this further, you’ll find key differences between what a SaaS provider is responsible for vs PaaS and IaaS providers. For SaaS and PaaS, much of the network access controls are set up by the CSP. For IaaS, however, network controls are controlled by both parties.

AWS, for example, provides its customers with a service known as AWS security groups. Security groups are equivalent to firewalls to control network traffic. AWS customers are responsible for properly configuring the security groups, so that they’re not exposing themselves to a DDoS attack. 

Looking ahead

While it is true that CSPs like AWS or Microsoft Azure have their own security responsibilities, the truth is that data breaches will continue to occur unless organizations using cloud services collectively fulfill their end of the relationship.

 

Ajmal Kohgadai

About the Author: Ajmal Kohgadai is an associate product marketing manager at Skyhigh. He combines product marketing, database marketing, content creation, advertising, and analytics. He generally splits time between finding new ways of educating the business community about mobile marketing, while trying to understand the profound and irreversible impact mobile technology is having on society.

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.

['om_loaded']
['om_loaded']
<!-- -->