Are Service Providers Prepared for Cybersecurity Risks Post-Heartbleed?

Many organizations responded to the Heartbleed Bug by conducting the appropriate risk assessments and vulnerability scanning to determine whether they were running vulnerable versions of Linux containing the affected OpenSSL versions (1.0.1 through 1.0.1f). If the vulnerability was found, they quickly moved to close it, but many organizations determined that the servers or systems they were running weren’t at risk.

The simple fact is that for hundreds of thousands of sites that ran the vulnerable OpenSSL code – which was in distribution for a year – we will probably never know whether the vulnerability was exploited, or exactly what data may have been compromised as a result of Heartbleed’s memory scraping.

Regardless of whether an organization ran servers with the Heartbleed vulnerability, it doesn’t mean that they weren’t affected or open to other cybersecurity risks. Companies interact with other company websites. Banks, financial services providers, even social networking sites where the company maintains or manages interactions may have been affected by Heartbleed. The passwords used to access these sites may have been compromised, as well as the encryption keys used to make interactions with them secure. To ensure that all the potential risks of information stored on these service providers’ sites are assessed and dealt with, take the following plan and modify as needed:

1. Identify the sites with which you interact. These would certainly include banks and other financial institutions, various software-as-a-service providers and social networking sites as a starting point. Try to make your list as comprehensive as possible.
2. For each entry on the list, find out if the partner/service provider had the Heartbleed vulnerability. Some websites (like Mashable) have compiled lists of sites and their vulnerability status. For some, you may have to contact the site operator directly.
3. For vulnerable sites, you should change your company’s passwords, but only after the vulnerability has been remediated by the site. Changing a password on a vulnerable site before they fix the Heartbleed problem can lead to the new password becoming compromised. Even in cases where multi-factor authentication is used, changing your password is a good idea.
4. If you did have passwords on vulnerable sites and use those same passwords on other sites – including those which never had the Heartbleed bug – you should change them. Bad guys know that passwords are often used across sites, so they must be considered to be potentially compromised.
5. Make sure your entire staff knows that if they have any sites they use for business, they need to notify you so that you can check on their vulnerability status and determine whether and when to change the passwords.

Even if a server was never vulnerable to Heartbleed, organizations may well be affected by it and affected seriously. Use this plan as an outline for making sure that responsible steps are being taken to protect companies from avoidable problems related to this programming bug.