Voter registration data breaches have come and gone without the public batting an eye in the past, but tensions around foreign election intervention and political data analytics will stoke concerns around the latest incident. Nearly 200 million Americans fell victim to a data breach at a marketing firm called Deep Root Analytics contracted by the Republican National Committee. The leaked data includes names, home addresses, birthdates, and phone numbers. The earliest records date to 2012, and the most recent come from January 2017, after the presidential election.

Voter registration database breaches have become common in the age of digital records. In 2015, 191 million records were found exposed to the public online in a similar incident reported by the same researcher, Chris Vickery. Last year, 94.3 million Mexican voter records were publicly exposed on Amazon Web Services.

What makes this case unique among voter registration breaches is the data analysis conducted by Deep Root. The firm analyzes public data to create profiles for individuals, modeling probable responses for fields like ethnicity and religion that voters do not directly provide. The records also include ratings for individuals based on their likelihood of voting for specific policy initiatives. In a political climate where many may prefer to keep their political allegiances discreet, this data exposure leaks far more information than simple political party membership. It also raises the question of whether public information can be combined and analyzed to create sensitive data.

An Accidental Inside Job

Nation-state hackers and zero-day vulnerabilities capture the imagination with menacing narratives, but this incident illustrates how easily human error can lead to a catastrophic breach. The information was publicly available in an Amazon Web Services S3 bucket. Deep Root states that the information became available because of a change in security settings on June first.

Data exposures like this occur all the time. In fact, in February, we authored a blog detailing this exact scenario as one of the top 3 reasons companies needed to use a Cloud Access Security Broker (CASB) to protect their data living in IaaS systems like AWS, Azure, and Google Cloud Platform. In that instance, we shared that:

“Highly valuable intellectual property was stored in an S3 bucket that was publicly accessible, in violation of internal policies.”

In this example, a commercial company had millions of dollars of IP housed in a publicly accessible S3 bucket – just as DRA had millions of voter records housed in a publicly accessible S3 bucket. These types of exposures make it possible for any person to access your data without any hacking required.

In the commercial example we cited, the customer told us this data would have given a foreign national government or a competitor the information to catch up on decades of research had they discovered this publicly exposed data and resulted in millions if not billions of dollars of lost revenue over time. Fortunately the exposure was discovered and rectified before that was possible.

Mind the Shared Responsibility Model

These examples highlight the differing responsibilities required by an organization when using IaaS vs. SaaS per the shared responsibility model. For SaaS services like Salesforce, O365, and ServiceNow the customer is responsible for guarding securing app usage and data. But with IaaS systems like AWS, Azure, and Google Cloud Platform, the customer is responsible for securing the configuration and usage of the IaaS environment.

For example, with AWS the customer owns the responsibility of ensuring that S3 buckets are encrypted and not publicly accessible as highlighted in this example. The customer is responsible for enabling CloudTrail monitoring, and then using that data to monitor activity and detect insider threats or compromised accounts. The customer is also responsible for ensuring MFA is required for root account access, and the list goes on…

Two Steps to Ensure This Never Happens to Your Company

With all of the possible configuration settings available and the vast number of Amazon services used across an enterprise, ensuring that security loopholes like this don’t exist can seem like an impossible task, but CASB makes it quite simple.

Here are the 2 foolproof ways to ensure this doesn’t happen to you:

1) Know where your sensitive data is: Companies use Skyhigh’s CASB to perform DLP across their IaaS services. Customers create DLP policies based on data identifiers, keywords, and structured/unstructured fingerprints to identify where their sensitive data is so they can apply appropriate controls to ensure the security of that data. With this knowledge you can pinpoint any S3 bucket that contains sensitive data and ensure it is adequately protected.

2) Audit your security configurations in AWS: AWS provides an extensive set of security configuration options for all their services. Companies use Skyhigh’s CASB to monitor over 70 AWS security configuration settings across all AWS instances and flag those that are non-compliant with an enterprise’s ISMS controls and the risk profile of the IaaS deployment. In addition, Skyhigh provides recommendations an in-product remediation platform, so customers can eliminate security loopholes they discover during the audit.

In the realm of security, these are some of the simpler exposures to prevent. If you’d like to learn more about common AWS security challenges, best practices for securing AWS and the custom applications running on AWS, and how CASBs can help you enforce your security and compliance requirements for AWS, download the definitive guide to AWS Security eBook here.