The Log4j disclosure was a wake-up call to the healthcare industry: The ubiquitous bug is used in a wide-range of software packages and is incredibly easy to exploit. But the disclosure has likely further expanded the divide between entities with strong resources and those without.
Log4j is a remote code execution (RCE) vulnerability with a 10 out of 10 criticality ranking and almost certainly to be an effective entrance point for an actor, Dan Murphy, distinguished architect at Invicti, told SC Media.
The criticality rank is due to the ease in which it is to exploit and the overall impact it could have on an organization. That’s what makes Log4j so unique: it’s very easy to attack. RCEs lead to backdoors, later enabling further access for the hacker and likely the exfiltration of sensitive data, or modifying things, he explained.
“It’s as simple as adding something technically to a web request that causes a log to be issued, and that is such an easy vector. It's a no-brainer to try,” said Murphy. “It tends to impact systems that are stitched together of many disparate systems, quite a bit.”
With a very simple payload and without authentication, you can trick the opposing server into downloading and executing arbitrary code. An exploit gives an actor whatever they want.
The concern is, particularly for healthcare, is that an actor could use the flaw to do just about anything, like forging or modifying data, and using it as a vector to install ransomware or other destructive actions. Murphy stressed it’s “a wide-open gate that allows for many, many, many different types of exploitation.”
“It’s the reason why we have seen it resonate so much throughout the community and why it’s creating such a stir is because it is so powerful in the type of attack and the unlimited amount of damage it can do,” he said.
The growing chasm between those who scan for Log4j and those who don't
In the six months since its disclosure, the Log4j attacks and exploits have been widespread. While those with strong security workforces and resources have quickly worked to remediate the flaw, those without effective security teams or tools have not found similar success.
The nature of Log4j has caused some alarm, as many providers lack the security expertise and even the tools to make effective progress in closing these gaps. Healthcare has long struggled with patch management and legacy tech due to the very complexity of its ecosystem.
“When you have complicated systems, it's hard to get the visibility into how those systems are composed, what they're built off, particularly now, as software gets increasingly complex,” said Murphy. “It's this web of interdependencies and different things that means healthcare tends to feel these issues somewhat more keenly.”
Due to this nature, security leaders must take a holistic view of how all the applications within the network are connected, he warned. “Because it's really the ones in the back, or in the musty corner that don't get called every single day, those are the ones where the concern is.”
In healthcare, you may have a system that's talking to another system on the back end, and in many cases, that relationship between the two might be something that's not immediately obvious. He added that “it’s one of the reasons that we still have Log4j six months after its disclosure.”
There’s a very strong correlation between those who scan and remediate, and those that don’t. After the disclosure, there was a huge explosion and steady increase in cases tied to Log4j.
Invicti provides scanning services to customers to find vulnerabilities in tech, like web applications. With a limited view through the lens of its customers, Murphy’s team has seen a drastic reduction in Log4j detections over the last six months.
Invicti’s data further shows that more than 80% of these detections have been fixed, and clients that scan their own internal web applications are seeing a stronger reduction in Log4j instances.
The decline suggests that entities with these strong tools in place are “scanning their code and web applications with tools,” and then fixing the discovered flaws. Murphy said “it means the detection techniques are working and people are finding and fixing their code.”
But it still gets accidentally introduced in some ways because Log4j is so ubiquitous: it's a package that so many different people use. Sometimes the developer can introduce a dependency on a package that they think is secure because they don't know what it depends on. It can in turn, pull in another dependency of something, that in turn depends on Log4j.
A developer may say, ‘Hey, my new shiny micro service that sits in front of this legacy system is secure.’ But if it can talk to the back end, if it can send something that tricks that back end, issuing a log — that's a potential vulnerability,” he explained.
“It's insidious,” said Murphy. “Because modern software, particularly in healthcare … is composed of so many different parts, it gets glued together. And it's very easy to pull in these new vulnerabilities, not even knowing you're introducing a vulnerable version of software, by depending on something that is.”
Log4j a call to equipping, educating security leaders
Just this week, I am the Cavalry Founder Josh Corman told a Senate committee that there’s an awareness and adoption gap in healthcare. These provider entities are highly targeted but are “cyber-poor,” lacking the resources to do minimum hygiene.
So while other industries can effectively pivot to find such pervasive bugs, it’s highly likely that most small- to medium-sized providers and non-profits are not able to effectively remediate all Log4j instances.
For Murphy, the Log4j disclosure is “a wake up call for the industry to start automating against these things, instead of treating these attacks as one-offs.”
By placing scanning tools within the software development lifecycle, CISOs can readily use techniques that can flag changes within the tech, he explained. Then, whenever a build happens, the software can automatically be scanned, which “is the best way to guarantee success.”
There are a range of scanning types that could be useful, particularly instances of less obvious vulnerabilities. For example, software composition analysis, which finds all of the software on the network and the different packages within the software program, including the software bill of materials with details on device components and the software versions.
“Putting that scanning very far left in your development cycle is a wonderful way to make sure that you're never building software that depends on something that's not secure,” said Murphy.
As yet another example of the “cyber-poor” nature in healthcare, these types of tools may be ineffective without the security expertise to support their use.
Remediating Log4j takes an entity fully understanding what devices and connections exist within the enterprise network. Security leaders have long warned that manual inventories are impossible and inaccurate, so scanning tools and other tech can support the process.
But, as Murphy pointed out, these security tools are “very involved.” There are open-source tools out there that can support an experienced security leader with this type of project, but again, “they really require more expertise to be able to operate, determine if the false positives are true, or if they're false.”
“If you don't have the budget for using security tools, and you don't really have the know-how in-house on how to do scanning, that puts the organization in a hard spot,” he explained. “Because you really are making a trade-off between expertise at a managed service, which allows you to really find something.”
“Lacking in-house expertise does become hard,” said Murphy. “It's almost the worst thing you can do: use something and get that false sense of security.” Using something, maybe incorrectly, or maybe set up improperly, “can almost be worse because you really think that you're OK. That's almost the worst place to be at.”
In healthcare that means leveraging the data out there to communicate the risk to the board or other leadership, for further resources. As Murphy warned, “Log4j is just the beginning.”
Healthcare needs a systemic approach, while considering new ways to build and deploy software that can last. These policies should transcend into how software is built, ensuring security and potential flaws aren’t just an afterthought.
These procedures don’t necessarily need to be crafted for just Log4j, “but practices that can be put into build pipelines and the way CISOs structure the organization,” he explained. It provides CISOs with needed evidence to develop a comprehensive policy that shifts out of a reactive stance and into one that addresses issues as they arise.
“It’s the type of systemic change that we need, as an industry, as a security industry, and as a greater society,” said Murphy. “As more and more apps and devices come online, we really have to start thinking about security as a first order of concern, and not as an afterthought.”
