It would be difficult to find someone involved in the security industry today who has not heard about the Heartbleed vulnerability, first disclosed earlier this week. This flaw in OpenSSL, which affects most of the Internet, is one of the most serious publicly disclosed vulnerabilities in recent times, not only because of how common OpenSSL usage is, but also because of the scope of the vulnerability itself. Servers vulnerable to the Heartbleed buffer overflow expose their own raw memory contents to attackers, allowing someone to snoop in on all kinds of data, including user names, emails, passwords, addresses, Social Security numbers, companies’ confidential data — the sky’s the limit. Essentially, if it is data that has recently passed through OpenSSL memory buffers on the server, it is vulnerable to attackers.

SEE ALSO: What to Do to Protect against Heartbleed OpenSSL Vulnerability

Furthermore, properly fixing the vulnerability is not even as simple as patching OpenSSL itself because if the host has been exposed to attackers, one must also regenerate their security certificate, which may be compromised and can no longer be trusted. Generating and replacing certificates for all servers can be an extremely expensive and time-consuming procedure for companies that have many SSL end points. Likewise, these previously used (and assumed compromised) certificates also have to be revoked.

How does one decide which servers to patch and certificates to remediate first?

There has been commentary that this vulnerability exposes a “need for a new approach to security,” one where proper monitoring, intelligence and incident response are just as important as strong firewall rules, which raises an important point: When responding to an incident like Heartbleed, the solution is not usually as simple as pressing a button and having all machines in the enterprise patched and all new certificates generated and deployed. For most organizations, it will require lots of planning and effort. So the question arises: How does one decide which servers to patch and certificates to remediate first? Thankfully, IBM Security has you covered. Using the IBM Security QRadar suite of products, it is relatively straightforward to not only detect servers that are likely vulnerable to Heartbleed, but also to prioritize your remediation work flow, allowing you to target your most vulnerable and/or valuable assets first.

2014 Gartner Magic Quadrant for SIEM

The first step is identifying the machines and services that are vulnerable to Heartbleed. IBM Security QRadar Vulnerability Manager’s scanner module, which processes nightly signature updates, will have the ability to detect hosts vulnerable to Heartbleed, also known as vulnerability CVE-2014-0160. It is important to note that you don’t have to rescan your assets to know if they are vulnerable; they just have to have been scanned in the past. Figuring out which hosts are vulnerable is very straightforward and can be done with a simple search.

Now that we know which hosts are vulnerable, we need to decide which ones must be patched first. Is the host exposed to the Internet, or is it firewalled from the world? Is the host a piece of production infrastructure, or is it just a test machine? This is where IBM Security QRadar Risk Manager enters the picture, which, as one of its functions, allows you to write policies that influence the prioritization of vulnerabilities. These policies can take into account not only the host’s security posture, but also firewall and IPS rules, routing information and flow traffic.

Here we have written a policy test if the server is in our production PCI network and also tests if inbound connections from the Internet can reach the host on the exposed port. The policy will then increase the risk of this vulnerability by a factor of 100 percent via the monitor mode and bring it to the top of our remediation list for patching.

But we can go even further: As previously mentioned, servers that are vulnerable to Heartbleed and have been exposed to attackers in the past also need to regenerate and apply their certificates. This could be the most expensive process for the enterprise in this whole scenario, so we want to make sure that we prioritize this properly. Due to its integrations with the rest of the QRadar product family, IBM Security QRadar Vulnerability Manager has the additional ability to filter on hosts that have actual traffic on a port. If we want to know which hosts not only are susceptible to Heartbleed, but also have communicated on this port in the past, the software allows you to determine if a new certificate actually needs to be generated for this host or not.

This search shows that none of the machines that have the vulnerability have communicated using this port in the past 120 days. Therefore, we can rest assured that the likelihood of them having a compromised SSL certificate is low, and we can move them to the bottom of the priority list for new certificates.

As you can see, even with issues as severe and wide-reaching as Heartbleed, a proper application of security intelligence can not only reduce your exposure to the issue, but also save a lot of time and money while remediating. While we may not be able to predict when the next Heartbleed will be exposed, by using the right tools it is at least possible to create policies and procedures that can be used to reduce reaction times when these kinds of problems come to the fore.