Adopting FDA’s medical device cybersecurity draft to minimize security risks at healthcare organizations

Increasing threats and cybersecurity attacks against healthcare organizations and their infrastructures have led to the need for robust cybersecurity controls to ensure medical device safety and effectiveness. Cybersecurity incidents have often rendered medical devices and hospital networks inoperable, disrupting the delivery of patient care across healthcare facilities both in the U.S. and globally. Such cyber attacks and exploits may lead to patient harm due to clinical hazards, such as delays in diagnosis and/or treatment.

The WannaCry ransomware affected healthcare organizations and medical devices across the globe. Vulnerabilities identified in commonly used third-party components, like URGENT/11 and SweynTooth, have led to potential safety concerns. Last year’s ransomware attack on a German hospital highlighted delayed patient care when a cyberattack forced patients to be diverted to another hospital. The sector was also called upon to take immediate action to protect against Log4j exploitation.

Following these incidents, the U.S. Department of Health & Human Services (HHS) Food and Drug Administration (FDA) agency released its draft guidance that provides recommendations regarding cybersecurity device design, labeling, and the documentation that the agency recommends to be included in premarket submissions for devices with cybersecurity risks. Last month, the Healthcare and Public Health Sector Coordinating Council (HSCC) also rolled out a ‘Model Contract Language’ that provides a reference for shared cooperation and coordination between healthcare delivery organizations (HDOs) and medical device manufacturers (MDMs).

Deloitte evaluates that healthcare organizations are on the brink of many seismic shifts, as innovations and external factors will continue to elevate and introduce new risks. In view of the changing threat landscape, it has become imperative for cybersecurity and privacy to become fully integrated, by design, in the piloting and deployment of new healthcare services and solutions. Industry players are beholden to responsibly embrace the drivers of change and the challenges to deliver on the promise of the future of health and enable a safe and secure tomorrow.

Industrial Cyber contacted industry experts to assess the critical cybersecurity concerns for medical device manufacturers and how best the FDA draft document addresses these issues as healthcare organizations build their cybersecurity stance.

“Manufacturers face a number of challenges when designing and supporting medical devices. Data processing and analysis automation, and network and internet access support and enable significant advances in patient care and efficiencies in the delivery of that care,” Todd Ebert, president and CEO of Healthcare Supply Chain Association (HSCA), told Industrial Cyber. “Unfortunately, those same technologies introduce new risks in the form of cybersecurity threats that manufacturers must address.  As the draft FDA guidance notes, these threats go well beyond the safety and efficacy of the individual device but also to the networks and systems to which the device is connected and other devices connected to those systems and networks,” he added

Ebert added that, as the FDA points out, cybersecurity needs to be ‘built in’ to a device and not ‘bolted on’ after the device has been designed. For this, a manufacturer should follow this built-in approach not only to comply with regulations but also to assure that a cybersecurity event involving the device never causes patient harm, directly or indirectly; the device does not act as a gateway for a threat actor to compromise a system, network, or another device connected to that system or network. The device can continue to provide its basic clinical functions on a stand-alone basis, disconnected from all systems or networks.

“This philosophy assumes that at some point the device and systems and/or networks to which it is connected will be compromised, but that the essential clinical functions of the device must continue to be available,” according to Ebert. When a device or network is compromised, cybersecurity must include the response to and resolution of the associated threats and vulnerabilities. The FDA’s draft guidance provides a set of processes and procedures that manufacturers can utilize in addressing these key issues, he added.  

“In many ways, the concerns for medical devices and their manufacturers are the same as they were in 2018 when the previous draft came out; however, attacks on healthcare during the pandemic as well as recent geopolitical conflicts have raised the stakes,” Seth Carmody, vice president of regulatory strategy at Medcrypt, told Industrial Cyber.

According to Carmody, engineering devices that are safe and effective require that they are secure and that device makers conduct certain activities to right-size their security posture. “These activities are encapsulated within this concept of a secure product development framework or SPDF. The Agency is clarifying what SPDF activities are most important to meet their regulatory bar and what should be submitted to the Agency as evidentiary basis that those activities produced a device that meets regulatory expectations,” he added. 

Carmody also said that the document takes considerable effort to tie SPDF activities to current statutory authority including the Quality System Regulations (QSRs). “The guidance is also designed to help manufacturers tell their security story to the Agency in the most efficient way possible,” he added.

Moving across to the critical elements contained within the FDA draft document that could help jump-start negotiating important cybersecurity issues about procurement contracts within the healthcare sector, Ebert said that the HSCA recognizes the challenge manufacturers face in negotiating cybersecurity terms with thousands or more healthcare providers. 

“We hope that manufacturers conversely recognize the challenge providers face in negotiating those same terms and then implementing cybersecurity in practice on large complex networks involving thousands, tens of thousands or more devices from hundreds or even thousands of suppliers,” according to Ebert. In addition, all parties need to recognize that cybersecurity is a collaborative effort that requires vigilance and cooperation among all involved. 

Ebert also pointed out that in the fall of 2021, HSCA updated its ‘Recommendations for Medical Device Cybersecurity Terms and Conditions,’ which noted that suppliers should warrant their devices to be compliant with FDA premarket and post-market guidance regarding cybersecurity throughout the product’s lifecycle. “That recommendation intentionally does not specify any particular version of the guidance documents, recognizing that best practices in cybersecurity and the FDA’s guidance will evolve over time. We fully expect that after the FDA incorporates input from industry and the public in the updated guidance, our recommendation will not change,” he added.

Ebert added that a manufacturer’s compliance with the FDA’s proposed guidelines would address many of the terms in HSCA’s recommendations, including ‘warranting products’ to be free of known malware and vulnerabilities from delivery to end of service. It also assists HDOs in resolving cybersecurity threats and vulnerabilities promptly. This includes but is not limited to providing timely updates and patches, a portal for sharing vulnerability information, and a security contact. It further provides documentation of processes and technology for external access and remote support, including security authentication, authorization, and monitoring.

The FDA’s proposed guidelines also include the provision of a bill of materials describing the component parts of products, including a Software Bill of Materials (SBOM) to the HDO before implementation that includes software versions, patch levels, and patching plans, Ebert said. It also provisions a product roadmap depicting the product’s lifecycle, including end of service, end of life, and end of support. He added that it also addresses the use of an industry-recognized vulnerability scoring methodology and disclosure of that methodology along with processes, procedures, resources, and timelines for communicating and addressing identified vulnerabilities and threats.

Carmody said that he thinks “that if we compare the FDA’s guidance with the recently released HSCC’s Model Contract Language for Medtech Cybersecurity, we’d find significant overlap between what device controls should be built-in and what a hospital would ideally procure; devices that prove trust through cryptography, devices the notice when their security posture is compromised, and how the security posture of the device is maintained and co-managed by producers and consumers over the life of a device.”

Taking a closer look at how SBOMs can be adapted for healthcare organizations and what precautions must be taken, Ebert said that “we can expect the use of SBOMs to grow quickly within and without the healthcare industry now that the Cybersecurity & Infrastructure Security Agency (CISA) has described SBOMs as a key building block in software security and software supply chain risk management.” 

As standard formats and systems for assembling, disseminating, using, and maintaining SBOMs are still being developed, manufacturers and providers need to be prepared to adapt as those evolve, according to Ebert. “Ideally SBOMs will be machine-readable and maintainable ledgers of a device’s software components including software versions and patch levels. These can assist both manufacturers and providers in managing and identifying vulnerabilities. Entities which can manage these software components in an automated fashion will be able to identify known risks in a matter of minutes or hours, as opposed to days, weeks, or months for those searching manually,” he added.

Ebert also highlighted that it is not clear that healthcare organizations need any special adaptation of SBOMs as long as they also require and utilize Manufacturers Disclosure Statements for Medical Device Security (MDS2). “The SBOM will be associated with a device and that device will also be associated with an MDS2 which should provide any healthcare-specific information associated with the device. Once again systems and tools associated with managing and maintaining SBOMs and MDS2s are in their infancy so organizations seeking to implement solutions need to be agile and adaptable as those evolve,” he added.

“We expect that best practices in manufacturing and support would have most device manufacturers already logging all of the software components in their devices,” according to Ebert. “If that is the case, then the next step is to develop processes, procedures, and systems to put that information into a machine-readable/maintainable format and disseminate that information to device owners,” he added.

“A significant attack vector is through known vulnerabilities in commercial, off-the-shelf, COTS software products,” Carmody said. “Like many industries, using COTS software products has allowed medtech companies to build life-saving and life-sustaining technologies faster. Because of its ubiquity, COTS software is a target and its use comes with additional security burden; namely, knowing what components you’re using or operating, what’s vulnerable, and the risk incurred. It’s not specifically that SBOMs need to be adapted, but how they are consumed and actioned upon when healthcare organizations are resource-constrained,” he added.

Carmody raised a couple of precautions, including a raw list of software components that may be useful to some healthcare organizations, but the risk of a vulnerability in a given software component will be context-dependent, which is information that the producer would have to provide, the industry is working on ways to provide an SBOM and vulnerabilities with context.

He also said that currently, vulnerability information is typically published directly to the internet, there is some incurred risk that those who are specifically impacted by the information may not see it, and those who don’t need to see the information, such as attackers can use the information for nefarious purposes. “Both concerns could be resolved by using a clearinghouse-type entity, where access to information is limited to producers and consumers of the technology in question. A clearinghouse entity has been discussed, but doesn’t currently exist,” Carmody added.

The FDA has, among other things, recommended the use of cryptography. Analyzing how would cryptography help the healthcare sector and the role that purpose-built cryptography and certificate management would play, especially for medical devices, within the sector, Ebert said that the FDA’s draft guidance recommends the use of cryptographic algorithms and protocols for authentication and the encryption of data. 

“HSCA recommends that all data be encrypted in transit whenever practical and that authentication information (usernames, passwords, keys, etc.), personally identifiable information (PII), protected health information (PHI), as well as any confidential or sensitive information, should always be encrypted in transit and at rest,” Ebert said. “Cryptography can generally provide much stronger security than other methodologies. However, as the FDA recognizes, not all cryptographic algorithms and protocols are created equal, and it is important that medical device manufacturers utilize robust, industry-accepted cryptographic standards and algorithms in the design of their devices,” he added. 

The use of cryptography for certificate management could help manufacturers more securely access, monitor, patch, and update connected devices, according to Ebert. “Such support by the manufacturer over the lifetime of the device is a critical component of the cybersecurity of the device, but remote access is one potential point of weakness in the system. Being able to manage that support and access in a more secure manner would be a benefit for both the manufacturer and the device owner,” he added.

“Cryptography fulfills two main functions: the protection of sensitive information and the establishment of trust between devices or devices and users,” Carmody said. “Properly designed and implemented cryptography, including features enabled through PKI would certainly go a long way in helping the industry transition to a more zero-trust ethos; you see the call for zero-trust given the attacks on healthcare during the pandemic,” he added.

Carmody also said that the industry is transitioning from when devices were designed solely from a clinical feature perspective to including cryptography-based security features, such as basic sign/verify or encrypt/decrypt operations. “This transition presents a daunting challenge; namely that traditional IT cryptography infrastructure products such as PKI haven’t solved for the medical device use case, specifically current certificate standards are inappropriate for resource-constrained devices, many devices aren’t connected outside the hospital, and the producers of the device don’t own or operate the device; including those owned directly by patients,” he added.

“This leaves producers to retrofit traditional IT products, make their own, or partner with specialists; all those choices come with risks,” Carmody concluded.