A look into the MongoHQ breach
A recent security breach in MongoHQ (a MongoDB cloud services provider) left the company working hard to patch up security holes. Unfortunately common, this breach was only detected when one of MongoHQ’s customers (Buffer) realized they had been hacked.
Following the attack, MongoHQ did the right thing: they apologized to their customers, detailed their security flaws (some are quite staggering) and laid out what actions they are taking to mitigate security.
Although the actions that MongoHQ took do improve security, data service providers and customers should ask themselves if their data is ever secure enough.
Once the data provider is breached, its customers are the first to suffer. And when discussing service providers, “small” hacks have a potentially exponential effect. Once a single server has been breached, all of the databases and the customers that own them are breached.
You’re the weakest link!
If you’re a data service provider with hundreds or even thousands of customers, getting hacked is only a matter of when – and when will it happen again.
Targeted attacks look for the weakest link in terms of security. When the weakest link is the data service provider and not the customer, the attackers might get greedy and not settle for just one target. A quote from MongoHQ :
“Currently, it appears that the unauthorized user was scanning for social media authentication information for spamming purposes, and probing for financial information in customer database”
Here are some of the issues that made the MongoHQ hack possible:
- A support application was accessible through the web and not behind a VPN
- Customer data was visible to users of this support application (what if the compromise was of an employee?)
- Two factor authentication was not implemented
- There was no User Rights Management.
Securing data requires, well, some data security
Even Though many factors were responsible for this breach (such as “Excessive and Unused Privileges”, “Privilege Abuse” and “Unmanaged Sensitive Data”), MongoHQ breach root cause is an example of one of Top Ten Database Threats:
“Internal security controls are not keeping pace with data growth and many organizations are ill-equipped to deal with a security breach. Often this is due to the lack of expertise required to implement security controls, policies, and training.”
This means that organizations should rely on the security expertise of 3rd party businesses instead of inventing the wheel or simply closing their eyes. Data security is a business of its own; Data service providers shouldn’t be surprised when breaches occur to non-secured data, and their security learning curve – and their customers (the ones that are left) – can be quite long and painful.
Since the breach, MongoHQ took very significant security measures, but mainly they utilized third-party validation of their security.
With Big Data comes big responsibility
Limited security expertise and education is not only the service provider’s problem, it is also a real concern for its consumers. Were MongoHQ customers aware that their sensitive data was visible to the MongoHQ support application? Do you know who can access your data? How is it stored? Can it be copied?
These are all questions that are all too often forgotten, especially for young startup companies eager to build applications and avoid dealing with security and management costs.
Customers need to know what their service providers are doing to protect their data. This has recently become a new mandate with the rise of PCI DSS 3.0, where service providers are now accountable for protecting the data of their customers. Data center security needs to be out in the open, especially “up in the cloud”.
While making your data somebody else’s problem is a nice fantasy, you are still accountable when it’s stolen or corrupted. You can’t guarantee your data availability when using a data service provider, but you can at least improve its integrity and confidentiality.
Joel Gascoigne from Buffer also realized this when he wrote on Hacker News:
“I want to be clear that this is still our fault. If access tokens were encrypted (which they are now) then this would have been avoided”.
You as a customer would be smart to take responsibly of your own data. Recognize where your sensitive data is and prepare for the inevitable day when it is compromised. Additionally, we as customers need to hold our service providers accountable for security instead of just “taking their word.”
Authors: Barry Shteiman, Michael Cherny and Sagie Dulce from Imperva.