Earlier this month, 36 million 
records 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.
