Share This Article
Incidents like the MongoHQ event in October make us move from shock (what happened?), to inquiry (how did this happen?), and then to one of two courses of action. The course of action that makes some people feel good – but doesn’t result in progress – is to start assigning blame. The other course of action – the one that leads to improvement and prevention of the problem – is to ask: what could have been done differently and/or what can we do right now to avoid such a situation in the future.
MongoHQ did a stellar job of identifying the issues, documenting them for their customers and public at large, and also at responding to them quickly and decisively. A textbook example of a solid response to a security incident. Kudos to MongoHQ for the way they handled the situation.
From the public reports, it appears that a key individual’s credentials were compromised. These credentials were shared with with a critical internal support application. Additionally, this internal support application was available via the public Internet. As a result, the attacker was able to gain access to the internal application which consequently enabled access to customer data and applications. While the full impact of the breach is not yet known, it is clear that it touched their customer data and it allowed for their customers to be compromised as well.
In addition to their public response, MongoHQ quickly adjusted their technical approach to make it dramatically more difficult to compromise them. Organizations can learn from this response and we detail below actions that every company can take to avoid a similar type of breach.
MongoHQ took three major actions:
- Ensured proper access to the support application (through multi-factor authentication)
- Disabled public Internet access to the application
- Hired a third party to perform incident response and security testing
It should be noted that the attack on MongoHQ is not unique and it is most definitely not rare. In fact, the techniques utilized were standard operating procedure for hackers and easy for them to execute. The good news is that this common attack vector can be addressed reasonably easily and quickly.
1. Enabling multi-factor authentication (MFA)
When people talk about MFA, they are generally talking about something you know (a password, for example) and something you have (such as a security token like Google® Authenticator). That ensures that if someone is able to get hold of your password, they hopefully don’t also have your security token as well. That means that the password is essentially useless by itself (and the token as well).
MFA is very powerful concept: it means that compromising your laptop doesn’t have to result in compromising everything you also login to via your web browser. It prevents brute force attacks because there’s no point in trying a bunch of passwords against an account if you don’t also have the rolling authentication key that comes from a security token. In short, it makes passwords strong enough to rely on for daily use, and lets you feel comfortable that if a password is lost, you won’t suffer any harm as a result.
The downside of MFA is the same as any security technology; you’re trading convenience and ease-of-use for security. MFA means that every time a system asks you for a password, you have to pull out your phone, or a token from your pocket, and type in whatever number it shows you. That means that you need to consider whether you want to add that bit of inconvenience to your customers in return for the added protection provided by MFA. That’s a question only you can answer, but if you want to prevent another MongoHQ-type incident, MFA is critical.
Our suggestion, if you go down this path, is to implement MFA for key individuals in your organization. These are people that have access to a number of internal systems and/or data. For example, your system administrators or DevOps personnel should have MFA enabled on their Google Apps email.
All critical servers can have multi-factor authentication turned on. If it is reasonable for you to enable it for your critical applications, you should do that as well. You can use technology such as JumpCloud™ along with Google Authenticator to implement this MFA approach.
2. Place Critical Applications Behind a Virtual Private Network: Strong Privacy and Authentication for a Variety of Servers
A VPN is basically the creation of an isolated network through the use of software. A client machine connects to a server machine, and they both agree to do two things:
- Authenticate each other: make sure that they are who they say they are
- Encrypt all communications between them
Putting these two concepts together is very powerful – it gives you the ability to isolate servers from the rest of the Internet, while gaining all the access you need. It also makes sure that not just anyone can get into your network – especially if you use certificates for authentication, rather than just username and password. It also makes sure that any communication between you and the remote host is hidden from others. A VPN also provides you with extremely fine-grained control over what you expose to the public, and what you keep hidden.
The downside of using a VPN comes in its setup and maintenance, which can take more effort than some are willing to invest. The actual use of a VPN for end users is generally only a minor inconvenience, especially when compared to the protection it provides.
If you have Linux servers, you can download OpenVPN and create tunnels between your servers. Place a firewall at the “head end” of the group of servers so that there is only one point of ingress / egress. Tighten down the access so that only key ports are available. After that, build out your VPN architecture.
3. MFA + VPN: A Match Made In Security Heaven
As with most security technologies, you get more bang for the buck if you layer multiple technologies together: putting MFA and VPN together, so that not only do you use an SSL certificate for authentication and encryption, but you also have to supply an authenticator from a security token. This provides a barrier that will thwart all but the most determined attackers. It means that even if your certificates or your token are lost, you’ve still got positive control over your environment.
No security is perfect, and as we often say, “You will get hacked, it’s just a matter of when, and how you respond.” MongoHQ got hacked, and even with the above controls, they’re not going to be impervious to future attacks. However, they responded as professionally as any organization could.
For your organization, execute on those two key things and you will dramatically decrease the level of risk. Add MFA to your critical users, servers, and applications. Focus on what matters so that you can do it quickly with the least amount of inconvenience. Then, put all of your critical apps – to the extent possible – behind your firewall and limit access through a VPN. These two things should not take an extensive amount of time, but should result in leveling up your security.
For those of you worried about a MongoHQ like breach, you can leverage JumpCloud along with your VPN solution (e.g. OpenVPN) to lock down access. Further, with JumpCloud’s multi-factor authentication capabilities, you can take it one step further and potentially avoid a situation like the one just presented.
