The feedback from healthcare security leaders on the proposed Protecting and Transforming Cyber Health Care (PATCH) Act and updates to the FDA’s cybersecurity guidance for medical devices has been overwhelmingly positive, with the vast majority of stakeholders lauding the effort to secure newly introduced devices.
At the ViVE and RSA conferences, the medical device security sessions were keenly excited about the planned addition to require manufacturers to add a software bill of materials (SOMBs) to new devices. And this week, the American Hospital Association announced its support of the PATCH Act, as it treats device security like the patient safety issue it is.
For a number of years, AHA has “strongly advocated that the FDA must do more to encourage or require medical device manufacturers to enhance the cybersecurity of their medical devices,” AHA wrote in its letter to Congress in support of the bill.
While the FDA has made great strides in promoting “voluntary compliance with the FDA pre- and post-market cybersecurity guidance to MDMs,” enforcing the security elements outlined in the guide has been a serious challenge. These issues have left hospitals to deal with insecure medical device challenges on their own.
AHA notes that the Patch Act will tackle these compliance and security burdens and encourages the lawmakers to “maintain the key provisions of the original bill to ensure cyber safe and patient safe medical devices.”
The hope is that the lawmakers will keep the security by design, SBOMs, ongoing monitoring and identifying of post-market vulnerabilities, and coordinated vulnerability disclosure elements will remain in the finalized bill to ensure providers receive much needed support, while new devices are brought online with security in mind.
Although these efforts will tremendously reduce the security risks introduced to the network by new devices, some stakeholders are concerned about ongoing challenges these congressional efforts have not yet solved.
To be clear, the PATCH Act and the updated medical device guidance are critically important to ensuring that all devices moving forward are designed with security in mind, Greg Murphy, CEO and president of Ordr, told SC Media.
But even if, or when, these rules go into effect, providers will still face device security challenges for existing devices, particularly if they don’t have processes in place to effectively take advantage of these new resources.
Healthcare’s white whale: legacy devices
The FDA’s recent webcast on the ongoing updates to its medical device cybersecurity guidance revealed that the focus on SBOMs is one of the most talked about additions to the framework.
Indeed, it’s an item that healthcare security leaders have consistently asked from the FDA in recent years. The addition of SBOMs to medical devices will support healthcare providers with identifying where possible vulnerabilities exist on a device and will apply to all devices brought to the market.
Further, reports show the healthcare sector is essentially a model for other industries on SBOM adoption and its role in securing devices throughout the lifecycle.
To Murphy, SBOMs are a critical issue for shoring up patch management challenges. Healthcare was highly impacted by the Log4j vulnerability, and “to their credit, were very quick to try to move. But they were hindered by the fact they couldn't figure out which of their devices actually relied on or leveraged Log4j in the code.”
With an SBOM, it would support healthcare CISOs with the ability to do a query and parse when the vulnerability was on the network. The caveat, however, is whether the hospital has a designated security leader able to properly leverage the SBOM to swiftly patch once a vulnerability becomes known.
What’s more, the SBOM will only be included in devices going forward. So it may be “an awfully long time before that represents the bulk of the market in healthcare.”
As such, the key question at the top of everyone’s mind is: but what about legacy devices?
The challenge is that device security is often approached from an IT security perspective, assuming that devices have a two- to three- year lifecycle within a corporate environment before being replaced, such as a laptop or workstation, explained Murphy.
As previously discussed with a number of healthcare security leaders, legacy tech exists in a long list of platforms and devices within the hospital environment. One of the most common examples in a hospital is a hospital bed, which is actually a connected medical device with an expected life of 10 years to 12 years.
However, a hospital with 200 beds to 500 beds would never consider replacing a fleet of hospital beds after two years into its useful life because “it already has an out-of-date operating system.” In a larger hospital, that project would cost millions. The reality is the vulnerable bed will be in use within the healthcare environment for at least another nine years to 10 years.
“The PATCH Act isn’t going to do anything to address that vulnerability,” said Murphy. “That’s why healthcare’s device security challenge is such a huge problem.”
One of Ordr’s healthcare clients provided a keen example on why solving legacy challenges won’t be as easy as demanding the replacement of legacy devices.
The client’s chief information officer, who was new to the organization, decided the first order of business would be to take all of the Windows XP devices off of the network within the year. The healthcare client generated reports calculating the cost of the project: an estimated $600 million.
The other challenge is the sheer volume of manufacturers and types, “some of which have very advanced security programs and others that, frankly, don't,” he continued.
The resource gaps for healthcare delivery organizations are well-documented. But when it comes to device security, the resource challenges extend to manufacturers, as well. While there are big multinationals with strong, significant cybersecurity investments, there are manufacturers of niche or uncommon devices that don’t have those same opportunities.
There are a variety of manufacturers and even more complexities with provider types, as well as their resources to consider, explained Murphy. As a result, the medical device security equation is incredibly difficult to solve.
Murphy urged technology providers to think through automation, making it easier to find newly published vulnerabilities and provide clients with recommended actions. Because, as it stands, “we're relying on human beings to parse through all of this information and find what devices are connected on the network, and that problem is beyond human scale.”
Challenges extend beyond traditional medical devices
“It’s not just a medical device security problem,” said Murphy. So it’s important to “recognize that medical devices only represent 15% to 20% of the connected devices across the healthcare environment, many of which have some unique vulnerabilities.
For example, one hospital customer experienced a hack that began from an exploit of a vulnerability found in a parking gate, he explained. It happened to be a network-connected device, but the chief information security officer “had absolutely no idea it was connected to their network, at all.”
To Murphy, the most vulnerable device on the network is the one the security leader is unaware is on the network.
“Because no matter what the manufacturer did, no matter what processes and even with a sustainable process, if the healthcare provider doesn't know that they have that device on the network, it's very unlikely that it's going to be patched,” said Murphy. “It's highly likely it might be placed on a network segment where it doesn't belong and is vulnerable.”
Murphy’s team has found medical devices “sitting on the guest network that patients are accessing: that's an obvious problem.”
These issues are caused by departmental silos within the hospital network, with biomedical owning some devices and operating their own inventory databases and other departments following suit. When these departments fail to share data, vulnerable devices may be connected to the internet without the security team’s knowledge.
These incidents are not uncommon and should remind hospitals that even if these laws are passed and when the FDA guidance is updated that device security is solved for the healthcare sector. Although those efforts answer calls from industry leaders and close a range of vulnerabilities, Murphy noted that healthcare CISOs need a “whole hospital approach.”
In short, even if all medical devices are locked down within the hospital network, there will still be “enormous exposures.” In particular, the internet of medical things devices, or IoMT, are often directly connected to the internet, commonly lack strong authentication, and contain vulnerable or buggy software.
“Frankly, it's very easy for intruders,” said Murphy. “If they can find the weakest point or vulnerability to get into the network environment, it then enables them to spread laterally and potentially impact these critical IoMT and devices that have direct impact on patient care.”
Given the vast number of connected devices outside of the typical medical device category that are “vulnerable in very similar ways to the medical devices themselves,” he stressed that IoMT must be top of mind in the healthcare environment.
“It's only when you actually kind of take a step back and make the investment to automate inventory … across the entire hospital, the entire infrastructure, that you can truly accomplish the task, which means you have to be looking everywhere.” said Murphy.
“Because if you're not looking at the guest network, you're never going to see, ‘oh God, we do have several medical devices connected in a place of the network where they shouldn't be,’” he added. “That's really where applying automation and AI really is effective, but it has to be done on a kind of a whole hospital basis to be able to create a complete view.”
