Log4Shell Exposes the Mismatched Allocation of Resources in Healthcare Cybersecurity
This is some text inside of a div block.
January 22, 2022
By Axel Wirth, Chief Security Strategist at MedCrypt, Adjunct Professor at the University of Connecticut, and co-author of “Medical Device Cybersecurity for Engineers and Manufacturers”
Over the past few days the cybersecurity world has been rattled by the Log4Shell vulnerability that caused yet another mad scramble to identify whether a given organization and given system are impacted and if so, deploy the respective mitigation.
It appears that human capacity for response to these events is reaching (or already exceeding) its limits, especially since these vulnerability announcements tend to not be stable for a while with new information continually being added (in case of Log4Shell with a subsequent vulnerability in the proposed patch). Clearly, to make vulnerability management workable at scale we need better tooling to improve software transparency to the benefit of both vendors and operators.
Rightfully, Log4Shell earned a CVSS score of 10/10, positioning it in the top 5% range of disclosed vulnerabilities. Reports indicate that it is already being exploited with more than an estimated 1 million systems already having been attacked (and counting). To make matters worse, some have speculated that it is wormable and that the appearance of self-replicating malware is imminent.
As many times before, cyber adversaries have demonstrated their ability to move fast. Initial attempts to exploit the vulnerability were detected as soon as nine minutes after public disclosure. Within a few days, attacks turned from simple reconnaissance to data exfiltration and credential theft as well as started to use obfuscation techniques to evade compensating controls like firewalls.
We are on a concerning trajectory with more and more vulnerabilities of higher impact being discovered increasingly frequently. We are still in the weeds with Nucleus:13 and, just in time for the holidays, Log4Shell comes along.
As a medical device manufacturer, it’s critical to rapidly identify affected product versions, communicate to customers, and provide a patch (or other mitigation). On the user side, health systems need to identify affected systems, prioritize based on risk and exposure, and deploy patches.
The key to mitigation is proper software component transparency at scale. Manual efforts have let us down to date and demonstrate the need for a vulnerability management tool that provides reliable vulnerability analysis and enables the manufacturer to identify affected products and versions. Then subsequently enable the operator, via connection to their asset management system, to identify the physical devices. In other words, SBOM is the glue between the two and provides for efficient vulnerability lookup and communication.
Not meaning to downplay the need for human intervention, but the increasing prevalence of deeply embedded and pervasive vulnerabilities means resources must be allocated where they are most impactful. Applying resources (e.g., people) to the complex and time consuming identification process is inefficient, results in loss of valuable cycles, and leaves too much time for the attacker to benefit from their latest opportunity.
Strategy to date has not substantially protected nor enabled rapid remediation. What got us here will not bring us to a safer and more secure healthcare environment.
Learn more about Heimdall, the SBOM and Vulnerability Management tool from MedCrypt
Get the latest healthcare cybersecurity news right in your inbox.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
We'll never spam you or sell your information