Apache Log4j Flaw: A Fukushima Moment for the Cybersecurity Industry

Organizations around the world will be dealing with the long-tail consequences of this vulnerability, known as Log4Shell, for years to come.

The discovery of a critical flaw in the Apache Log4j software is nothing short of a Fukushima moment for the cybersecurity industry.

Ten years ago, an earthquake and subsequent tidal wave triggered the meltdown of the Fukushima nuclear power plant that continues to plague the region today. Similarly, the early exploitation of Log4j, during which attackers will go after the low-hanging fruit exposed by the vulnerability, will evolve over time to take the form of more complex attacks on more sensitive systems that have less exposure to the internet. And, just as Fukushima brought to light significant issues with longstanding processes in place at the plant, so too does the Log4j vulnerability, known as Log4Shell, highlight two crucial practices of concern:

• How organizations capture and protect their massive troves of log data; and
• The use of open-source code libraries as the building blocks for major enterprise applications.

The paradox of Log4j: the more you log, the worse it gets

We’re discovering new apps every minute which use Log4j in one way or another. It affects not only the code you build, but also the third-party systems you have in place. Everything from the new printer you’ve bought for the office to the ticketing system you’ve just deployed is potentially affected by this flaw. Some affected systems may be on premises, others may be hosted in the cloud but no matter where they are, the flaw is likely to have an impact.

To give you a sense of the sheer scope: already, we at Tenable are seeing customers auditing 1,000 systems per second and identifying one affected system per second.

The irony of this flaw is that it could end up enabling attackers to exploit the very logging practices that are the bellwether of sound security practices: the more secure your organization is, the more you’ll log every action, which means you’re sitting on a bigger pool of logging data with the potential to be exploited. The most mature security organizations typically capture the greatest amount of logging data in order to perform effective incident response and security remediation. The issue with Log4j at its core is that you can exploit it if you can get it to log arbitrary tracks; we’re dealing with very insecure data and the library, for some reason, treats it as if it has been sanitized.

Open source code libraries: building apps on shaky foundations

The Apache Log4j flaw shines a bright light on the risky practice of relying on open-source code libraries to build enterprise-scale applications. The Apache Foundation, which also gave us the Struts vulnerability in 2017, is a community-led organization that claims to make $22 billion worth of software products available to the public at large for no cost. For-profit organizations around the world reap the benefits of the foundation’s work every day. Yet, as an industry, we have not made it a priority to support the organization with funding that can promote a security-first approach.

With the demands of digital transformation and software development agility increasing exponentially every year, enterprises around the world have come to rely on open-source libraries as a key element in their ability to bring applications to market quickly. This dependence on what is effectively a wild, wild west of code libraries will continue to leave organizations vulnerable until they invest the time and resources needed to make them more secure. We’re long past time for the creation of a security classification system for open-source code libraries. Such a system would assign a security rating to each piece of code and provide users with visibility into how well the libraries are maintained from a security perspective.

If organizations are going to continue to make open source software a critical component of their custom development models, it’s time to have a set of standards and practices in place to enable a clean assessment of the criticality of every open-source component in their infrastructure and the ability to make sure security design is in place at every step in the development lifecycle.

Learn more: