Why Log4j Vulnerabilities Highlight the Importance of DevSecOps

In December 2021, IT security teams and development organizations around the world got a rude wake-up call. Researchers had discovered a serious security vulnerability in the Apache Log4j utility, a popular logging component embedded in countless Java applications and services. News of this vulnerability set IT security teams and development organizations scrambling to find all instances of the vulnerable versions of Log4j on their own networks.

The Log4j vulnerability has also forced DevSecOps teams to answer a question that now feels less theoretical. If Log4j or any other vulnerability compromised an internally developed application, would security teams be able to isolate the attack and mitigate its damage? Do current DevOps practices prepare for an organization to go threat hunting quickly and effectively through its own code?

Let’s take a quick look at the Log4j vulnerability, what it means for DevSecOps teams, and how Zero Trust Segmentation from Illumio can help DevSecOps teams mitigate threats when vulnerable software is attacked before it can be fixed.

The Log4j vulnerability and why it matters

The vulnerability getting all this attention involves Log4j’s use of the Java Naming and Directory Interface (JNDI), a popular naming and lookup API for Java applications. Early versions of Log4j enabled JNDI’s message lookup substitution feature by default. Using that feature, attackers can submit carefully constructed messages to an application, forcing the application to execute code loaded from LDAP servers or other endpoints under the attacker’s control. That code could install malware, exfiltrate data, or perform other malicious actions on the application’s network.

Log4j is widely used. Google estimates that it’s in 4 percent of the Java packages in the Maven Central Repository, widely recognized as the most important Java package repository. Log4j is used in all kinds of software ranging from web applications to back-end services and custom apps for IoT devices.

As soon as this vulnerability was announced, IT security teams began scouring their networks, looking for file names and other indications of Log4j’s presence in any directory in their environment. DevOps teams got busy, too, searching through their own archives looking for any use of Log4j in their own applications.

The stakes are high. Cybercriminals have already used this vulnerability to launch ransomware attacks, install coin mining software on corporate networks, and infiltrate the Belgian Defense Ministry. Attackers are designing new forms of malware targeting the vulnerability. For example, new Night Sky ransomware targets Log4j vulnerabilities in VMware Horizon software.

The bigger picture: source code vulnerabilities and the risks they pose

The Log4j vulnerability highlights two larger problems for internal development organizations. First, no matter how well organized their DevOps tools and processes are, most organizations have difficulty determining all the components used in their applications, especially if those components are embedded as libraries or accessed through dependencies with other services.

In the case of Log4j, for example, it’s possible to include the utility in an application without leaving a Log4j JAR file sitting in a repository. Finding all the versions of all the software components — open source or otherwise — in applications is difficult, time-consuming work.

Second, if an application is discovered to be under attack because of a vulnerability, security teams need a way of isolate the attack immediately before the attack can spread to other systems on the network.

Catching and stopping Log4j attacks is important not only for protecting sensitive data and ensuring operational continuity, though those goals are obviously critical.

But there’s a compliance angle as well. On January 4, 2022, the U.S. Federal Trade Commission (FTC) announced that it would enforce penalties and fines against companies that permitted confidential consumer data to be breached as a result of the Log4j vulnerabilities.

Citing its $700 million penalty against Equifax for leaking consumer data because of an unpatched vulnerability in the Apache Struts framework, the FTC announced it “intends to use its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j, or similar known vulnerabilities in the future.”

Log4j, it turns out, is the tip of a massive iceberg of potential threats. To find and fix vulnerabilities not only related to Log4j but to any software component in their own applications or third-party applications they’re running, companies need comprehensive visibility into their software environments. Failing to find these vulnerabilities before they result in a data breach can lead to steep regulatory fines and lasting damage to an organization’s brand.

Fortunately, DevSecOps can help.

The role of DevSecOps in mitigating software vulnerability threats

The idea behind DevSecOps is simple: Security shouldn’t be an afterthought when it comes to developing and deploying software. Instead, security should be included in every step of DevOps, from design to development to testing to release and operations management. DevSecOps is the practice of building security into the software applications developed and managed through DevOps processes.

How can DevSecOps help address problems like the Log4j vulnerability?

First, DevSecOps best practices would call for development teams to use updated versions of components like Log4j when building and managing applications.

Second, DevSecOps would also call for development and test organizations to track the versions of all components, including open-source components, used in applications. That way, if the IT security community announces a vulnerability in a particular component, the DevSecOps organization can quickly determine which of their own applications, if any, are affected.

Equally important, DevSecOps best practices would call for embedding security controls within applications, so that when, inevitably, another open-source library or component is found to be vulnerable, teams can be prepared to contain any zero-day attacks against that vulnerability quickly and effectively. If defensive measures are already in place, the organization can act to defend against an attack, even if a patch for the vulnerability is days or weeks away.

One of the best security controls to embed is a Zero Trust Segmentation solution that uses the built-in firewalls on the systems to enforce security policies limiting network traffic only to authorized users and processes. By dramatically reducing the network paths available to attackers, Zero Trust Segmentation boxes attackers in, isolating them on the few systems they might initially manage to compromise. With Zero Trust Segmentation in place, attackers would not be able to download and execute code from a malicious site.

If an attack is isolated on the network, cybercriminals can’t spread ransomware to other systems. They can’t stealthily explore the network, looking for valuable data to exfiltrate. They’re stuck in place like a hapless burglar who’s managed to drop in through a skylight only to find themselves in a bear trap. They got in, but they’re not going anywhere. And an alarm has been sounded.

Illumio provides the visibility and automation DevSecOps teams need

Illumio Zero Trust Segmentation is a valuable security solution for any DevSecOps organization because it makes it easy for development teams to embed rigorous security controls into applications without having to learn the intricacies of network or security practices.

Illumio protects applications by making it easy for developers and security teams to define Zero Trust Segmentation policies. Once created, organizations can then easily enforce those polices using Illumio’s Virtual Enforcement Node (VEN) along with the host-based firewalls already built into the systems where the organization’s applications are running. The Illumio VEN is a lightweight, fail-safe client that can be easily included in software builds. No extensive design changes are required.

The Illumio solution uses firewalls but spares developers the trouble of having to program complex sets of firewall rules. Instead, it lets developers and security team define the policies they want enforced, permitting only the necessary traffic to pass through their applications, and then push those policies out to VENs embedded in applications for enforcement.

DevSecOps organizations can fine-tune policies for various applications and environments. Specifically, they can define policies based on:

• Roles within the application
• The application itself
• The environment the application runs in, such as development, test or production
• The environment's location: for example, a production environment in a U.S. West Coast data center

Then, the DevSecOps team simply adds an Illumio VEN to a software build. Once running in the application environment, the VEN enforces Zero Trust policies, raises alerts upon detection of suspicious lateral movement, and curtails traffic in response to active attacks, isolating infected endpoints from the rest of the network.

Illumio also offers a C-VEN client and Kubelink service for use in containerized environments, which are popular in microservices architectures. C-VEN is a lightweight Illumio agent, running as a pod on each node in a Kubernetes cluster, that protects the node and all the pods running on it. Delivered as a DaemonSet, C-VEN scales up and down as the cluster evolves. Kubelink is an Illumio service that monitors the Kubernetes API server to learn about resources within the cluster and provide Kubernetes context to the PCE. It is delivered as a package and requires only one replica per cluster, helping to make the Illumio container solutions highly scalable.

DevSecOps teams have two ways of interacting with the Illumio PCE: through the PCE user interface or its well-documented REST APIs. DevSecOps teams can use the APIs to integrate Illumio into CI/CD pipelines, so that Zero Trust Segmentation becomes a standard part of DevSecOps workflows. APIs also allow security teams to integrate Illumio with other security tools and workflows.

The Illumio product suite provides Zero Trust Segmentation wherever applications and services are deployed, including endpoints in:

• Data centers: Illumio Core
• Public, private or hybrid clouds: Illumio CloudSecure
• Endpoint devices: Illumio Edge

Log4j won’t be the last software component found to include a dangerous vulnerability. By adopting DevSecOps practices and using Illumio to enforce Zero Trust Segmentation in applications everywhere, organizations can be ready to protect their data, applications, and people while the time-consuming work of network scanning and threat hunting continues.

To learn more:

• Check out the solution brief, Illumio for DevSecOps.
• Contact us for a demo.