MongoDB security head addresses database exposures

MongoDB security settings have received significant upgrades recently, yet some users are still accidentally exposing their databases to the public internet.

Starting in 2017, MongoDB added several security features for its database products that are enabled by default. But that hasn't stopped some organizations from running older or free versions of the software that are misconfigured and left vulnerable.

For example, earlier this month, security researcher Victor Gevers discovered more than 2,000 exposed MongoDB databases belonging to foreign and local businesses operating in Russia. Those databases contained credentials that gave the Russian government full access to the data.

We spoke with Davi Ottenheimer, head of product security for MongoDB, about such exposures and what the company has been doing to stop them. MongoDB security enhancements include moving from SHA-1 to SHA-256 for the company's default authentication mechanism -- dubbed SCRAM, or Salted Challenge Response Authentication Mechanism -- as well as TLS improvements. 

"Part of our mantra is to make security easy for people. Otherwise, it doesn't get adopted," he said.

Ottenheimer discussed MongoDB's security settings, how the company has approached misconfigurations and the challenges of having an open source product.

Editor's note: This interview has been edited for clarity.

In trying to make MongoDB security easy, were you worried about making authentication too hard to the point where people were locking themselves out of their databases? Did that ever happen?

Davi Ottenheimer: Not that I'm aware of. It's more that people either don't use [authentication], or they use it incorrectly. We've seen people use it incorrectly for sure. And, in a lot of cases, they didn't turn on authentication, and that was what we kept telling them to do -- or use something else that protected them.

Davi Ottenheimer

We've always had the approach that we want to make it not only easy, but make it something that people will do. We measure our success on whether they are doing it, and so we've taken steps and continuously evaluated whether we're successful in getting people to do it.

For example, we moved to TLS 1.1 and above. And we could have gone straight to 1.2, but we wanted to make sure that it was available first. Then, we measure to see if anyone's using it. And if we find no one's using the 1.1, we may turn it off proactively and just go [to] 1.2 and above.

There literally are academics debating which ones should be used. But, in the real world, we, of course, have people who have very old devices who need insecure versions and want to have, for whatever the use case is, things done in a way that others would consider the wrong way.

We can't always judge for one group of people the way everyone should behave. So, we try to be sensitive to the widest possible use case and make people as secure as they need and give people who don't want any security the option to turn it off so they can get done what they need to get done. It can be literally less secure to have a denial-of-service situation. So, for some people, they have to have a connection, even if it's a weaker connection. And that's another tenet of security: The availability matters.

What kind of feedback did you get from customers? Were there some who saw authentication requirements as roadblocks? Or, were there other customers who weren't aware they should be protecting their databases?

Ottenheimer: We never found that anyone who came and asked us for [security] advice had been compromised, to my knowledge. The only compromises I'm aware of are people who never followed the most basic directions, or never followed the basic templates.

There was an expectation that they would take the trouble to go through the process and, for example, have a firewall. But some people never will put a firewall in, because they just don't follow that basic step. What we've done is made it easier and easier for people when they initiate the product to be in a position where they're asked and prompted [for security settings].

For example, [MongoDB] version 3.6 and later is a local host. You need to turn on the network connection and assign IPs. And then, that forces you in the decision tree of, 'Who do I want to connect to me?'

With Atlas, we do the same. You have to enable a network connection, and we have an IP whitelist there. We're saying very specifically, 'You need to assign a very particular IP to connect to you to do work now.' It's not open to everyone.

Now, if they want to go and open it to everyone, that's now a decision tree that they have to go through. People want default security in a way that allows them to get their apps written on a database that's running as quickly as possible. And in a safe manner, they're able to produce whatever their application's doing and deliver it to customers. Atlas tends to be the best option for people today.

So, we didn't have customers coming in and saying what's wrong; we actually had the opposite. We had people not coming to us. For all we know, it was students running a lab, putting some public data in and then just leaving it open because they were just playing with the product. The familiarity of the product to people, I think, is a good sign. And that's why there's so many of them out there.

But that also creates the attention. And people are asking us, 'Why are these configured in a certain way?' And we don't always know, because they didn't come to us, even though we did put the information out to do it the right way.

There's been a lot of debate about what vendors and cloud service providers should do to prevent accidental exposures. Some have argued that default settings for security should be set high in order to protect customers from their own errors, but it sounds like you don't think that's necessarily the best approach.  

Ottenheimer: It's a balance question. I think we've been very proactive, at least since I've been here [in May 2017], in getting the message to people about how the defaults have been set for them to be secure. But that shouldn't prevent them from doing everything they need to do.

For example, local hosting is on by default. There's no internet connection compromise when local host is the only connection. We consciously made that change all the way back in version 2.6. But we were trying to do it in a way where we thought it would have the most impact, and then we realized we needed to do it everywhere.

MongoDB 3.6, released in [November] 2017, very specifically enabled default security across all the builds, and it's going to be that way going forward. And we're encouraging people to upgrade. We're encouraging people to take these new defaults that are more secure. But, in terms of balance, we also do not want to, as you said before, lock people out of their own account. We don't want availability issues where they can't use their product.

We have online training, and we have an extensive university, with a million people trained so far. We're also writing security manuals, we're doing security best-practice checklists, we have TSEs [technical service engineers], and we have teams dedicated to helping people with any questions they raise about security.

I think we're very proactively moving on the secure-by-default position, and Atlas is a perfect example of that. Encryption is enabled by default, and it can't be turned off. But we're also still trying to make sure that we're enabling the speed of development that's required for a lot of the AI, ML [machine learning], and IoT workloads and the very diverse customers and very different industries that we have to address.

Do you feel like the messaging that you're putting out there to customers running older versions about taking advantage of the MongoDB security settings and upgrading to a more secure version has been successful? Are people mostly heeding the advice, or are they ignoring it?

Ottenheimer: We're in an interesting situation being an open source company and having a free version of the product available. People are welcome to have no relationship with us whatsoever -- which, in a sense, is good privacy.

By enabling people to have little to no knowledge of us and us to have no knowledge of them, we have a much more interesting situation than if we have a tight, commercial, managed service relationship where we see everything they do and own everything they do. We give people the kind of freedom and privacy they want, and that also opens us up to having no way of communicating with them about what they should be doing.

That's another balance that we're in. We've never had a customer, to my knowledge, that has had a relationship with us that has had this issue, so we're talking about people that have taken a free version of the product.

Now, that raises another interesting question: If they're providing a service to someone else -- for example, if they moth ball a 2.6 release, and we're on 4.0 -- can we find out that they're giving it out to someone else and get them to raise the version? I think that's where we're going next. We're trying to make sure that, even if they don't want to have a relationship with us, if we find out that it is insecure, we will proactively communicate with them.

We have been doing that for a while. If we find out [a database is misconfigured and exposed], we try to communicate with people about what we think would be best. But there's an authorization component there. Have they authorized us to go in and tell them what to do with the product that we essentially gave them for free? If you respect people's privacy, you can't always go in and tell them exactly what to do.

At the same time, when you see headlines about 'MongoDB databases left wide open,' even if it's for free versions that you never touched, do you feel like those examples reflect negatively on your company?

Ottenheimer: We obviously take it very seriously. We investigate every one of them, and we look at how we can do a better job. And that's where you saw the transition, as I described. We had some changes all the way back in 2.6, and then we made more changes. By the time we got to the 2017 release of 3.6, across the board, we were proactively offering a secure-by-default posture.

We're always looking at how we can get in front of that kind of problem. Even if we can't go and tell people what to do, we give them the best tools possible without preventing them from getting their job done. We want them to have tools that work that are safe.