News & Analysis

OpenSSL Vulnerability – A Quick Action Guide

Ever since the vulnerability was brought forth a week ago, IT managers have been a worried lot. But not anymore as help is at hand

The OpenSSL vulnerabilities that was first reported a week ago had IT managers worried for some time. The reasons are obvious as such vulnerabilities directly hit the servers where enterprises usually store their most precious data assets, starting from user access controls. However, there is help at hand as Tim Mackey, Principal Security Strategist at Synopsys Cybersecurity Research Centre gives a quick action list: 


How not to perform an incident response – OpenSSL CVE-2022-3602

Over the past several days, there has been both anticipation and concern over a new vulnerability in OpenSSL. Some details of this vulnerability were leaked on Oct 28th, and there was an expectation that this vulnerability would have a “Critical” rating. Along with the leak was a statement that a patch would be available on Nov 1st. We now know that this isn’t a critical vulnerability, but rather a “high” one. We also know that there are two vulnerabilities in the patch.


What happened?

Not surprisingly, a vulnerability in OpenSSL is going to gather industry and perhaps even media attention. With the initial rating of Critical, we saw media attention ramp up. This media attention realistically served two purposes. First, it focused attention within both the technical and non-technical ranks of organizations who might be using OpenSSL. Second, it alerted the cyber-attacker community that there is something for them to focus their R&D efforts on – and that there might be a large target audience for such an attack.

Much of this chaos and increased software supply chain risk stems from the reality that publication of the existence of a vulnerability occurred before any patches were available. That then led to speculation, and in all likelihood some poor decision making by those attempting to protect their systems from an unknown attack as part of their response to what they believed to be a major incident.


What should have happened?

It’s important not to downplay vulnerability management efforts, but perspective and pre-defined processes are key elements in incident response management. In the early phases of the media and community reaction to what we now know as CVE-2022-3602, I was recommending that organizations perform a proactive scan of all of their software using tooling called Software Composition Analysis (SCA). SCA tooling scans the source code of an application and creates a Bill of Materials (BOM) for that application. If you don’t have access to the source code, major SCA vendors all have an option to scan binaries to create that BOM.

From an incident response perspective, you want to scan all the software your organization uses, regardless of its source or role. That includes commercial software, stuff that was freely downloaded, mobile applications and software like firmware that is included with hardware. Having a current, accurate and complete BOM for all software is a key to responding quickly to an incident like what we were expected from CVE-2022-3602.


How does a BOM benefit incident response?

Assuming you have a BOM for all software, you then can query each BOM and find out if the vulnerable version of the software is referenced by or linked into an application. If it isn’t then there is nothing else to do. If it is, then there is some triage work to be done. To make things simple, for the pre-disclosed OpenSSL vulnerability, you could simply include in the list of applications to triage anything that references any version of OpenSSL. We now know that the impacted versions of CVE-2022-3602 are 3.0.0 to 3.0.6 which means that the triage list could be further filtered to only those versions of OpenSSL.

With a list of applications to triage in hand, the next step is to identify where the patch for CVE-2022-3602 should come from. While SCA tooling can help solve this problem to a degree, knowing what is being triaged is far more useful. For example, if you know you are triaging a web application running on a Linux VM, then the OpenSSL patch should come from the distro that created that Linux version. This paradigm holds true whether you’re dealing with VMs, containers, firmware, mobile applications, serverless functions, or any other deployment context.


Decreasing time to identification and remediation

Obviously not all potential providers of a patch will issue their patch at the same time, but when the disclosure of a vulnerability is held under embargo until patches are ready from a majority patch sources, everyone is playing on a level playing field. Tooling like SCA can greatly assist in reducing the time to identify impacted applications and deployments. If you’ve heard about the concept of an SBOM, it provides exactly the same value as a BOM from an SCA tool. But as with SCA tooling you need to know how to use it for impact identification.

Time to remediation will of course be subject to how long it takes to validate patches and then roll them out. By shortening the time to identification and focusing triage efforts to only systems and applications directly impacted by a vulnerability, remediation becomes quicker and more efficient.

Leave a Response