A Framework for a Medical Device Security Program at a Healthcare Delivery Organization

The recent flurry of regulatory activity in the medical device security space is encouraging. Congress is clearly concerned about this topic, and several proposed bills (e.g., S.4336, Strengthening Cybersecurity for Medical Devices Act¹; S.3904, Healthcare Cybersecurity Act of 2022²) are steps in the right direction when it comes to holding medical device manufacturers (MDMs) accountable and ensuring that the Food and Drug Administration (FDA) is funded and staffed appropriately to deal with this issue.

With healthcare classified as critical infrastructure by the Cybersecurity and Infrastructure Security Agency and in light of global instability and a looming recession, it is not surprising that regulators are concerned and are finally heeding the warnings of cybersecurity experts.

During the last several years, a realization has occurred among healthcare technology management (HTM) teams that cybersecurity events can disrupt medical devices and directly affect patient care and safety. The role of healthcare delivery organizations (HDOs) in ensuring the security of medical devices as a part of the life cycle management is becoming more prevalent. Hospital administrators are concerned from a patient safety standpoint, as well as of the possibility of tarnishing the reputation of their institution. In many cases, HTM teams are not adequately trained in information technology (IT) and cybersecurity, which leads to a joint effort in tackling this space between IT and HTM departments.

To make things even more convoluted, information privacy and security teams do not generally report to the IT chief information office to avoid a conflict-of-interest scenario where IT departments are auditing their own work.

This article is a follow-up to one published in December 2021 about return on investment for a medical device security program.³ It is intended to provide a framework for an HDO to establish a medical device and Internet-of-Things (IoT) security program. The medical device design and market release process is heavily regulated by the FDA, but unfortunately, the process of establishing a medical device and IoT security program within an HDO lacks any centralized regulation or enforcement.

The silver lining is that many organizations (e.g., AAMI, National Institute of Standards and Technology [NIST], and others) have developed guidance and elements of a construct and a roadmap to build these types of programs. Some large health systems have mature medical device security programs, but the vast majority are at the beginning of their journey.

Medical devices are becoming more advanced, relying on the Internet, hospital IT networks, and mobile devices to function properly and share information. Focusing on the security of these types of devices to maintain device efficacy and ultimately patient safety is becoming increasingly important. These highly regulated devices are easy targets because they have a long life cycle (10–20 years in some cases) and usually are not up to date with the latest security best practices, in part due to the nature of the FDA 510(k) process.

Interconnectivity and interoperability of medical devices enable important advances in patient care, but these attributes also present security risks. Device security vulnerabilities can adversely affect device performance and the availability, confidentiality, and integrity of the device and its data. The maximum tolerable downtime for the health system decreases from days to hours when medical devices are compromised, and HDOs often do not have mature business continuity plans focused on medical devices.

The responsibility for medical device security is a shared one between the MDM and HDO. The program outlined in this article is focused on the HDO perspective.

Although the medical device security program proposed here is aligned with traditional confidentiality, integrity, and availability cybersecurity objectives, it requires additional patient care and safety considerations. The security measures taken are sensitive to not interfere with the device's intended usability or patient safety. Ultimately, the program is intended to reduce negative impacts on the delivery of care and to avoid the loss of sensitive health information.

Several security frameworks can and have been used by IT departments to address cybersecurity. These include the NIST Cybersecurity Framework⁴; ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection—Information security controls⁵; NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations⁶; or Secure Controls Framework.⁷ One of the most popular and widely adopted in HDOs is the NIST Cybersecurity Framework, which is a subset of NIST 800-53 and relies on certain elements in ISO 27002 but does not include all of the elements in both.

The medical device and IoT framework being presented with its 12 focus areas is primarily aligned with the NIST Cybersecurity Framework. This is one way to tackle this space; however, depending on your institution, there may be a need to modify or augment it. The focus areas are aligned with best practices and attempt to leverage existing groups and teams as much as possible to reduce the need for a large medical device/IoT security team. In most cases, the existing security policies, processes, and procedures need minor modifications and rewording to address medical devices. The 12 focus areas for the program are outlined in Figure 1. The focus areas are interconnected and, in some cases, have dependencies.

Figure 1.

Twelve focus areas of a medical device security program.

Maturing all 12 focus areas is critical for maturing the program. This article will expand on six of the focus areas that often need the most attention when building out a new program.

Procurement

The focus on procurement is intended to proactively capture security-related information about medical devices as they make their way through the sourcing and procurement process. The information provided by the vendor is used as one input into assessing the risk of introducing the device onto the HDO network. The goal of the medical device security procurement process is to ensure that HTM, IT, and security are presented with the opportunity to review a medical device before allowing it onto the network. This is intended to manage the risks associated with new medical devices being added to the network and to avoid adverse interactions with other networked devices.

Many departments and teams can purchase medical devices, but ideally, the requests should make their way to a central sourcing department. To assess the risk associated with introducing a medical device onto the network, a series of documents is required from the medical device vendors. These include:

• A Manufacturer Disclosure Statement for Medical Device Security (MDS²) document, which details the device's cybersecurity features and vulnerabilities.⁸

• An MDM's residual risk file.

• The software/firmware bill of materials (BOM).

• Any recommendation from the MDM regarding optimum security configuration.

• Detailed technical specifications for the device.

HTM, IT security, and members of the clinical community can review the responses and craft a risk assessment document back to the business. If an MDM provides no response or a poorly crafted response, this is a red flag to dig deeper into their maturity when it comes to security.

Vulnerability and Patch Management

Mature IT security programs generally have a high level of automation and a good handle on vulnerability and patch management. This is due to years of practice leveraging vulnerability scanners and dealing with sophisticated vendors that have streamlined the release of new firmware patches. Unfortunately, medical and IoT devices do not share this luxury. MDMs are incentivized and driven by the clinical efficacy of the devices, but they generally are not concerned with the underlying operating system (OS), threat modeling, or security concerns.

The design engineers will use the most convenient OS, which could be one that is legacy or no longer supported. A good example is Windows XP, which has been unsupported by Microsoft since 2014 but continues to be used in new devices being developed. To make matters more complex, these types of devices generally do not react well to traditional vulnerability scanners (e.g., Qualys, Rapid 7). The act of scanning a given device can affect its core functionality. The trends are concerning enough that medical device test labs at HDOs are hesitant to pull inventory out of the clinical environment to test. There is an apprehension that scanning a given device in the lab may affect its clinical functionality. In some cases, MDMs will void the warranty on a device if it is scanned by a vulnerability scanner without the MDM's knowledge or approval.

If your HDO intends to take the risk of going down this path, including language in the contract with the MDM spelling out this and the support expectation is paramount. The last thing anyone wants is a nonfunctional magnetic resonance imaging scanner that the MDM refuses to support because it was scanned for vulnerabilities and is no longer functioning to specification and expectations.

The most effective and automated method to deal with medical device vulnerabilities is by using a purpose-built medical device passive listening platform. These intercept and analyze data from the network without interacting with the medical device directly. This type of platform brings vulnerabilities to light and allows traditional vulnerability scanners to avoid medical devices on the network. A huge benefit to going down this path is that the vulnerabilities are prioritized and only the ones that matter to your organization are in focus. Attempting this prioritization manually while keeping up with the emerging 50-plus vulnerabilities disclosed per day is an unrealistic, herculean task.

A good way to augment this functionality is to establish a medical device lab where more intrusive vulnerability scans can be performed. Vulnerabilities should be tracked in a similar manner to risks, and the time window for remediation needs to be sufficient. In many cases, it may take MDMs months to create a patch for a given vulnerability.

Routine patches associated with ongoing preventive maintenance (PM) can be addressed by the HTM department based on its needs and the recommendations from the MDM. One of the keys to a successful program is for HTM to view security risks to medical equipment through the lens of PM. A medical device whose security has been compromised can cause harm and possibly death. To that end, the policies for onboarding, operating, and decommissioning medical devices should include cybersecurity considerations.

Asset Inventory and Management

The process of quantifying the risks introduced by IoT and medical devices to the business relies on two foundational elements. These are (1) attaining a thorough understanding of the inventory of connected medical devices and (2) carefully considering when new devices are being introduced into the environment. To manage the risks associated with medical devices, we must first have an accurate inventory of medical devices. Typically, several stakeholders within the health system maintain medical device inventories. These can include staff from HTM, radiology, lab, the simulation lab, and others. The largest documented medical inventory usually is managed by HTM and housed in the computerized maintenance management system (CMMS). The CMMS data does not typically include IT- or security-related elements and is not tied to the configuration management database (CMDB) that is used by IT.

IT and HTM see the world through their own biased lenses. IT is focused on mission-critical assets, while HTM primarily is dealing with mission/life-critical assets. In a typical healthcare facility, approximately half of medical devices are networked; therefore, the two groups have a growing interdependency. The CMDB is aligned with ITIL (information technology infrastructure library) principles, whereas the CMMS is not. It is designed for medical equipment life cycle management, and the data elements on which it is focused reflect that.

To improve the inventory alignment among the IT network scanning, network access control tools, and CMMS inventory, IT and cybersecurity data elements must be captured in the CMMS inventory record. These include data elements (e.g., MAC address, VLAN, wireless capability, OS, firmware). HTM can integrate collecting this information into its existing medical equipment onboarding policies. The additional information collected will help reconcile the inventory and provide insight into vulnerability and patch management, as well as risk management.

Governance

Governance is at the heart of the medical security program. It is an essential part of engaging with all the stakeholders, which can range from pharmacy to radiology, informatics, IT, lab, sourcing, and others. Having a clinical executive sponsor sets the appropriate tone around governance. Medical device security is not an IT issue, and ultimately, it boils down to patient safety and the institutional appetite and threshold for acceptable risks.

Governance encompasses two key areas, namely establishing the appropriate (1) policies/standards and (2) committees/workgroups for the program. The security team is responsible for shining a light on vulnerabilities and risks associated with medical devices and recommending remediations, but the clinical stakeholders need to choose which direction to take when it comes to addressing risks.

Policies that address the medical device life cycle within the health system have been around for many years, but they often lack specific security-focused language. These typically address preprocurement, procurement, deployment, operations, and decommissioning of medical devices. An overarching medical device security policy that points to other existing policies is a great way to pull all of the information into one document. The existing policies can be modified to include a security focus.

For example, part of the preprocurement policy can be requesting the appropriate security documentation from the MDM so that a risk assessment can take place prior to purchasing new devices. When it comes to operations, the policy will need to include how to deal with emerging vulnerabilities, and ultimately when the devices are decommissioned, any configuration or protected health information that may reside on a medical device needs to be scrubbed appropriately.

From a governance committee standpoint, three tiers are needed to effectively manage the program.

1. The highest tier consists of senior executives in the organization who report up to the board and need to be kept up to date with risks to the institution posed by medical devices.

2. Reporting into the highest tier is a security committee consisting of various stakeholders, including IT, HTM, lab, pharmacy, clinical specialties, radiology, and others. This committee can meet up to once per month to discuss emerging trends and specific risks being presented by different types of medical devices along with recommended remediations. The committee will need to make determinations on how to deal with the risk or, in some cases, accept it.

3. Reporting up to the medical device security committee is a medical device security workgroup consisting of subject matter experts who meet on a regular basis to discuss the outputs from the medical device security management tool. This is where different types of security controls are recommended and tracked. Only escalations or risks that have complex dependencies or some level of funding bubble up to the tier 2 security committee. Any exceptions or deviations from the policy are addressed and documented at the committee level. The diverse stakeholders are instrumental to ensuring that no policies are missed and that risks are classified and prioritized appropriately.

Vendor Management

The most effective way to manage security expectations from MDMs and vendors is to include these in the contract language. The Healthcare & Public Health Sector Coordinating Council released Model Contract-language for Medtech Cybersecurity, which outlines a number of clauses, including the availability of a software BOM and remote access expectations.⁹

The expectations around service-level agreements/service-level objectives and reaction times need to be clearly defined. One general pitfall to avoid is trying to predict the level of security maturity of a medical device based on the MDM's historical performance. A direct correlation between the two does not exist.

The organization should maintain contact information for the security group within each MDM to ensure that they can maintain an open line of communication and that they have the ability to reach out and triage security issues as needed.

Training

The ultimate measure of success is ingraining medical device security awareness into the organizational culture. That means staff members being on the lookout for concerning anomalies with medical devices and reporting these to the HTM and security groups for further investigation.

Routine, cross-functional training is required in order to attain this level of maturity. That means training IT on HTM concepts and vice versa, as well as training the business on the importance of and risks associated with medical device security. Medical device safety can affect patient safety directly, which is one of the most important measures for an effective HDO.

Conclusion

Standing up a medical device security program is no small feat, but the industry is full of thought leaders who are passionate about this topic and publish about it routinely. There is no need to reinvent the wheel when dealing with standing up a medical device security program. Others have paved a path that is now well traveled and proven when it comes to IT asset security. HTM teams can embrace the same model and modify it as needed to accommodate medical devices.

The journey is not a comfortable one and requires some adaptability, learning about new topics, and working outside our comfort zone. However, at the end of the day, it's worth it in order to protect our providers and our patients.