Many security teams have been running hard for past few days looking to assess and address their organizations' exposure to CVE-2021-44228, aka "Log4Shell," a flaw disclosed within the popular Log4j Java-based logging library. While there is a significant and welcome amount of tactical information available from vendors and from collaborations on social media, there’s also an opportunity to take a broader view of this incident.

The vulnerability has been widely discussed, but in brief, code within Log4j was found to be susceptible to a remote code-execution exploit technique. By employing a unique code string, an adversary may be able to gain full access to a target system running Log4j.

An initial software patch was released on Dec. 6. However, as with other recent flaws in widely used software components, there have been significant ramifications for downstream third-party software makers that incorporate Log4j. Dozens, if not hundreds, are affected, including Apple, Amazon, and Google; those vendors have been working to update vulnerable software.

As with any incident response, it’s important to acknowledge that early information can often be supplemented by better insights later — indeed, as this piece was being written, a second vulnerability was uncovered, logged as CVE-2021-45046. With it comes updated guidance to upgrade to Log4j version 2.16.0. Meanwhile, numerous reports have surfaced of malicious actors using this vulnerability to trigger ransomware and other attacks, and Omdia expects further developments. But even now, we're able to start to gather important lessons.

Software Supply Chains Need Documentation
This incident is one more in a long line of supply chain attacks, most likely surpassing the SolarWinds software supply chain compromise of late 2020 in terms of its overall impact. The nature of today's globally interconnected software supply chain means vulnerable software components are likely to be a recurring threat for the foreseeable future.

This highlights the immense value of accurate and timely inventories, at multiple levels of abstraction. Specifically, as it relates to Log4j, the challenge is significant; it is a widely deployed library that can often exist not only on multiple systems but can also be invoked from different locations.

With software component inventories, software makers can take steps to quickly identify these issues, and one such method is a concept called a software bill of materials (SBOM) — an accurate, timely, and easily consumable description of the fundamental building blocks of software components.

For vendors, an SBOM can help them get timely information out to their customers on whether specific products are affected. For end users, having proper SBOMs for key applications significantly shortens the triage cycle, as they can potentially take action to restrict access to an affected application, or even take it offline, until a fix is made available.

The Cybersecurity and Infrastructure Security Agency (CISA) has been spearheading efforts around the development and use of SBOMs and has been providing updated information on the Log4j vulnerability. In a sad coincidence, the agency had previously scheduled an SBOM-centric event for this week.

Having an SBOM is not a panacea, but it can greatly help organizations avoid falling victim to exploits caused by software supply chain vulnerabilities.

For security teams looking to determine if they're exposed to this, a good inventory of systems/applications is the first step in determining whether they use the library in question. Here, teams should beware the challenge of striving for a "perfect" inventory: It's inevitable that environments change, so inventory information should be dynamic.

Least Privilege, Defense-in-Depth Remain Critical
Proven security principles, such as defense-in-depth and least privilege, also have a strong role to play. Many security teams understand these concepts well and wish to apply them to their organizations' software and solution deployments, but they are often met with resistance from other stakeholders, or lack the resources to deploy them.

The increased use of automation in IT — such as infrastructure as code, particularly when used in modern pipelines built around CI/CD — makes it possible for security teams to cooperate with developers to build more secure solutions from the start, and across multiple systems.

Least privilege also plays a key role, at the host, application, and network levels. At the host level, what actual privileges and capabilities does the process leveraging Log4j really need to have? Increasingly, the use of least privilege principles plus behavior monitoring alongside runtime protection can act as a powerful combination to contain the impact of an exploited system. Similar considerations apply to securing the Java applications themselves via features, such as controlling the use of remote codebases.

Importantly, at the network level, least privilege manifests itself via methods such as egress control. With Log4Shell being a two-stage attack — where the payload has to be downloaded from an attacker-controlled system — being able to lock down which systems the infected system can even initiate connections to is particularly useful.

Security Researchers Saw Potential for Log4j Vulnerability Coming
Lastly, there's also the reminder that it's wise to pay attention to security research. Back at Black Hat 2016, Alvaro Muñoz and Oleksandr Mirosh presented research on issues with JNDI — the underlying interface that Log4j uses — and is eerily prescient of today's crisis, though not naming Log4j specifically. That credit falls to Jeff Williams, from Contrast Security, who wrote here in 2018: "If an attacker was able to infiltrate a popular library like log4j, they would very quickly be running with privilege inside most data centers in the world."

This is, of course, little comfort now to teams running at 110% looking to address these issues, but it highlights the importance of giving security teams not only the access to relevant information from research but also the resources — time, money, political support, and more — needed to apply these lessons to an organization's own infrastructure and practices.

None of the lessons here should detract from the herculean work that security teams are undertaking to address this. More than anything else, they need support both through this crisis and beyond as they continue to help their organizations. Let's never forget that security is, undoubtedly, a team sport.