The RNC Data Exposure: Learnings and Actions to Take

By Natalie Walsh

RNC Data Exposure Blog Banner.png

Recently, headlines were hyping the largest ever exposure of voter information, involving some 9.5 billion data points related to 198 million U.S. voters.

Attention-getting stuff. And since the story involved the Republican National Committee (RNC), the hype was intensified. Somewhat imprecisely, many articles characterized the incident as a data “leak”, “breach”, or “compromise” — again, adding to the intensity, but not the accuracy of what actually happened.

I’m not trying to minimize the seriousness of the issue — the potential damage was enormous as were the implications regarding security and privacy. But now that some of the dust has settled, it’s time to back away from the headlines and explore what actually happened.

So let’s see what we can learn from the RNC data exposure — and more importantly — what we can and must do to better protect our data and systems going forward.

Note: Some excellent post-incident analyses and commentaries have been published, including:

Who, What, & When

This story has three main players: the RNC, UpGuard Inc., a security firm, and Deep Root Analytics (DRA), a media analytics company that the RNC had hired to gather information about U.S. voters during the 2016 presidential campaign.

On June 12, Chris Vickery, a security analyst with UpGuard, discovered an open cloud repository that was left exposed by DRA and remedied the problem on June 14. To quote the UpGuard report:

“The data repository, an Amazon Web Services S3 bucket, lacked any protection against access. As such, anyone with an internet connection could have accessed the Republican data operation used to power Donald Trump’s presidential victory, simply by navigating to a six-character Amazon subdomain: “dra-dw”.”

A key point is that the report does not contain any reference to data having been downloaded for mal intent.

The Fundamental Problem

What’s unsettling about this story is the fact that the mis-configuration that caused the data exposure is extremely common and could have been addressed with a few basic AWS security steps.

In a recent survey that Threat Stack conducted, we found a surprising number of well-documented security misconfigurations:

  • Among the most egregious were AWS Security Groups configured to leave SSH wide open to the internet in 73% of the companies analyzed. This simple configuration error allows an attacker to attempt remote server access from anywhere, rendering traditional network controls like VPN and firewalls moot. In fact, Threat Stack observed SSH traffic from the internet using the root account, which could have severe security repercussions.
  • Additionally, the well-recognized best practice of requiring multi-factor authentication (MFA) for AWS users was not being followed by 62% of companies analyzed, making brute force attacks that much simpler.
  • Even AWS-native security services, such as CloudTrail, were not being deployed universally (27%) across all regions.

As Sam Bisbee, Threat Stack’s CTO, has stated: “The most surprising part of these findings is that, for all the money that sophisticated enterprises spend on advanced security, a majority aren’t Go to the full article.

Source:: Business 2 Community

Be Sociable, Share!