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 Software Vulnerabilities

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.…

MSMQ QueueJumper (RCE Vulnerability): An in-depth technical analysis

13 min read - The security updates released by Microsoft on April 11, 2023, addressed over 90 individual vulnerabilities. Of particular note was CVE-2023-21554, dubbed QueueJumper, a remote code execution vulnerability affecting the Microsoft Message Queueing (MSMQ) service. MSMQ is an optional Windows component that enables applications to exchange messages via message queues that are reachable both locally and remotely. This analysis was performed in collaboration with the Randori and X-Force Adversary Services teams, by Valentina Palmiotti, Fabius Watson, and Aaron Portnoy. Research motivations…

X-Force prevents zero day from going anywhere

8 min read - This blog was made possible through contributions from Fred Chidsey and Joseph Lozowski. The 2023 X-Force Threat Intelligence Index shows that vulnerability discovery has rapidly increased year-over-year and according to X-Force’s cumulative vulnerability and exploit database, only 3% of vulnerabilities are associated with a zero day. X-Force often observes zero-day exploitation on Internet-facing systems as a vector for initial access however, X-Force has also observed zero-day attacks leveraged by attackers to accomplish their goals and objectives after initial access was…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today