Log4j is everywhere. You can fix it, but first you have to find it

January 14, 2022

It’s easy to see just how important — and dangerous — the Log4j vulnerability is. What’s harder is devising an effective response.

As you may know, Log4j is an open-source, Java-based logging utility and library. Developed by the Apache Foundation, its use is pervasive but not usually overt — being embedded in many Java servers, applications and services to log security and performance information. You’ll also find Log4j in many industry leading enterprise applications and cloud services.

Since early December 2021, a zero-day attack has been circulating rapidly on the internet that takes advantage of what our partners at Tenable describe as “the most significant vulnerability in a decade.” Threat actors equipped with relatively unsophisticated exploits can take full control of a system. This means the range of potential threat actors is especially broad and may include crypto currency miners, state-sponsored groups and crime syndicates that specialize in extortion including ransomware.

In part because Log4j is so widely used, no one has been able to create a directory of all applications that use it. That means Log4j — and its easy-to-exploit vulnerability — is likely embedded inconspicuously in many organizations’ most important systems.

Clearly, now is the time to take action. Our security organization at DXC Technology has been working 24x7 to identify and patch thousands of these vulnerabilities for our customers. This process requires multiple steps, many of which must be repeated as new patches are released. What preventative and remedial actions should you take?

Patching with a purpose

The simple answer is: patch, patch and then patch some more. Of course, it’s not that simple.

Before you can patch effectively, you must first understand your complete IT estate. That includes not only your on-premises data centers, but also any offshore outsourcing partners, your software supply chain, cloud providers and managed services providers. Plus, given the shift to remote work during the pandemic, you may also need to consider your employees’ home networks and personal computing devices. This job should be somewhat easier if you’re fortunate enough to have a complete and up-to-date configuration management database (CMDB) with proper tracking capabilities. Unfortunately, not every organization has this.

Next, you’ll need to scan your servers and other devices for vulnerabilities, using endpoint detection and response tools. Some devices will likely have up-to-date patches, others may have patches that are out of date and still others may be completely unpatched. This inventory should include every device that provides an entry point into your organization’s network, even lowly printers, Wi-Fi access points, routers and IoT/OT devices.

Once you have this list, you can then prioritize remediation. Unpatched endpoints directly connected to the internet need to be dealt with first, since they represent an obvious boundary with the outside world. You need the ability to shut them down, if necessary, until they’re patched and up to date. Move next to your crown jewels —that is, those systems at the top of the priority list, including the CMDB and patching services you rely on to achieve remediation. Then move on to any other systems with out-of-date patches.

Don’t assume that you can wait for a later variant of the patch. Any delay extends the window for an attacker to find the vulnerable entry point and act. That’s a mistake we often see organizations make, and the consequences can be dire.

Communicating the risk

The work just described is extensive, but it doesn’t end there.

For one, you need to communicate and evangelize. You need to engage with your organization’s application owners, business units and subsidiaries.

Because these conversations will likely involve nontechnical colleagues, limit the use of cyber security terminology and focus on business continuity impact.

Explain what’s at stake from the perspective of their business lines. That might include estimating potential losses, delays, reputational damage and other setbacks. Also tell them what other groups within your organization are doing about the Log4j vulnerability. This should be a controlled two-way dialogue so you can work together to create and launch an effective and appropriate response. A central register that records the actions taken and shares lessons learned should always be available.

Another important to-do: Establish 24x7x365 technical support for Log4j-related issues. Why? Because you’ll need to handle different time zones with great speed. If there is an incident, you’ll want to respond quickly — ideally in a matter of minutes.

So, know what you have. Patch what needs patching. And make sure your colleagues understand the impact.

The threat of Log4j vulnerabilities is great. This issue could be with us for years. Wherever you are in this process, it’s important to take action now.