Race to patch OpenSSL is on again
Something different is occurring in the way new vulnerabilities are being disclosed is occurring that should be applauded, the maintainers of the OpenSSL project announced last week that on November 1st they would be releasing an update to the project that among other things addresses an unknown critical vulnerability.
Now later this week everyone, including cybercriminals, will know what that vulnerability is. However, cybersecurity teams now have advance warning that they need to make sure their organizations are prepared to immediately install an update to OpenSSL.
The OpenSSL community oversees the development of a cryptography toolkit for securing communications across the Transport Layer Security (TLS) protocol that is widely relied on by Web sites and applications. Most notoriously, a Heartbleed bug in OpenSSL discovered in 2014 that enabled cybercriminals to send a malformed heartbeat request with a small malware payload and large length field to any vulnerable Web site or application.
The level of disruption caused by the discovery of this flaw was significant. In some cases, as much as three years after the discovery of the Heartbleed bug, reports of breaches that exploited this bug were still filtering in. The patch that will be released this week will once again put the security incident response capabilities of many organizations to the ultimate test as yet another race against time ensues. Cybercriminals will undoubtedly be paying as much attention as anyone to the details of the OpenSSL disclosure that will be openly shared this week.
Exactly how vulnerabilities are disclosed is, of course, a sore subject among many cybersecurity professionals. The open-source community especially has tended to favor an approach where disclosures are publicly shared in keeping with the general ethos of a project that is maintained by a community. Over the years that has become especially challenging as the amount of open-source code embedded in a wide range of applications has exponentially increased. Many IT organizations are still looking for all the instances of a vulnerability in widely used open-source Log4J software used to collect log data from Java applications.
On the plus side at least, a good open-source security crisis is at least not going to waste. Maintainers of open-source software projects are now embracing everything from cryptographic signing of code to the automatic creation of software bills of material (SBOMs) that promise to make it easier to discover where instances of any piece of code might be running.
The issue now is to what degree are security incident response processes being improved to act on that information that is being made accessible. IT teams need to first be able to determine the severity of a vulnerability and then make sure best DevSecOps practices are employed to remediate the most critical vulnerabilities as quickly as possible.
There will no doubt be security breaches in the months ahead that will be traced to vulnerable instances of OpenSSL that were not patched. However, it’s also clear where the fault for not installing the necessary updates to prevent those breaches from occurring will increasingly lie.