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 McAfee’s (formerly Skyhigh Networks) 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 McAfee’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, McAfee’s 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.
Will They Pay the Price? Probably Not
Deep Root Analytics accepted full responsibility for the leak but also took a relatively bold stance by declaring that all the exposed data was public information. The law may be on their side. Regulations on the confidentiality of voter registration data is piecemeal at best. South Dakota specifically prohibits public access to databases of voter data online, and California has restrictions on the use of voter information.
Foreign intervention in the US presidential election may have heightened the sensitivity toward the integrity of the democratic process, however. Experts called the Russian hack of the Democratic National Committee an attack on US democracy. Additional reports now show evidence of attempted compromise on local voting software in 39 states – a much more invasive and successful campaign than initially reported. Accidentally leaking data on millions of voters only reduces confidence in US democratic institutions and provides ammunition that can be used in targeting additional malicious intervention.
Cybersecurity incidents also played a role in the election in France; Emmanual Macron’s campaign suffered a data breach days before the election. Europe has set in motion much stricter regulation for companies with data on individuals. The European Union General Data Protection Regulation, set to come into law in under a year, will impose fines on companies that collect, share, or lose data on individuals without their approval. The scale of the breach and lack of preparedness can increase the fine, meaning Deep Root may have faced a substantial penalty if they were operating under the law. US consumers demanding accountability for data from political organizations after the past election may look to GDPR as a possible solution. At the very least, companies that analyze voter data overseas must prepare to comply with the law when it comes into effect in May of 2018.
About the Author
Categories: Cloud Security