How do we instruct our employees to protect themselves from Heartbleed? [duplicate]

Solution 1:

Essentially, no, there is no one way to tell the good scenarios from the bad, because your users don't have full visibility of the systems they're using.

The extent of the damage caused by the bug is still largely unknown, most of the damage was potentially done in the past and will continue to impact the internet for a long time. We just don't know what secrets were stolen, when, or by whom.

For example: Google's OpenSSL heart bleeds for about a year. Unknown adversaries harvest the servers and look for interesting secrets - again, there is no way for us to know whether they did this or not - until they find an account belonging to someone with authorized access to another system, say Twitter.com or AnyBank.co.uk or dev.redhat.com. With access to such accounts, they could potentially keep digging, gaining access to other systems, doing other damage (visible or not), further compromising other accounts - without anyone suspecting the origin of the breach. At this stage you're already far away from the bleeding OpenSSL servers, and this is one of the nastier consequences of Heartbleed. Added to that is the risk of servers' private keys being compromised.

Trust takes a long time to build up, and can quickly be lost. I'm not saying that we didn't have trust issues on the internet before, but Heartbleed definitely didn't help. Repairing the damage will take a long time, and understanding this is part of understanding how you can protect yourself and your employees/clients/bosses etc - and how you cannot. There are some things you can control, to limit your exposure to the vulnerability, and there are things you cannot control - but they will still affect you. For example, you cannot control how everyone else decides to respond to this vulnerability - the NSA reportedly discovered the bug but kept quiet. That was pretty bad for the rest of us, but we had no way of protecting us against it.

As an internet user you can and should:

• Understand just how bad the bug is
• NOT reply to/follow links in e-mails telling you to reset your password - instead go to the website of the company/organization directly and actively reset your password. Times like these scammers like to go phishing
• Check your Android phone for Heartbleed. There's an app from Lookout Mobile Security that checks your version of OpenSSL.

• Check websites you visit for Heartbleed (incomplete checklist):

  1. Is the server using OpenSSL?

     • No: You're not directly impacted (by this bug). Keep using the site, but change your password in case another server directly or indirectly affected by the bug had access to your password. This assumes, of course, that all such servers on that network have been patched, issued new certs... etc.
     • Yes: Go to 2.

  2. Is the server on a Heartbleed-free version of OpenSSL? Make sure that your check-for-heartbleed-tool actually checks for the vulnerability and not the HTTP header or some other "indicator".

     • No: Don't submit any secrets to the site, but if possible submit a note to the webmaster.
     • Yes: Go to 3.

  3. Did any previous version of OpenSSL have Heartbleed?

     • No: Some admins didn't upgrade to the latest OpenSSL version, because it hadn't been field tested long enough. Their servers were never vulnerable to this bug, but for reasons presented above, you may still be better off changing your password.
     • Yes: The server was vulnerable, and it is possible that any in-memory data was compromised between the time of upgrade to the vulnerable version and the time of disclosure (up to two, or even three years).

Here we come back to trust: When you lose someone's trust, that's a bad thing. Especially if that someone is your user/customer/boss. To regain their trust, you have to start building again, and open up for a dialog.

Here's what a web admin can publish to get that started:

• Previous OpenSSL version(s) (vulnerable/not vulnerable)
• Current version and when it was updated

And if the previous version of OpenSSL was vulnerable:

• When the current SSL certificate was generated
• Detailed description of how the old certificate has been revoked
• Assurance that a new secret was used for the new certificate
• Suggestions for users based on the above information

If you're a user, you have every right to ask for this kind of information, and you should, for the sake of all users of the service. This would increase the visibility for the security community, and make it easier for users to minimize their exposure to compromised servers.