By Sean M. Houle, CISSP
Medical device security has come a long way in the last 10 years, but so has the threat landscape. New product development often adds network capability as one of the benefits on everything from MRI machines to handheld thermometers and everything in between. Telemedicine has expanded in ways that we were just starting to explore 10 years ago. The vast numbers of these connected devices leave a target-rich environment for hackers.
Disruption of health care was once considered “off limits” in an unwritten code of ethics among malicious hackers, it appears this is no longer the case. Ransomware has been a particular favorite payload for attackers targeting the health care industry, with over 1,200 reported cases in 2021. Last year also saw what has been attributed as the first ransomware directly related death in the case of a baby born in Alabama whose doctor was unable to detect complications due to the unavailability of fetal monitoring data due to an ongoing ransomware attack during the time of delivery. It is difficult to measure what negative health care outcomes have come because of delayed care due to malicious cyber attacks. These things have caught the attention of lawmakers who have acted through the proposal of legislation.
The Food and Drug Administration (FDA) released its first guidance to medical device manufacturers in 2014 to assist those manufacturers in addressing cybersecurity issues in the premarket context. The FDA followed up two years later in 2016 with a similar guidance, this time addressing the postmarket portion of the lifecycle. Since that time manufacturers have responded in varying degrees to address cybersecurity. Some have chosen to conduct risk assessment and penetration testing of devices as part of premarket development, others have embedded endpoint security software into their products, there have been knowledge portals conveying suspected and confirmed security vulnerabilities and recommended remediation, while some manufacturers have even taken on maintaining repositories to deliver security patches and updates to endpoint security products on a regular basis. Others sadly leave cybersecurity as an afterthought or had good intentions at one point — creating RSS feeds and information portals — but the content has since gone stale, with no updates being posted in years. One thing to note is that this guidance released by the FDA is at this point just guidance, it is non-binding, with no obligation for manufacturers to follow it.
In the interest of a secure health care environment there has been an increased interest to address healthcare information security, and specifically medical device security, through legislation. This would codify the requirements that medical device manufacturers must address certain aspects of medical device security as matter of law. There have been several pieces of legislation introduced in the Congress recently to address this topic. One of the recently introduced bills is the Protecting and Transforming Cyber Health Care (PATCH) Act introduced in the senate on March 31, 2022, by U.S. Senators Bill Cassidy (R-LA) and Tammy Baldwin (D-WI). Representatives Angie Craig (D-MN) and Michael Burgess (R-TX) introduced companion legislation to the House of Representatives the same day. The bill primarily aims to address 4 main topics by means of making them a requirement for premarket submission to FDA. While the requirements are part of premarket certification, the bill addresses the need for cybersecurity throughout the entire lifecycle of the equipment.
The bill calls on manufacturers to have a plan to appropriately monitor, identify and address — in a reasonable time — postmarket cybersecurity vulnerabilities and exploits. The language of this requirement appears to be tied into the second requirement specifically because it identifies this as a postmarket requirement. The bill does not define what it considers a reasonable time, but perhaps it will depend on timelines published by the Cybersecurity and Infrastructure Agency (CISA) in determination.
The second requirement is that the manufacturer shall have a plan for a “Coordinated Vulnerability Disclosure” program. These types of programs allow a means for security researchers to communicate with manufacturers to notify them of security issues that they discover without fear of retribution to the individual or group that reports it. It also gives manufacturers time to address and fix these security issues before the findings are made public.
Patch, patch, patch. It’s one of the mantras of any good security program, almost to the point of being nauseating, nevertheless it is one of the best means of cyber hygiene. Unfortunately, many times it is easier said than done with medical equipment. Testing, applicability, patch at your own risk disclaimers have often plagued patch management among medical equipment. The PATCH Act states that the manufacturer will have processes and procedures to make updates and patches available on a reasonably justified regular cycle for what it calls unacceptable vulnerabilities, and as soon as possible out of cycle, for critical vulnerabilities that could cause uncontrolled risk.
The fourth requirement of manufacturers included in the PATCH Act is for manufacturers to furnish a software bill of materials (SBOM). This SBOM is to include commercial, open-sourced, and off-the-shelf software components of the system or device. One of the first rules of cybersecurity is that you can’t protect what you don’t know. That starts with knowing what IP addresses are assigned to what devices, but it does not end there. This is where an SBOM is worth its weight in gold. Many of the high-profile vulnerabilities we have seen recently (such as PrintNightmare, NSA Crypt, Zerologon to name a few) are related to operating systems. Determining what operating system a device is running is usually fairly simple or can easily be answered by manufacturers.
However, what happens when the vulnerability is not embedded in the OS and not in a running software version, but in certain versions of an open-source software library component that may or may not be implemented in a particular software, or may be implemented as part of another embedded third-party library?
We saw this with the log4j vulnerability, named log4shell, a vulnerability with a CVSS score of 10 out of 10. The race was on to identify which systems were affected through file name scanning, log parsing and network traffic analysis. This process resulted in both false positives and false negatives. An accurate SBOM could have identified systems positively having the log4j component that could be addressed immediately, reducing the pool of systems that had to be investigated through the manual process. An SBOM would also play a key role in providing an accurate risk profile during the risk management process by providing a means to assess potential threats of included software components more thoroughly.
Even as we wait for the legislative process to address these issues, contract language may provide an excellent opportunity to create a means of securing these and other valuable tools as part of the purchasing process. Regulation and legislation are nothing new to the medical device industry. Legislation regarding cybersecurity management seems like a logical progression as we strive to provide a safe and effective health care environment. It will not solve all the problems related to this issue, but it will certainly provide more tools to those charged with the mission to protect data and maintain uptime, amongst the many other tasks healthcare technology professionals provide every day. Stay vigilant.
– Sean Houle, CISSP, is an Information Systems Biomedical Equipment Support Specialist (IS-BESS) with the Department of Veterans Affairs in Louisville, Kentucky.
