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.


More from Intelligence & Analytics

Email campaigns leverage updated DBatLoader to deliver RATs, stealers

11 min read - IBM X-Force has identified new capabilities in DBatLoader malware samples delivered in recent email campaigns, signaling a heightened risk of infection from commodity malware families associated with DBatLoader activity. X-Force has observed nearly two dozen email campaigns since late June leveraging the updated DBatLoader loader to deliver payloads such as Remcos, Warzone, Formbook, and AgentTesla. DBatLoader malware has been used since 2020 by cybercriminals to install commodity malware remote access Trojans (RATs) and infostealers, primarily via malicious spam (malspam). DBatLoader…

New Hive0117 phishing campaign imitates conscription summons to deliver DarkWatchman malware

8 min read - IBM X-Force uncovered a new phishing campaign likely conducted by Hive0117 delivering the fileless malware DarkWatchman, directed at individuals associated with major energy, finance, transport, and software security industries based in Russia, Kazakhstan, Latvia, and Estonia. DarkWatchman malware is capable of keylogging, collecting system information, and deploying secondary payloads. Imitating official correspondence from the Russian government in phishing emails aligns with previous Hive0117 campaigns delivering DarkWatchman malware, and shows a possible significant effort to induce a sense of urgency as…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Unmasking hypnotized AI: The hidden risks of large language models

11 min read - The emergence of Large Language Models (LLMs) is redefining how cybersecurity teams and cybercriminals operate. As security teams leverage the capabilities of generative AI to bring more simplicity and speed into their operations, it's important we recognize that cybercriminals are seeking the same benefits. LLMs are a new type of attack surface poised to make certain types of attacks easier, more cost-effective, and even more persistent. In a bid to explore security risks posed by these innovations, we attempted to…