MongoDB Data Breach: 3 Steps to Network Security

Last updated: 23 June 2016

Earlier this month, 36 million Network security breachesrecords from MongoDB databases were released publically online by the hacker group TeamGhostShell with the goal raising awareness of sloppy security practices. TeamGhostShell took advantage of database administrators misconfiguring their MongoDB environments and ignoring basic security best practices to gain access to sensitive data from 110 different servers.

The owners of these breached databases left ports open on their newly configured servers and require root authentication. To take and read this sensitive data, TeamGhostShell didn’t even need to elevate privileges. At stake were names (both real and user), passwords, browser information, geolocation information, API credentials, e-mail addresses, and more.

So, as we hear about security breaches on a daily basis, why does this one stand out?

It stands out because it was entirely preventable. Security isn’t always guaranteed in products right out of the out of the box. Even then, counting on your perimeter or closing ports is only an impediment to hackers and not a fool-proof method of securing your data. With so many layers of technology built on top of each other, from databases to firewalls, even the savviest administrator will find it difficult to understand their security coverage. Plus, vulnerabilities are discovered every day; even in the best of circumstances, organizations will find themselves at the mercy of holes in their defense they could never have anticipated.

Again we see that encryption is the last line of defense to keep data safe. It protects data and buys organizations margin of error when choosing technology solutions and the known and/or unknown vulnerabilities that they contain.

In the recent MongoDB hack, even TeamGhostShell mention encryption as a possible impediment to their activities. Gemalto’s 3 step approach to data protection would have prevented Team GhostShell from obtaining these 36 million records. Here’s how:

Step 1: Locate your data: Knowing where your data resides isn’t always just about knowing where to apply your encryption. It’s about taking a step back and thinking of the ways that your data is vulnerable at each touch point. In this instance, the database owners had an opportunity – if not an obligation – to think about the open ports on the database servers and close them.

Step 2: Encrypt the data: Scrambling data with encryption – either with MongoDB’s native encryption or a third-party solution such as SafeNet ProtectFile – would have protected data on the breached servers. Ultimately, the TeamGhostShell hackers would have only seen garbled data that would have been useless when downloaded. Even if the hacker were to find a way to earn root access, access controls built into encryption solutions such as SafeNet ProtectFile would have separated duties such that the root server administrator would not have access to clear-text data.

Step 3: Proper key management: In this instance, proper key management would have kept the necessary decryption keys stored in a separate appliance available only to the security administrator. Full root access to the MongoDB server wouldn’t have yielded the secret required to render the data in clear text. Additionally, access controls layered on top of the encryption would have strengthen the separation of duties between the server and security administrators further protecting the data.

Breaches occur daily, but there are ways to mitigate these risks! These 36 million records could have been protected through due diligence and a more earnest approach to security. Gemalto and MongoDB work together to offer customers the data protection and key management solutions they need to keep their data safe from hackers and privileged users looking to exploit known and unknown vulnerabilities in network security.

For more information visit the MongoDB page on our website. Or, if you prefer to talk to us in person, we will be at MongoDB World 2016 on June 28 & 29. Come visit us at booth #9 to learn how we can secure MongoDB databases with our solutions and in support of MongoDB’s native encryption.

One thought on “MongoDB Data Breach: 3 Steps to Network Security

  1. Check Your Firewall: A firewall provides protection for your network by blocking unauthorized access while still permitting approved communications. Make sure that you have one and that it is current, meaning that everything is being automatically patched and updated on a consistent basis. While you are at it, check that these updates are being applied regularly to your firmware as well.
    Emphasize Password Strength and Best Practices: Cyber criminals often gain access to networks through hacking employees’ passwords. To combat this, make sure your employees know the ins and outs of creating strong passwords (ones that are lengthy, use multiple characters, and are unique to that account). A little education can go a long way in securing one of cyber criminals’ easiest access points.
    Ensure Remote Access Mechanisms are Secure: Your employees need to be able to work remotely. We get it. But remote access is a gateway drug to a serious data sprawl problem. If your employees are accessing your network from multiple devices on connections that are not secure and sharing files to other users doing the same things, you are offering access to your network up on a silver platter to cyber criminals. The three safest ways to access your network remotely are through a remote login solution, a virtual private network or a terminal server/citrix (basically a cloud environment that securely delivers your desktop to you wherever you are). Although this might take a bit of work to get right up front, the encryption/security features will be inherent to the solution, once implemented. A robust solution will also eliminate the need for employees to use personal Dropbox accounts or email documents to themselves which, in turn, eliminates the risk of data sprawl.

Leave a Reply

Your email address will not be published. Required fields are marked *