The MongoDB hack and the importance of secure defaults

I wouldn't blame MongoDB.

Any machine connected to the Internet should start with a configuration equivalent to:

    ufw default deny incoming
    ufw allow ssh
    ufw enable

And then start punching very specific holes as needed.

Well, you have a sysadmin, that's the point. Developers aren't sysadmin. Should they have a deep knowledge of network security? you bet they should.

Now I'm sorry, but MongoDB inc IS at fault as well, for not forcing developers to create credentials upon installation from the beginning. Any vendor that doesn't do that with its product isn't serious about security. Let's take Wordpress, imagine it didn't force its users to create an admin account upon deployment, everybody would be mad about it. But somehow MongoDB got a pass all this years? bullshit.

I hope this hack will permanently damage MongoDB brand.

Thoughts like this are, and will forever be, the one dividing thing between a more ops-y person versus a more dev-y person.

But that's fine. At our place, our mysql cookbook is maturing. This mysql cookbook makes it really easy to say "hey, we need a mysql master with these 2 databases". The only security overhead consist of generating 4 passwords in that case (and we're planning to automate that).

Once you've done that, you get a mysql master with passwords, restricted root access, a local firewall, backups and all kinds of good practices. It's secure because our cookbooks are good, and people use our cookbooks because they are easier than handling mysql directly.

And that's a kind of cooperation I'm really happy about. Devs want services, and we provide easy ways to setup services in decently secure ways.

A bit off-topic but related: how secure are the defaults of an AWS RDS MySQL (created by a BeanStalk environment, if it matters)?

It's really, really easy to pass things off for later and then lose track of them. What's worse is that, once some task is "lost," it's even easier to assume that it's already been completed. And when that happens, we can completely block it off from thought as we concentrate on other tasks unless some external stimulus causes us to think about it again.

It's not a perfect comparison, but there are some similarities to the tragic cases of children being left in hot cars in the summer. Dozens each year, largely by parents who aren't abusive, neglectful, or what most would consider to be "bad parents."[0] Instead, it's what's called a prospective memory failure: habitual memory processes override prospective memory, which by its very nature involves additional cognitive mechanisms. There are a couple of PM theories, but the multi-process model suggests that PM cues can trigger a prospective intention even without an active monitoring process. Miss or interrupt the cue, and the intention isn't retrieved and followed through on. Failures such as airplane crashes when pre-flight tasks are interrupted and tasks are missed,[2] fatal anesthesia incidents,[3], fires because gas appliances were left on, etc. A number of industries have been putting more effort into hedging against PM failures over the past few years through better checklists and other aids and precautions precisely because the consequences can be so tragic.

Getting back to the topic at hand, the issue with dumb shortcuts like insecure defaults isn't that they're bad on their own but that the way our brains work makes it less likely that we'll go back and fix all aspects of those shortcuts later before a problem arises. Documenting your shortcuts, setting reminders, and other actions can help minimize that likelihood, but how likely is it that you'll do so when you're in the middle of taking an ill-advised shortcut in the first place? At that point, you might as well spend the time to do it right.

It's the same danger that comes with hotfixes. Even when you have no other choice, you've put yourself in a position that could have unseen danger later on. Having a policy in place (checklists?) for dealing with something like that can help you avoid PM failures by forcing you to go back and retroactively apply your normal procedures to the patch in question. Style guides and other guidelines help as well in everyday circumstances, even though they can be a bit annoying at times. Because no matter how you look at it, mistakes will be made.

Insecure defaults and stupid shortcuts make it more likely by stacking the deck against the people working on a project.

0. http://www.cnn.com/2016/07/25/health/hot-car-deaths-explaine...

1. http://www.psych.wustl.edu/learning/McDaniel_Lab/Prospective...

2. http://www.psychologicalscience.org/news/releases/when-we-fo...

3. http://anesthesiology.duke.edu/?page_id=826043