Do your MongoDB admins know what they are doing?
Note: This was originally posted to LinkedIn, but I have moved it over here to go along with the update I posted about the explosion of malicious ransom demands.
MongoDB by default does not have very good security configured out of the box. Unfortunately, the technology is new enough and different enough that people tend to do a poor job of securing their data. After a brief discussion with another security professional this last week, I started digging into MongoDB servers around the United States. What I found was disturbing.
I found more than 14,000 MongoDB servers from more than 600 companies that are open and unsecured. Some of the databases include personal photos from cell phones, call recordings, call logs, billing information, credit card information, and more. PII (Personally Identifiable Information) and PBI (Private Business Information) is out there and available to the world with no authentication in front of it.
If your company owns a MongoDB server, please take the time to review the configuration with your Information Security department and make proper decisions on what information should be secured and protected. NoSQL is just like any other database technology; all data should be protected with authentication and authorization.
Why do metrics and other “junk data” need to be secured?
Many of you will say things like “The only data we have on there is some basic metrics.” That should be protected too. Even though it could only be basic metrics/analytics on users, that information can still be used by rivals or scammers to get a better understanding of your business, your customers, and/or your business processes. Usage modeling is actually a very valuable tool for penetration.
Keep in mind that MongoDB is being used for more than ever before. It is relatively new compared to some of the other technologies out there, but it is growing at an amazing rate. It is being used for everything from document handling, to session management in SiteCore. The last thing you need is to give malicious actors the ability to see session data. From there it is a very short jump to hijacking sessions.
Remember that all data is valuable to someone that is less than ethical. It can all be used in a way that hurts the business or hurts the customers. You also need to remember that server usage changes. When you setup a new server, it may only be used for basic analytics collection. Ten months later, you may be hosting a lot more on that MongoDB instance than you had originally planned.
Large applications are implemented in phases. You need to account for the full lifecycle of that application when you setup your resources. In phase one, you may only keep basic analytics on your MongoDB server, but during phase two or phase three, you may end up storing session data, billing data, or more.
The importance in understanding where your applications are going and planning ahead is more important than making sure the implementation is fast. It may take you more time to implement an application with the added security and segregation of concerns, but in the long run, it protects your customers and it protects your business to do it right and not just fast.