Yesterday, the US government’s Cyber Safety Review Board (CSRB) released a report concluding that the Log4j flaw will remain an “endemic vulnerability” for the foreseeable future.

The CSRB was first established in February 2022 following President Biden’s Executive Order 14028, and is responsible for reviewing significant cybersecurity events, and developing insights into how government institutions and private enterprises can protect themselves from threat actors. 

“The Cyber Safety Review Board has established itself as a new, innovative, and enduring institution in the cybersecurity ecosystem,” said CSRB chair and DHS under secretary for policy, Robert Silvers. 

“Never before have industry and government cyber leaders come together in this way to review serious incidents, identify what happened, and advise the entire community on how we can do better in the future. Our review of Log4j produced recommendations that we are confident can drive change and improve cybersecurity.” 

For enterprises, the renewed focus on Log4j highlights the importance of taking a more proactive approach to scanning for and patching vulnerable systems.  

A quick rundown of the history of Log4j 

The CSRB’s report comes just weeks after the Cybersecurity and Infrastructure Security Agency (CISA) issued a warning notifying organizations that threat actors were exploiting Lo4j in VMware Horizon and Unified Access Gateway (UAG) solutions.

Ever since Alibaba’s cloud security team reported the Log4Shell vulnerability to Apache on November 24th 2021, after noticing attackers were using it to deploy malicious code to servers running Minecraft, enterprises have been in a state of panic.

With over 3 billion devices using Java, security teams were under lots of pressure to update systems featuring Log4j before attackers could exploit them. 

Why won’t Log4j go away already?

While most organizations know that Log4j is a highly exploitable vulnerability that can be patched, the problem is that identifying systems that use it is easier said than done. Modern enterprises are using such a complex patchwork of systems on-premise and in the cloud, that it can be difficult to pinpoint what systems are vulnerable. 

“The complexity of patching unknown Log4j systems continues to add more difficulties for organizations. A purchased appliance may have a vulnerable version of Log4j without any knowledge of the organization,” said CTO and cofounder of automated threat detection and response provider Blumira, Matthew Warner. 

“There continues to be exploitation of Log4j across internet-exposed VMware Horizon servers that have not been patched, even within hours of CISA notifications of vulnerable hosts,” Warner said. 

Given the difficulties of patching these unknown systems, senior director of security operations at Bugcrowd, Michael Skelton, agrees that for enterprises and security teams, Log4j is here for the long haul. 

“Dealing with Log4J is a marathon, one that will take years more to resolve. Java and Log4j are prevalent everywhere, not only in core projects but in dependencies that other projects rely on, making detection and mitigation not as simple an exercise as it may be with other vulnerabilities,” Skelton said.  

The supply chain complication 

Of course, the security risks of Log4j aren’t just limited to vulnerabilities present in an organization’s own systems, but also those present in the IT assets used by third-party service providers, who are often reliant on exploitable third-party software. 

“Given management of open-source software is different than commercial software, and open source powers commercial software, reliance on a commercial vendor to alert consumers of a problem presumes that the vendor is properly managing their usage of open source and that they are able to identify and alert all users of their impacted software — even if support for that software has ended,” said principal security strategist at Synopsys Cybersecurity Research Center, Tim Mackey. 

As a result, it’s important for organizations to consider that upstream providers in the software supply chain might be relying on compromised open source technologies behind the scenes, which could leave their data at risk. 

For this reason, Mackey recommends that enterprises implement a trust-but-verify model, double-checking the provider’s security measures, systems, and practices, to check for any potential weaknesses that could increase the risk of a data breach. 

What can enterprises do? 

CSRB’s review of log4j provided 19 total recommendations that government agencies and private enterprises can use to secure their environments from threat actors.

At a high level, the board called for the “widespread development and adoption of capabilities, tooling, and automate frameworks that support developers with the daunting task of building secure software.” 

More specifically, CSRB recommends that enterprises maintain an accurate asset and application inventory, deploy vulnerability scanning technologies to monitor for and upgrade vulnerable versions of Log4j. 

It also recommends that enterprises develop both a vulnerability response program and a vulnerability disclosure and handling process to ensure that exploits are mitigating in a timely manner. 

Furthermore, CSRB recommended that organizations report all significant incidents around Log4j exploitation to the FBI or CISA. 

Going forward, for organizations, tools like vulnerability management platforms, attack surface management solutions, and bug bounty programs will play a critical role in mitigating these vulnerabilities wherever they exist in the environment.