January 25, 2017 By Kathryn Zeidenstein 4 min read

The inevitable happened — attackers stole data from thousands upon thousands of misconfigured MongoDB databases and are now demanding ransom money to get it back. These cybercriminals are going after even more misconfigured systems on the internet.

Don’t say we didn’t warn you. The IT community has known for some time that default settings can leave databases open for attack. MongoDB has made no attempt to hide these issues. In fact, the company encouraged users to read its security manual and directly addressed the latest round ransomware attacks on its blog. A technical rep from MongoDB has even posted on Security Intelligence about the importance of hardening the MongoDB server and following security best practices.

Unfortunately, these education efforts won’t sink in with everyone. In this case, it failed to resonate with a lot of people. I do not know the nature of the organizations being attacked, but I think we can safely assume that in many cases the MongoDB instances are owned by application teams that are not tied into the security community as closely as some of us are. Or maybe people just plain didn’t know one way or another whether they were at risk.

Data security software was invented to fill in those gaps. You can read all the manuals and warnings in the world, but let’s face it — people forget things, fail to follow process or simply lack the time and awareness to adhere to security best practices. IBM enhanced its Guardium Data Protection Platform to support MongoDB and developed the software with input from the MongoDB security team.

Read the white paper: Finding the path to security in the big data landscape

The MongoDB Security Checklist

Let’s look at the MongoDB Security Checklist and discuss how a data protection solution can automate the work of monitoring, encrypting and hardening your databases.

Enable Access Control and Specify the Authentication Mechanism

While someone has to set this up, you can schedule automated, regular checks to verify that the system is been enabled. Make sure to enable this checking on new MongoDB servers. This is not a one-and-done process: A Guardium Vulnerability Assessment can regularly check that the authentication system is configured and that you’ve disabled the localhost authentication bypass.

Configure Role-Based Access Control and Follow the Principle of Least Privilege

Later releases of MongoDB include role-based access controls that enable administrators to assign specific users to roles that do not allow access beyond what is necessary. Guardium Vulnerability Assessment includes tests to check regularly for users that have highly privileged roles, such as dbAdmin and userAdminAnyDatabase. Guardium Data Activity Monitoring also enables you to see when roles are created and populated.

Encrypt Communication

A basic best practice is to encrypt communications to the database server and even between nodes. If you’re not sure if your team has done this, a security tool can check to see whether secure sockets layer (SSL) is configured. Activity monitoring can also work with encrypted traffic.

Encrypt and Protect Data and Configurations at Rest

MongoDB has an option to encrypt data in the storage layer using the WiredTiger storage engine. If you aren’t using that storage engine or would rather use a system that integrates with the rest of your environment, consider using Guardium Data Encryption. You can use this to encrypt data, backups, log files and configuration files with an easy-to-use, policy-based interface.

Guardium Vulnerability Assessment can also run tests to check the file ownership and permissions on critical configurations and other objects to help protect the confidentiality, integrity and availability of the MongoDB databases.

Limit Network Exposure

Limiting network exposure was once the source of many headaches. In earlier releases, the MongoDB default configuration enabled listening on all interfaces. Although MongoDB corrected this in the latest releases, it’s important to ensure that you use the bind_ip configuration appropriately. You should also ensure that only trusted connections get through. Guardium Activity Monitoring enables you to monitor and profile connections to the database, monitor their activities and even block connections that are not vetted.

Audit System Activity

Why wait for a ransom note to find out your database is under attack? Monitoring access to data and configurations is critical for both real-time and forensic analysis. MongoDB Enterprise includes native auditing capabilities. To really take advantage of real-time alerting and blocking, outlier detection and out-of-the-box integrations with security intelligence systems, consider a solution that is tailor-made for data security and does not impact performance as native auditing sometimes does.

For example, you can set up real-time alerts when data is being read at an excessive rate, which is an indication of a potential attack. You can also receive alerts when someone is attempting to guess passwords. In the following screenshot, you can see that Guardium produces a notification when a user reaches the failed login threshold.

Run MongoDB With Secure Configuration Options

This section of the checklist includes some miscellaneous but extremely important items. For example, you should use only the MongoDB wire protocol on production deployments. Mongo recommended disabling the REST, JSON and HTTP interfaces.

MongoDB supports execution of serverside JavaScript for some operations such as mapReduce, group and $where. This can potentially be a launchpoint for an injection attack. If you can avoid these operators, you can disable serverside scripting. Additionally, Guardium Activity Monitoring can monitor database traffic and flag the use of these operators, as shown here.

Keep Current on Maintenance

Although not specifically listed in the MongoDB checklist, it is critical to keep your systems up to date. Whenever an exposure is discovered, the database vendor must address the vulnerability. The response speed depends on the severity of the problem. Guardium updates its test database quarterly, so if MongoDB ships a patch required for security, Guardium can test to make sure that patch is applied.

Certified Data Protection

To see Guardium Vulnerability Assessment in action with MongoDB, check out this video demonstration. For technical details on implementing a database activity monitoring solution for MongoDB using Guardium, see our IBM developerWorks article series.

Guardium is certified with MongoDB and other vendors such as Cloudera, Hortonworks and Teradata to help you provide data protection capabilities across your operational databases, as well as big data and NoSQL systems.

Read the white paper: Finding the path to security in the big data landscape

More from Data Protection

3 Strategies to overcome data security challenges in 2024

3 min read - There are over 17 billion internet-connected devices in the world — and experts expect that number will surge to almost 30 billion by 2030.This rapidly growing digital ecosystem makes it increasingly challenging to protect people’s privacy. Attackers only need to be right once to seize databases of personally identifiable information (PII), including payment card information, addresses, phone numbers and Social Security numbers.In addition to the ever-present cybersecurity threats, data security teams must consider the growing list of data compliance laws…

How data residency impacts security and compliance

3 min read - Every piece of your organization’s data is stored in a physical location. Even data stored in a cloud environment lives in a physical location on the virtual server. However, the data may not be in the location you expect, especially if your company uses multiple cloud providers. The data you are trying to protect may be stored literally across the world from where you sit right now or even in multiple locations at the same time. And if you don’t…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today