Healthcare Cyber Security and the Challenges with the Diagnostic Vendor Space

By Arthur F. Ream III, Senior Director of IT Applications & Integration | CISO, Cambridge Health Alliance

The U.S. FDA’s Center for Devices and Radiological Health (CDRH) has always remained committed to promote and protect public health, including the safe and effective use of medical devices and diagnostic devices that are connected to the Internet, hospital networks, and most any other medical devices.

Labs are becoming automated more than ever, which increases the risk on unsecured connected devices as someone can hack and use it to infiltrate the broader organizations infrastructure.

The diagnostic industry, specifically laboratory and radiology instruments, has consistently been a lagging industry for cybersecurity and addressing the risks associated with their products. Why? It’s my opinion that the majority of this is due to over-regulation and the expenses for recertification coupled with manufacturers who tie their software and hardware performance to an ever-changing operating system industry. 

Last year, the U.S. FDA issued warnings about Urgent 11 malware, which created vulnerabilities in medical devices.

We have a big gap between what is possible and what is probable. So, should hospitals and the healthcare industry be concerned?

The answer is “yes.” Ensuring lab devices remain secure from cyber threats is all about controlling access, and having a consistent, documented management process with your vendors is essential. In addition, access and connectivity to the network are paramount. Often you have devices in your diagnostic areas running a version of Windows, which is either at or near the end of life. Your institution is not about to replace instruments just because the vendor has failed to go back to recertify an up-to-date O.S. or has extended support from the O.S. vendor. Either way, you’re stuck making sure the connection is there in a form that is safe to the environment and provides timely results into your Electronic Health Record (EHR) for effective patient care – a true balancing act for any CISO and organization.

Labs are becoming automated more than ever, which increases the risk on unsecured connected devices. Someone can hack and use it to infiltrate the broader organization’s infrastructure. What is perhaps more likely is a vendor coming in to patch an extended support device and putting an infected USB drive in after using it at home and accidentally adding malicious software onto it.

Connecting a device to a network is like punching a tiny hole in that network, and you’re looking at potentially hundreds of interconnections.

Most manufacturers aren’t doing much to protect their devices from threats. They see cyber threats as minimal risks and the expense to mitigate the ties to defunct O.S.’s and their core diagnostic software is too great. 

From a manufacturer’s perspective, when the software or firmware update significantly changes the device, only resubmission of a 510(k) notification is needed for FDA.. The FDA’s device software functions and mobile medical apps policy does not require software developers to seek FDA re-evaluation for minor, iterative product changes. According to the FDA Guidance for Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software, notifications are not required for cybersecurity patches. Without fear of needing revalidation or altering the device’s function or results, users and manufacturers can install security patches to their devices.

So what is the problem?  In my opinion, it has several fronts. Many vendors work with their O.S. suppliers to develop firmware patches, but we are still faced with;

1) Logistics of updating patches,
2) Manufacturers may not push automatic patch installation,
3) Installation of a patch will alter the device’s operation.
My main point is vendors need to stop tying their software running instruments to a particular O.S. They need to disconnect the dependencies and code better software that can run independently of the O.S.

Under the Healthcare Sector Coordinating Council, FDA is co-leading the legacy device task group to define better current and future device management guidelines. The FDA is taking a tailored, risk-based approach that focuses on the software side of this equation. We all understand that software in the diagnostic industry spans a wide breadth. In contrast, some software carries minimal risk; those with dependencies to operating systems pose a greater risk to patients will require FDA review.

The immediate concern and focus should be on disconnecting the diagnostic software’s codependency from any operating system. The O.S. vendors cannot possibly care about your software when making changes and patches happen far too frequently for the industry to test – time to make the instruments agnostic of an O.S. version or update.  

Resources: For a list of device software function, manufacturers and developers can search the FDA’s public database of existing classification by type of software (for example, diagnostic). Approved/cleared device software functions will also be listed in the FDA’s 510(k) and PMA databases and on the FDA’s Registration & Listing Database.