This is the second in our Ionburst blog series overviewing the challenges and benefits of Cloud object storage. It considers data privacy and security concerns, highlights examples of Cloud object storage leaks, and describes how a new paradigm of emerging solutions such as Ionburst innovatively apply security, resiliency and privacy technologies alleviate these Cloud-specific challenges to give organisations comprehensive control of their data privacy, recovery and security.

This short series covers:

  1. Setting the scene: Data privacy implications for Cloud object storage and the Shared Responsibility Model;
  2. The problem of how Cloud object storage leaks happen: A look at data compromise in the Cloud and examples of how, why and the extreme impacts which can occur;
  3. A solution: How Ionburst uniquely plugs the gap in the Cloud data privacy model by enabling customised organisational control over data privacy and security.

In our first blog we introduced the subject of Cloud object storage, the security concerns and breaches that plague it, and the grey area of accountability created by the Shared Responsibility Model.

This blog will explain how cloud storage typically works, using Amazon S3 as an example. We’ll then dig into some recent examples of public Cloud data breaches, their scale and impact, and the data they exposed.

The scale of the problem

The escalation of data breaches in the Cloud is unprecedented. The IT Governance “List of data breaches in 2019,” notes a staggering 425% increase in compromised records from 2018, from 2 billion to 12 billion records. The report notes that more than two-thirds, 8.5 billion records, were due to internal error. As we highlighted previously, the vast majority, if not all Cloud storage leaks result from misconfigured access policies, rather than an underlying vulnerability in the Cloud platform.

Critically, because Cloud storage simplifies the process of storing data for everyone, compromised data spans a wide range of use cases, industries and levels of sensitivity.

Cloud storage security: a guide

To understand how Cloud storage exposures, result in breaches, we should first look at how Cloud storage services work. While no Cloud platform is immune to breaches, Amazon, Simple Storage Service, or “S3,” is by far the most widely used, so we will use this as our example.

S3 is a Cloud object storage service, accessible over the internet by AWS web console, API and a variety of SDK and client interfaces. Data is arranged and stored in “buckets,” through which AWS offers a practically unlimited repository in which to store files or objects.

The first key point to consider for S3, is that each bucket name is globally unique across the whole S3 service, not just by account or region. Buckets are exposed to end-users and applications as a web endpoint, like a website, so no bucket can share the same name.

For example, if we had a bucket named “ionburst-blog”, created in the Dublin region on AWS, it would use the following address:

This enables S3 users and AWS customers to interact with their buckets. However, it also provides malicious actors and security researchers a mechanism to identify public S3 buckets and interact with them in the same way.

The second key point relates to S3 bucket access control security. Bucket and object security are controlled through two security mechanisms: (1) Access Control Lists (ACLs); and (2) Bucket Policies.

ACLs allow access to be controlled and defined at a bucket, or individual object level. Access can then be defined at multiple levels:

  • Bucket owner – the AWS account that owns the bucket;
  • Other AWS accounts – allow access to other AWS accounts;
  • Public access – allow public/anonymous access.

Each level can be assigned a number of permissions:

  • List objects – the ability to list the objects within the bucket;
  • Write objects – the ability to create, or delete objects within the bucket;
  • Read bucket permissions – the ability to read the bucket ACL;
  • Write bucket permissions – the ability to modify the bucket ACL.

Bucket and object ACLs were original security features for controlling access to S3 buckets, Newer methods followed, like Bucket Policies now available. However, if not used carefully, ACLs can drastically impact the security of S3 buckets.

That’s because ACLs have a feature called “predefined groups” that allows access to be granted simply and quickly. These groups are poorly scoped from a security point of view and their configuration should generally be avoided, as follows:

  • Authenticated Users – while it may seem sensible initially, this group allows anyone with an AWS account to access the bucket or object;
  • All Users – allows access to any AWS account, and to anonymous requests;

Bucket Policies are the newer, preferred method to secure S3 buckets and to offer more granular control over a bucket and its objects. This comes at an inevitable cost of added complexity, from a myriad of permission options and via the JSON-based policy language.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "PublicRead", "Effect": "Allow", "Principal": "*", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::ionburst-blog/*" ] } ] }

This policy allows anyone access to every object in the bucket “ionburst-blog”. If this is confusing or hard to understand, that’s because it is. Creating and managing properly scoped S3 bucket policies can be a daunting, difficult task, even for experienced professionals.

To their credit, AWS have never allowed public S3 buckets to be created by default. As public data breaches have become more prevalent, AWS have added safeguards and clear visible warnings to discourage allowing public access.

But breaches still escalate. This is partly due to confusion. With multiple methods available to secure S3 bucket data, many organisations don’t have the knowledge or skills to decide which to use. They’re not necessarily aware of the Cloud vendors’ “Shared Responsibility Model,” which sets out their broad responsibilities, indicating a skills gap to be considered for organisations migrating to Cloud.

Then there’s complex requirements and use cases which make creating fully scoped policies a time-consuming task, and organisations often don’t have the resources or time available.

The bottom line is that granting public access just works.

It is the allow / chmod 777 / setenforce 0 of the Cloud world.

As is often the case, therefore, security concerns and considerations take a backseat to making things work. Unfortunately, in the Cloud world the risk of exposure is no longer constrained by the reduced blast-radius of an on-premise environment. It is amplified by the vast scale and on-demand availability of the public internet.

This, as we’ll soon see, can have dire consequences for the uninitiated.

Data analytics leads to unexpected PII exposure

Deep Root Analytics is a media specialist for political advert targeting. On 12th June 2017, researchers discovered an S3 bucket owned by the firm which publicly exposed 1.1 terabytes of detailed “personally identifiable information” (PII). The data contained unprotected PII relating to almost all registered US voters at the time, around 198 million individuals – 61% of the US population. This information exposed included:

  • Names;
  • Addresses;
  • Date of birth;
  • Demographic;
  • Political affiliation(s);

Due to the way S3 can be configured, the bucket and its data became accessible by anyone who knew how to search for open buckets. Thankfully, the researchers who discovered this open bucket reported it to US law enforcement. The bucket and the highly sensitive data within it were secured by the 14th of June 2017.

In a statement following the breach, Deep Root stated the data had been exposed following an update to security settings on the 1st June, exposing the personally identifiable information of 198 million US citizens for nearly two weeks. Deep Root thereafter hired a cybersecurity specialist that found no evidence the exposed data was accessed by malicious third parties.

However, the fact a simple misconfiguration was able to expose the PII of almost all American voters shows how precarious securing sensitive data in the Cloud can be, and the drastic scale at which data can be so easily exposed.

Customer and sensitive business data exposes commercial relationships and PII

Publicly exposed Cloud stores regularly expose the sensitive data held by organisations.

On May 13th, 2019, security researchers discovered three publicly accessible S3 buckets belonging to Attunity, a data management company. In contrast to the Deep Root Analytics example, the Attunity breach exposed highly sensitive information relating to Attunity customers. According to its website at the time, Attunity had over two thousand customers, including around half of the Fortune 100. This was corroborated by data exposed in the breach, which included a wide range of sensitive information:

  • Netflix database server authentication details;
  • TD Bank invoices;
  • Ford project planning details;
  • Around 1 terabyte of email and cloud storage backups;
  • Internal Attunity IT infrastructure details;
  • Attunity employee PII – suspected to include Social Security Numbers.

Attunity was notified on the 16th May, 2019, and its S3 buckets were secured by the next day. It’s unclear exactly how long the data had been exposed, but as the oldest files exposed were dated September 2014, the worst-case scenario is potentially two and a half years.

This is another example of how Cloud object store misconfiguration can result in massive scale, public exposure of PII and sensitive commercial information. In this case, sensitive details relating to Attunity’s internal operations and those of its customers were exposed, impacting its reputation… All through a simple misconfiguration.

Cloud storage leaks: the implications

The Cloud data store exposures summarised above related to large scale organisations with significant technology presences. Deep Root Analytics specialises in the structuring and analysis of large data sets. Attunity performs data management for large enterprise customers. Both require sophisticated technology skills to perform their business. If they can’t prevent their Cloud data from being exposed, things need to change.

In both examples, the personally identifiable information of individuals was exposed, breaching data privacy regulations. This can lead to identity theft, fraud and enable attack vectors like social engineering. The exposure of political preferences or voting intentions exposed in our first example could lead to trolling, doxing; the use of limited personal info to obtain further personal info, or even threats in the physical world like blackmail or intimidation.

The point is, if data is exposed and breached, its impact ripples significantly beyond the organization, like a stone landing in a pond. Those impacted beyond the organisation may be customers or patients or other “classified” or “unclassified” data. Organisations can of course asses risk and act accordingly. However, people are not so fortunate and comprise the unquantified cost of Cloud data exposures.

They may live in different countries to where their data is exposed. They likely won’t even know why or how their personal data is being used. Irrespective, they are people with real lives that can be disrupted by simple misconfigurations and oversight that expose their data…and their lives.

The leak of sensitive internal information also exposes organisations and their stakeholders to a wide range of threats. For example, details of internal IT infrastructure creates the potential for malicious actors to build an understanding of how to compromise an organisation and enables further attacks. It also potentially exposes sensitive, internal details to competitors and enables espionage, both corporate and potentially nation state.

Ultimately, the rapid escalation in Cloud storage leaks shows just how easy it is for hackers to compromise Cloud object storage where simple but critical configuration isn’t managed properly. That puts all sensitive information stored in Cloud stores at greater risk, as opportunistic hackers and researchers are spurred on by accelerated migrations but no sign of greater skills or understanding in Cloud data security.

Advanced persistent threats or zero-day exploits are redundant if organisations unintentionally leak the data themselves. Organisations are also exposed to data privacy regulation consequences, such as GDPR, along with the reputational and financial impacts that accompany data breaches.

The volume of data stored in the Cloud will grow fast. Despite our best efforts to protect this data, both as individuals and organisations, exposure is one simple mistake or misconfiguration away.

More worryingly, we might actually feel confident that our Cloud data is stored securely and privately, but equally have it exposed by the actions of a third party.

A new method of storing sensitive and private data in the Cloud is required, that removes the risk of object store misconfigurations by organisations and their third-party Cloud support providers. A method that combines provides assurance that data is stored securely and privately without creating additional management overhead.

That’s where emerging technologies like Ionburst will provide peace of mind.