Heartbleed broke internet a bit, here is what you can do.

We can’t even describe how scary the Heartbleed attack is and will be for quite some time. It all started rather small but it has grown to one of the worst setbacks for security on internet for quite some time. OpenSSL 1.0.1 had a small bug, but the thing is that OpenSSL is used in about 60% of all servers on internet to encrypt the traffic that flows through it. Not all of them uses the exact vulnerable version but a lot of them do. The vulnerable bug have been deployed in servers for almost 2 years now, and usage of vulnerable version have increased a lot since then. New goodies like TLS 1.1, TLS 1.2 and elliptic curve cryptography have been driving the adoption. All and all, the vulnerability have been deployed for a long time, and it’s only now that the bug was found, patched, communicated and named Heartbleed.

With the help of Heartbleed an attacker can read information from a servers memory. A servers memory can hold all kinds of secret stuff. It could include passwords, encryption keys, secret documents, personal identifiable information and money transactions. On top of it all can a server be attacked without any traces of it being so. 

This means that if your system is vulnerable you can’t figure out if you where attacked, what information was retrieved by the attacker and how badly you where hit. Or have been hit for 2 years. It does not really stop there either. Users tend to re-use there favourite passwords all over internet. That means that a lost password on a vulnerable server can open up security holes in other systems and servers. It spreads like wildfire. What you should do is to consider most of your information compromised, even information and passwords sent years ago. If your system don’t use the most modern encryption standards it’s even possible to figure out information sent before the vulnerability occured. It’s like a perfect storm.

It’s definitely time to have the biggest password change day the world have seen so far. In all servers where you have accounts. But make sure to wait until the servers you update your passwords at are updated and patched. Otherwise you have to do it again. 

If you have been running OpenSSL 1.0.1 you should make sure to revoke your existing certificates and keys and order new once. Update your servers to use OpenSSL 1.0.1g and then add the new keys. Then start the major cleanup work within your organisation. What that consists of varies according to what organisation you have, but changing passwords and keys is one of them, information is another, crying could also be a key part of it.

It’s always hard to protect your self for things like this. What you can to is to minimise the risk and make sure that when it happens it should be controlled and retained as much as possible. 

The key things you should do is to expose as little of your IT-infrastructure as possible to the big bad internet. A common way to expose servers is to open up a firewall and hope that the server is kept updated, have good authentication and authorization built in to it and that it does not use OpenSSL1.0.1(not g that includes the fix). It works when you have a very small amount of servers, but as soon as you have 5 or more servers it becomes a tough job to maintain them all. Where are your users created? Are they all updated? Do all of them have different passwords? We recommend that you put a centralised protection of all those resources. A reverse proxy like neXus Hybrid Access Gateway can protect all of your internal and cloud systems and keep a unified and updated front against internet. It have built in authentication and authorization so that the correct persons have access to the correct systems. 

Another thing you should do is to put all your smart policy decisions and connections to your user storages, like Active Directory and other identity stores, as protected in the network as possible. It’s important to split an access solution so that only the minimum amount of services are facing internet, and others are protected way inside of your protected network.

Secure two factor authentication methods like neXus Invisible Token, TruID, one time passwords or PKI certificates also minimises the risk. That means that you do not only rely on a username and a password, a user must also prove it’s identity with something else (the second factor). That seconds factor is not calculated and generated on the an attacked server, that means that the attacker can’t logon even though a password was stolen.

Everybody hates passwords, especially changing them. And even more especially when it needs to be done on a bunch of servers. Heartbleed will require a huge password change process on internet. The solution and the security industries main weapon against having your password scattered all over the internet is called identity federation. That means that you only logon once (preferably using a two factor authentication) and you can re-use that authentication all over the internet. If an attacker would be able to read an listen in on a logon to a system using a federated identity it’s not as bad as loosing a password. A federated identity can never be re-use to logon to a system. That’s hugely limits the attack surface of an attack like Heartbleed.

It’s also important to have systems that’s quick and easy to upgrade and to patch. When scary stuff like Heartbleed happens, you have to be quick to upgrade the systems. You must have ways to push new versions into your production without downtime and you also need to handle things like key rotations gracefully. It’s an art and requires it’s implementations.

Finally, detailed and centralised access logs and reports is crucial. If you have a possibility to figure out who logged in (within the last 2 years, or more), what resources they have been accessing then you at least can know what information may potentially be compromised.

This have happened before, and it will happen again. The important thing is to make it really rare and to limit the impact of it. More hands on deck when it comes to supporting, with hard cash or with time, organisations like OpenSSL and other security based projects and security standards will make it less likely that this happens often. The second thing that needs to be done is to design your IT infrastructure in an as secure way as possible.

Now go change your passwords, but make sure that the site you change your password at isn't vunerable  :)

/ Erik Wahlström