Many orgs are still failing to address Log4j — here’s why 

Out of all the vulnerabilities discovered over the past few years, there’s one that stands out from among the cloud: Log4j. When the vulnerability was first identified in December 2021 after researchers identified a remote code execution exploit in the Apache Log4j Library, it became clear that billions of devices that used Java were at risk. 

While much of the uproar over Log4j has died down, many organizations are still struggling to eradicate the vulnerability completely. 

New research released by attack surface management provider, Cycognito, found that 70% of firms that previously addressed Log4j in their attack surface are still struggling to patch Log4j vulnerable assets and prevent new instances of Log4j from resurfacing within their IT stack. 

In fact, some firms are actually seeing their exposure to Log4j increase. Twenty-one percent of org’s with vulnerable assets reported experiencing a triple-digital percentage growth in the number of exposed Log4j vulnerable assets in July compared to January. 

Above all, the findings indicate that the Log4j debacle is far from over, and will continue to haunt organizations that aren’t prepared to proactively manage their attack surface and patch exposed systems. 

Is Log4j still a threat? 

Around a month ago, the U.S. Cyber Safety Review Board’s report renewed interest in Log4j and attempted to dissect the true long-term impact of the vulnerability.  

One of the key findings of the report was that Log4j is an “endemic vulnerability” that “remains deeply embedded in systems.”

The authors suggested that one of the key problems is that security teams are often unable to identify where vulnerable software lives within the environment. 

For senior security operations analyst at Forrester, Allie Mellen, the issues around mitigating Log4j come down to companies lacking a comprehensive software inventory.

“Without an accurate inventory of where the function is used, it can be very challenging to track down every single application it is used in the enterprise,” Mellen said. 

Once an organization has a software inventory, it can start to work toward patching vulnerable systems. With Log4j classified as a CVSS 10 vulnerability, it should be a top priority for security teams.  

“CISOs should work with application security teams, risk management teams, and cross-functionality with IT and development teams to prioritize patching Log4j,” she said. “There are a lot of competing priorities for these teams, but Log4j needs to be at the top of the list given the effects it is having on the ecosystem.”

While there are limited public examples of breaches taking place as a result of Log4j, there are some examples of significant damage being caused. Criminals have used the vulnerability to hack Vietnamese crypto trading platform ONUS, demanding a ransom of $5 million and leaking the data of almost 2 million customers online. 

In any case, Log4j provides attackers with an entry point they can use to exploit web applications and gain access to high-value personally identifiable information (PII) and other details. 

Rethinking attack surface management 

The key to identifying and patching Log4j vulnerable systems lies in leveraging a scalable approach to attack surface management, with the ability to discover exposures at scale and at the pace new apps and services are added by users to the environment. 

This is a task that legacy approaches to vulnerability management with limited automation are ill-equipped to address.

“Log4j is one of the worst [vulnerabilities] of the last few years, if not the last decade. Organizations are struggling to eradicate it, even when they have huge teams. Why? Because of the legacy input-based, unscalable approach,” said Rob Gurzeev, CEO of Cycognito. “That unscalable approach is a legacy mindset when it comes to external attack surface management, where scanning tools don’t scan often or deep enough into assets. Simply put, external attack surfaces are too vast and amorphous for status quo EASM [external attack surface management] solutions.”  

Gurzeev noted that the external attack surface is morphing constantly as organizations deploy new software-as-a-service (SaaS) applications, with Log4j not only impacting old systems but newly deployed ones as well. 

The attack surface management market 

One of the solution categories emerging to address vulnerability management of external-facing assets is attack surface management. 

Providers like Cycognito are working to address the challenges around attack surface management with solutions that can automatically scan the attack surface to provide security teams with more transparency over systems with vulnerabilities.

These solutions then provide security teams with threat intelligence they can use to identify the most vulnerable and at-risk assets. 

As more and more organizations seek scalable vulnerability management solutions, Frost & Sullivan, estimates that the global vulnerability management market will achieve a valuation of $2.51 billion by 2025. 

Over the past 12 months alone, security providers including Cycognito ($100 million) JupiterOne ($70 million), Bishop Fox ($75 million) Cyberpion ($27 million), and Censys ($35 million) all closed significant funding rounds in attack surface management.

Other competitors in the market include Microsoft Defender External Attack Surface Management and Mandiant Advantage Attack Surface Management, which aim to help enhance a security team’s ability to identify vulnerabilities and misconfigurations that put enterprise data at risk.