Healthcare sector struggles to address Log4j vulnerability without ‘breaking’ critical applications

Healthcare faces the same struggles as federal government and well-resourced sectors in Log4j remediation, but compounded by ongoing patch management issues and reliance on legacy platforms that may force difficult decisions tied to critical applications.

In early December, researchers first disclosed a critical vulnerability found in the Apache Foundation’s Log4j logging tool. Since that time, researchers have uncovered further flaws and observed multiple malware variants and other threats directly targeting the vulnerability.

Researchers have continued to deploy fixes, as threat actors continue to scan for ways to exploit the vulnerability. But according to Cybersecurity and Infrastructure Security Agency Director Jen Easterly and Executive Director Eric Goldstein, there’s just not enough visibility to assess the bug’s impact, despite unprecedented levels of collaboration between stakeholders.

Log4j is “a Hydra of sorts, whether you’re in healthcare or not. You feel like you cut a head off of it and two more come back because you didn’t fully understand what you were dealing with in the first place,” Tony Cook, head of threat intelligence at GuidePoint Security told SC Media.

In healthcare, however, vulnerability management is a systemic issue, making mitigation of the Log4j flaw a massive undertaking.

Log4j is found in many of the basic applications used by a range of healthcare entities, Cook explained. The trouble is that “no one even knows how to upgrade without breaking different portions” of the device or application on which it resides.

There’s also a lack of visibility to identify the source of exploits, and confusion about the true impact of addressing vulnerable elements once found.

Cook likened it to layers of an onion. "You start to peel the layers back, asking ‘where does this go?’ ‘How does that affect this other portion?’” On one device, it’s possible for nearly the entire platform to run on some portion of Java because it was easy to write, 20 to 30 years ago. And so much of modern tech has been built on top of it.

In order for healthcare organizations to get to an acceptable risk posture for Log4j, they must identify where it exists within the environment. But, as noted, visibility into Log4j instances is a challenges for all sectors. 

The added difficulty in healthcare is that many leaders lack a general understanding of what those sub-dependencies are in the environment, whether it’s a vendor-related portion, or an app running on their own web server. Cook said understanding those relationships will be critical for remediation.

“It really takes that level of understanding their environment,” he continued. Search across the entire environment, find these class files, and then determine how to fix the issue without breaking it.

For Cook’s team, they’ll engage with an entity and deploy their toolset that has the ability to go out and find the class files. But if you ask the team directly whether they use Log4j, and if it’s something they’re worried about in terms of business risk, a lot of chief information security officers and administrators just don’t know.

Log4j is under active exploit, meaning the vulnerability can’t be part of the typical healthcare organization’s “accepted risk.” It must be rooted out, as attacker groups are scanning for the flaw, even if the entity isn’t, in an effort to gain a foothold onto the network.

Log4j remediation challenges and workarounds

Remediation tends to be split up into first assessing the greatest risk, which is typically found in externally facing access points, or in any location unauthorized access can occur. Cook stressed that most organizations are less concerned with vulnerabilities in more isolated networks.

The problem with Log4j remediation is that many exploit opportunities exist, even in the most isolated networks.

In one use case outlined by Cook, Log4j was found on an isolated network where it was logging to and sending requests, running commands in that environment and logging outside of the environment. The flaw was pretty well locked down.

So the question remains, how do you lock down a vulnerability that you can see and can exist nearly anywhere on the network? And how do you do so in healthcare, where an exploit could result in a patient safety risk or even the exposure of highly sensitive data?

For Cook, remediation is just half of the challenge. The CISOs he’s worked with on the ground to resolve Log4j challenges have struggled to even find instances on their network, in part because they rely too heavily on vulnerability scanning . Vulnerability scans are not going deep enough and typical flags aren’t triggering the right way, he explained. For the previous example, if the scanner was sent to the front-end web server, it wouldn’t have seen the impacted backend database actually running Log4j.

The scanner “would have just looked for that particular portion” and wouldn’t have caught it. Beyond scanning, such cases require a defense-in-depth approach.

“What we found is actually having an agency on the host itself, looking for those class files,” is where security leaders will find the most success, Cook said. “There are very specific instances that are vulnerable; determine where they’re located, and then ensure it’s patched, which is probably the No. 1 way to go about it.”

If an entity can’t patch discovered Log4j instances, it should remove those class files.

Another challenge within the healthcare network is that they simply don’t have the staff to test whether or not a patch or upgrade will break beforehand.

In other sectors, it’s possible to stand up the entire network and if it breaks without that class file, they can move along. For healthcare organizations, remediation will center on implementing mitigating factors to prevent exploits. This is an effort where healthcare historically fell short.

The vendor problem

At the end of the day, prevention begins with identifying where the particular Log4j instances are on the network, logging it as much as possible, then “trying to patch the whole way through.”

“But it’s not that easy,” said Cook. “A lot of times these are vendor-related issues where an entity doesn’t have the ability to go in and try to deal with it. They have to rely on the vendor to come through and deal with the affected portion.”

So for many in healthcare, it will mean finding the affected products and “segmenting it off as much as possible to only trusted networks, making sure that those things can kind of only be interacted with trusted devices, things of that nature.” 

When you can’t patch all of the time, Cook added that visibility is the final piece, which includes logging reviews and monitoring for suspicious activity. It's problematic in healthcare because “you're at the mercy of the vendor.”

A provider organization may want to implement a workaround, but it could potentially void the warranty of the product with a particular vendor. Instead, organizations are forced to just try to find a way to lock it down as much as possible and hope that it works. “A lot of times in healthcare situations that can break day-to-day profits,” he added.

“That’s where we're seeing a lot of the delay in trying to get this fixed,” Cook concluded. “But in the meantime, let's make sure everything's segmented. “Let's make sure that the risks can get pushed down, by ensuring you have visibility on portions and make sure that you know that they can't be touched by anything else.”