Just before Christmas 2021, Verdict reported on the discovery of a vulnerability within Log4j. This was described by the UK’s National Cyber Security Center as potentially the most severe cybersecurity vulnerability in years.
Log4j is a Java library for logging error messages in enterprise applications, which includes custom applications, networks, and many cloud computing services. Log4Shell, a zero-day vulnerability in the logging library, allows attackers to remotely execute code and gain access to machines.
Go deeper with GlobalData
Last month, the new Cyber Safety Review Board—a public-private initiative set up by the US Department of Homeland Security to investigate major national cybersecurity incidents to improve US cyber resilience—produced a report on what it called the “December 2021 Log4j Event”, covering how the vulnerability occurred, the events surrounding the December 2021 disclosure of the vulnerability, and the lessons learned from it.
Having no ‘customer list’ hindered defenders
The report made clear that cybersecurity defenders faced a particularly challenging situation with Log4j. The vulnerability impacted virtually every networked organization and the severity of the threat required fast action. The fact that there is no comprehensive ‘customer list’ for Log4j, or even a list of where it is integrated as a sub-system, hindered defenders’ progress. It left both enterprises and software vendors scrambling to discover where they used Log4j.
According to the report, the pace, pressure, and publicity compounded the defensive challenges: security researchers quickly found additional vulnerabilities in Log4j, contributing to confusion and “patching fatigue”; defenders struggled to distinguish vulnerability scanning by bona fide researchers from threat actors; and responders found it difficult to find authoritative sources of information on how to address the issues. This culminated in one of the most intensive cybersecurity community responses in history.
The CSRB found that organizations that responded most effectively to the Log4j event understood their use of Log4j and had technical resources and mature processes to manage assets, assess risk, and mobilize their organization and key partners to action.
How well do you really know your competitors?
Access the most comprehensive Company Profiles on the market, powered by GlobalData. Save hours of research. Gain competitive edge.
Thank you!
Your download email will arrive shortly
Not ready to buy yet? Download a free sample
We are confident about the unique quality of our Company Profiles. However, we want you to make the most beneficial decision for your business, so we offer a free sample that you can download by submitting the below form
By GlobalDataSome organizations spent massive resources as they struggled with this problem. One US federal cabinet department reported that it had dedicated 33,000 hours to its Log4j vulnerability response to protect the department’s networks. These costs, sustained over many weeks and months, delayed other mission-critical work, including the response to other vulnerabilities.
One of the costs was also human, with the need for an urgent response and the challenges in managing risk contributing to professional burnout among defenders. This may have a long-term impact on the availability of cybersecurity talent, which is already in short supply.
Log4j remains deeply embedded in systems
In its executive summary, the CSRB said that it is not aware of any significant Log4j-based attacks on critical infrastructure systems. It also found that the exploitation of Log4j occurred at lower levels than many experts predicted, given the vulnerability’s severity.
Such a conclusion was criticized by the chief trust officer at one vendor, who argued in an opinion piece in Dark Reading that given how widely the logging library is used, it is difficult to accept that a significant vulnerability like Log4j did not cause any real damage to critical infrastructures.
The vendor added that the report saying there were no significant incidents was “no reason to drop our guard.” That is important because as the CSRB points out, the Log4j event is not over. The CSRB says Log4j is an “endemic vulnerability” with vulnerable instances of Log4j remaining in systems for perhaps a decade or longer. With community stakeholders continuing to identify new compromises, threat actors, and learnings, the Log4j story has a way to run.
