US Cyber ​​Safety Review Board Warns Log4j Will Remain a Problem for Years

Yesterday, the US government’s Cyber ​​Safety Review Board (CSRB) released a report conclude that the Log4j will remain an “endemic vulnerability” for years to come.

The CSRB was first established in February 2022 following President Biden’s decision Executive Command 14028and is responsible for assessing key cybersecurity events and developing insights into how government agencies and private enterprises can protect themselves from threat actors.

“The Cyber ​​Safety Review Board has established itself as a new, innovative and sustainable institution in the cybersecurity ecosystem,” said Robert Silvers, chairman of the CSRB and DHS Undersecretary for Policy.

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

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

A brief overview of the history of Log4j

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

Since Alibaba’s cloud security team reported the Log4Shell vulnerability to Apache on November 24, 2021, after noting that attackers were using it to deploy malicious code on servers Minecraftcompanies have panicked.

With more than 3 billion devices using Java, security teams were under a lot of pressure to update systems with Log4j before attackers could exploit it.

Why isn’t Log4j going away already?

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

“The complexity of patching unknown Log4j systems continues to create more problems for organizations. A purchased device can have a vulnerable version of Log4j without any organizational knowledge,” said CTO and co-founder of automated threat detection and response provider. BlumiraMatthew Warner.

“There is still abuse of Log4j on Internet-exposed VMware Horizon servers that have not been patched, even within hours of CISA reports from vulnerable hosts,” Warner said.

Given the difficulties in 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 to solve. Java and Log4j are everywhere, not just in core projects, but also in dependencies that other projects rely on, making detection and mitigation not as easy as with other vulnerabilities,” Skelton said.

The complication of the supply chain:

Of course, Log4j’s security risks are not 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 often rely on exploitable third-party software.

“Since the management of open source software is different from commercial software, and open source is the driving force behind commercial software, relying on a commercial supplier to alert consumers to a problem presupposes that the supplier is properly managing their use of open source and that they are able to identify and alert all users of their affected software, even if support for that software has ended,” said chief security strategist at Synopsys Cybersecurity Research Center, Tim Mackey.

As a result, it is important for organizations to consider that upstream providers in the software supply chain may be relying on compromised open source technologies behind the scenes, potentially putting their data at risk.

For this reason, Mackey recommends that companies implement a trust-but-verify model, which double-checks the provider’s security measures, systems, and practices, to check for potential vulnerabilities that increase the risk of a data leak†

What can companies do?

The log4j CSRB review yielded a total of 19 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 automation frameworks that support developers in the daunting task of building secure software.”

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

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

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

For the future, 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 are in the environment.