Log4j: The Ghost of Christmas Future?

Log4j

As part of Solutions Review’s Premium Content Series—a collection of contributed columns written by industry experts in maturing software categories— Hugh Njemanze of Anomali warns if you Scrooge your security team, you may receive a visit from Log4j, the Ghost of Christmas Future.

Premium ContentWhen the Apache Log4j vulnerability first became known late last year, security teams worldwide came face-to-face with a potentially devastating vulnerability that affected virtually every networked organization. The vulnerability affected a software component used by millions of computers worldwide running online services. Rather than being a single piece of software, Log4j, among the most deployed pieces of open-source software, was embedded into thousands of software packages. What’s insidious about the Log4j vulnerability is how the software has such a broad reach across systems within any given organization.

So, when a vulnerability in a software building block such as Log4j gets integrated into other software packages, it puts every organization that uses those packages at risk. As a report by the Department of Homeland Security’s Cyber Safety Review Board (CSRB) pointed out, “it also means that system owners may not know where vulnerable software lives within their environments. When such a vulnerability is also easy for a threat actor to exploit to obtain broad control over a compromised system, it can create a once-in-a-generation security event.”

Attackers could choose to exploit Log4j in different ways, including the deployment of remote-control malware and ransomware. And while there have been few publicly reported instances of the flaw being exploited to carry out a major breach, it’s very possible that attackers are simply biding their time and waiting for the opportune moment before striking.

It’s why CISA Director Jen Easterly described the vulnerability as “one of the most serious” in her career, “if not the most serious.” All of which ought to be sufficient incentive for enterprises to take steps to improve their network cyber resilience before the threat disrupts their operations. Yet while we’ve had nearly a year to prepare, we’re not in a better position to handle the vulnerability than we were a year ago.

The reason Log4j is especially compelling is because it’s so pervasive.  And if another threat like this materializes with similar characteristics, you will also want to adopt an approach that is proven to be more effective for Log4j than traditional approaches.

It comes down to a few simple things that apply to most types of breaches:

  • First, adopt defense in depth as a principle and a strategy. There are different techniques, but the basic idea is that if your adversary gets past one type of defense, then they will run into another obstacle you have prepared for them further down the road. And then sooner or later they either give up or at least you have delayed them, making it more expensive for them to breach your defenses.
  • Look to exhaust opponents by adopting proactive steps, blocking as much as possible with the deployment of firewalls and the addition of defensive layers to your infrastructure. Even if these measures fail to hermetically protect the organization, the additional steps will make it that much harder on intruders and perhaps help convince them to turn their attention elsewhere. For example, with ransomware, you should have a trusted backup of your systems that you can redeploy easily. As you think about how to deter ransomware attacks, it’s also prudent to prepare for worst-case scenarios by creating safe backups of your data. Ransomware attackers want to encrypt your data and block access to your system, forcing victims to pay up. But you can rest easy if you already have a backup safely stored away. You also need to regularly run exercises doing that redeployment in case it ever happens for real.
  • CSRB recommended that federal agencies protect themselves by scanning their networks and doing a better job regarding asset inventory. Enterprises should do the same, but while the task of identifying the attack surface is key, most existing tools stop at mapping out the attack surface. That poses challenges because if you do not know where there have been probes, interactions, breaches, or attacks against specific parts of the attack surface, it is hard to know what to patch or what to protect first.

Let us use the analogy of someone walking into their home and finding the floor covered in ants. Which room should they sweep first? And would it matter if they swept the room, or would the ants just fill it again in five minutes? Effective automation can help deal with vulnerabilities like Log4j. If you’re always keeping a handle on which systems are vulnerable to known threats and keeping them patched, you’ll be better positioned to avoid trouble later. You also should know which systems are more critical to the overall operations. If an enterprise runs 100,000 systems, which ones should it secure first? Which ones, if damaged or compromised, would cause the most pain?

A targeted approach can help better identify and pinpoint specific spots in the attack surface where probes, breaches or attacks have occurred. The implications are substantial: Instead of worrying about which of the nodes associated with those 100,000 systems need patching, it becomes a matter of being able to better identify the specific subset of nodes under threat. Imagine shrinking that 100,000 down to 100 points of focus, for example, and being able to subsequently protect them first. Beyond specific steps, it’s also about how you measure your team and your organization. Identify which systems are mission critical. What percentage of those are up to date on various protections? How does that percentage compare to last month, last quarter, or last year?

If you orient your operations accordingly, you’ll sleep a little easier. Otherwise, you may dread Log4j as the proverbial Ghost of Christmas future.

Hugh Njemanze
Follow Hugh
Latest posts by Hugh Njemanze (see all)