Most IT people have heard of Apache’s log4j security flaw. It is a flaw that allows a malicious person to take remote control of a server. A critical flaw that needed to be remedied urgently, mid-December 2021. It sounds simple, but the situation was very complex. First, most common versions of log4j had the flaw (versions 2.0-beta9 to 2.14.1). While the flaw was discovered on November 24, 2021 by a cybersecurity researcher at Alibaba, it took until early December to have a fixed version 2.15.0. In the meantime, our researcher “friend” who had the generosity to alert Apache, also published the code allowing to exploit the flaw.
A few days later, the protection mechanisms that had been implemented in this version 2.15.0 were circumvented by cybercriminals, and this resulted in the corrective version 2.16.0 *** copy/paste *** copy/paste * ** copy/paste *** to finally arrive at version 2.17.1.
But why has this flaw taken so much space in the news? Because it is critical, it is easy to exploit, the code to exploit it is available, it can be exploited remotely… and what else? Ah yes, log4j is used everywhere, everywhere, everywhere. This flaw had a huge impact all over the world. Organizations, and not the smallest ones, have found themselves unable to serve their customers. The Government of Quebec had to put more than 4000 government websites offline as a preventive measure for several days. And such scenarios have been repeated almost everywhere.
How could this flaw have put so many organizations out of service? How does log4j find itself at the heart of the business conducted by the entire planet?
The first affected are software publishers who use log4j. Their products have suddenly become the cause of security incidents all over the world. These software publishers therefore had to work around the clock to provide remediation to their customers. These customers not only had to patch the servers (yes, operating systems, virtualization platforms, databases, etc. were also affected), but also contact each supplier to obtain remediation for each software package and deploy the remediations. It was a nightmare and a lot of people’s holidays were ruined. And afterwards, the organizations realized that they had forgotten certain systems: the server for the security cameras, the SaaS application for cash management, etc. January was also the scene of intensive activities to solve the log4j problem.
Finally, all of that is now behind us. Or is it not?
Log4j is one software component among tens of thousands of others that may be present in your computing environments. Who knows what other software component will affect you in the future? Will there be another log4j this year? Next month? What will these variants be called?
In the field of engineering, there is the notion of product nomenclature (Bill Of Materials (BOM) and Software Bill Of Materials (SBOM). These nomenclatures list, in a hierarchical way, the list of all the parts, components, materials, etc. that make up a physical product, and therefore by analogy the list of open source components, libraries, etc. that make up software. The United States is considering making BOMs mandatory for all products manufactured in the United States. It is an excellent idea.
As CISO, why wait for a law? Already demand BOMs from all your suppliers. At the next flaw affecting a software component, you will already know which products, which applications, which platforms, and therefore which business processes are affected. And you will be able to handle the situation much more proactively.
Are you a software publisher? Know that tools like Grype and Syft can help you produce these BOMs.
Let’s also ask ourselves the following question: open source is generally maintained by the goodwill of a few volunteers. How relevant is the presence of open source in critical business processes*? Support contracts exist for some open source components and these contracts have well-defined service levels. This is definitely something to consider.
* Let’s ask ourselves one more question: Is there a difference between open source and merchant software? Not necessarily, once the flaws are discovered, the patches are developed either by the free collective or by the vendor.
Some vendors are excellent at providing these fixes, some are not. Some collectives are good and others less so. Application code is made by humans, and humans are almost always the weak link in cybersecurity. Don’t ask yourself if the software you use will have vulnerabilities, instead ask yourself when. And deploy mechanisms to protect yourself in the event of an application vulnerability.
