Observability is needed to help identify where Log4j is used and minimize any potential impact it may have until the software component is updated.
It has been almost nine months since security experts discovered a vulnerability in Apache’s Log4j software library. At the time, many claimed it was the most serious vulnerability they had seen in their decades-long careers. And because the software was so widely used and embedded in applications, it highlighted the need for security observability. Unfortunately, not much has changed since the initial discovery.
This month, a report by the U.S. Department of Homeland Security’s Cyber Safety Review Board declared Log4j an “endemic vulnerability.” The report explicitly warned the Log4j event is not over and remains deeply embedded in systems. “Community stakeholders have identified new compromises and new threat actors,” said the report’s authors, Robert Silvers, Chair, and Heather Adkins, Deputy Chair, both of the Cyber Safety Review Board. “We must remain vigilant against the risks associated with this vulnerability.”
The report noted the reason the security issues with Log4j are so impactful and lingering is due to the way applications are built today. “The scale and efficiency of our global technology infrastructure are made possible through the standardization of key building blocks,” said the authors. “These reusable building blocks, while useful for creating software at scale, also create dependencies and risks that are often not understood until they manifest as a security issue.”
So, a vulnerability in a software building block integrated into numerous other software packages means that every organization using those packages is at risk. It also means organizations may not know where vulnerable software lives within their environments. That is the case with Log4j. When such a vulnerability is easy for a malicious entity to exploit and obtain broad control over a compromised system, it can create a once-in-a-generation security event. That is why addressing the Log4j vulnerability is so critical.
See also: Log4j Vulnerability Highlights the Need for Observability
What’s needed to combat Log4j security problems?
Getting down to the details…Log4Shell, a zero-day vulnerability within Apache Log4j, a popular Java logging library, poses significant threats as it can be exploited for unauthenticated remote code execution (RCE). If exploited, it allows any bad actor to run code on a server. The challenge is that organizations do not know if their applications use the vulnerable software or where the software is deployed.
One way to address this issue is the look for activity using tools that provide visibility into the web, application, and network traffic. Organizations proactively monitoring such data can identify and understand what is happening and stop the exploitation’s impact. Such capabilities are core functionality in many observability platforms. Hence, observability is needed to help identify where Log4j is used and minimize any potential impact it may have until the software component is updated.
