Applying Cyber Risk Management To Medical Device Design

Abstract

Recent U.S. Food and Drug Administration (FDA) guidance recognizes that today's medical devices face a host of cyberthreats. Medical device manufacturers, in turn, face the need to assess and mitigate cyber risks. By combining the cyber risk framework of the National Institute of Standards and Technology (NIST) with the existing International Organization for Standardization (ISO) 14971 Safety Risk Management (SRM) process,1 manufacturers can leverage proven best practices to make their devices safer and more effective.The cyberthreat to medical devices is based on two factors. First, increasingly faster and more efficient processors now enable full operating systems to run on small implant devices. Previously, only dedicated firmware could have been used. Second, modern hardware can readily connect to networks using wired and wireless protocols. Both factors offer markedly increased capability for patients, physicians, caregivers, and healthcare technology management (HTM) professionals, at the cost of opening unforeseen and unintended doorways into a device.Opening unintended doorways can compromise medical devices in three major areas of cybersecurity: confidentiality, integrity, and availability. Confidentiality refers to preserving authorized restrictions on information access and disclosure, including means for protecting patient privacy and corporate proprietary information. Integrity means guarding against improper information modification or destruction and includes ensuring information nonrepudiation and authenticity. Availability is ensuring timely and reliable access to and use of information.As embedded medical devices grow in complexity and ability, an end-to-end cybersecurity framework is needed to ensure that they achieve the confidentiality, integrity, and availability required for successful operation.Cybersecurity concerns have factored into medical device design for some time, but additional attention has been focused on the topic by recent FDA communications, including a recent guidance document2 and a safety communication.3 These documents, however, lack clear instructions on what needs to be considered and tested—a comprehensive standard could be years away. To ensure safety and effectiveness and reduce exposure to liability, device manufacturers need to be proactive in defining and applying cybersecurity controls for their medical devices.The problem facing medical device development teams is complex; it involves securing a device against an ever-growing number of cybersecurity threats while balancing usability, performance, and safety. A viable approach must view the device as part of an information system. No matter how specialized it is, a “smart” medical device connected to a network is, in essence, a node on that network. This is true even of devices often thought of as stand alone. Pacemakers and insulin pumps, for example, do not normally operate on a network, but they are very likely to be connected to monitoring equipment for programming or reprogramming, data off loading, or data streaming.Coping with the vast and fast-changing cyberthreat landscape means that development teams must implement cybersecurity from the beginning of the design process, rather than ad hoc after a device's core features have been defined. Because development teams already are familiar with applying SRM throughout the design process, integrating an established cybersecurity framework into proven ISO 14971–based processes leverages team experience and enhances confidence in both the approach and outcome.The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-37 provides an established framework that integrates readily with ISO 14971–based medical device development.4 The standard, which was developed to measure the security of computing environments in the Department of Defense and other federal agencies, applies a holistic approach to cybersecurity for information systems. Treating each medical device as a network node makes the NIST risk framework directly usable to evaluate the threats, vulnerabilities, and risks unique to network connected devices.While similar to ISO 14971, the NIST SP 800-37 risk management process includes more steps that recognize a device's interconnected status and its resultant exposure. Figure 1 summarizes the NIST framework.The SP 800-37 process shown in Figure 1 is similar to the current SRM process of ISO 14971. Consequently, a company that already is following ISO 14971 is well positioned to plug in cybersecurity risk management at the appropriate points in its existing phases of development. For example, the “categorize” step (step 1 of Figure 1) could be implemented up front as part of SRM planning (sections 4 [risk analysis] and 5 [risk evaluation] of ISO 14971), while steps 2, 3, and 4 of Figure 1 (select, implement, and assess security controls, respectively) could be folded into safety risk control, as described in section 6 of ISO 14971.An important feature of the NIST framework is that it uses the well-accepted security controls documented in NIST SP 800-53.5 These controls define the measurable protection boundaries of a system in a way that is very similar to identifying and implementing safety risk controls. A template of cybersecurity controls integrated with other safety controls forms an excellent starting point from which to ensure that a proposed device is safe and secure. By selecting cybersecurity controls early in the design process, with advisement and review by qualified cybersecurity engineers (i.e., “qualified individuals” are a requirement of ISO 14971,) the development team can use these controls to objectively measure the cybersecurity protection footprint for different proposed device designs. This objective measurement enables the design team to consider tradeoffs among usability, security, and safety, as discussed below.Applying the NIST process begins with analyzing the usefulness of specific controls to a particular device in the three areas of cybersecurity (confidentiality, integrity, and availability) mentioned above. The risk management framework of ISO 14971:2007 addresses availability and some aspects of integrity, but confidentiality and other aspects of integrity need increased attention during medical device development, as electronically transmitted control commands to the device may be monitored, spoofed, or altered.Implementing the NIST cybersecurity controls begins with step 1 (categorize), during which the design team categorizes risks as low, moderate, or high impact for each of the stated security objectives of confidentiality, integrity, and availability. The highest risk level in any of the three objective areas determines the way in which each particular control needs to be implemented. For example, if the risk to confidentiality for a certain control is high but the risks to integrity and availability risk are low, then the entire control will be implemented using the high settings.To start building the cybersecurity baseline for a particular device, the development team selects cybersecurity controls from the 18 families of controls documented in NIST SP 800-53 (Table 1). The controls themselves are well defined in the NIST document and thus for brevity may be referenced by their family identification (ID) and sequence number. Although the controls span many aspects of cybersecurity, each device has unique external interfaces and not all controls or families of controls will be needed for a specific device. The collection of security controls for a device class might appear similar to Figure 2, which for clarity highlights only the controls to be applied from the Access Control (AC) family.NIST SP 800-53 describes each control. An example taken from the callout in Figure 2 is Control AC-4 (Information Flow Enforcement). First, the control is defined5:The publication then provides supplemental guidance for applying the control, offers enhancements to cover special cases, and lists related controls. For each of the chosen controls, the development team fills in the blank by incorporating its specific requirement language (i.e., “organization-defined information flow control policies”). The team then combines the (highlighted) controls from the AC family with controls from other applicable families to form a security baseline for the class of device being developed. After the baseline for a device class has been created, it can readily be tailored for specific new devices within the class.During the design of a new device, the baseline set of controls can be used to evaluate each candidate technology using a yes/no (satisfies/does not satisfy) evaluation for each control. The collective score in each control family could be used to evaluate which areas of cybersecurity need more attention in the device, enabling weaknesses to be uncovered during the architecture and design phases of the development process. A high score in all areas, indicating a more secure device, could yield a marketing edge for new devices under development.An example of applying a cybersecurity control to a device can be found in a recent study in which a pacemaker was modified to accept biometric information from a patient's heartbeat as authorization for it to process commands from an external system.6 This control was added so that the device would not require a password for authentication when the patient was physically connected to the control computer. As a cybersecurity control, this is specified in NIST SP 800-53 as Adaptive Identification and Authorization (IA-10).As described above, IA-10 would be incorporated in the device's cybersecurity baseline. During development, the development team would be able to use the baseline to objectively compare the ability of each candidate design to satisfy the requirement, regardless of the specific technology used to do so.Baseline sets of controls also can be used as an assessment tool for existing devices, translating the list of controls into a template to objectively measure a device's performance in a given environment. Such a template could enable an HTM professional to assess competing devices for hospital or clinical use or procurement. For example, an HTM professional could measure a specific wireless monitor's compliance with the template, recording each potential control as a pass or fail. The cumulative score within each control family becomes the device's objective measurement, enabling the user to compare different wireless monitors from a cybersecurity perspective and to rate unknown devices relative to an established, tested unit.Of course, the cybersecurity and SRM processes described above must balance safety and security with effectiveness. In real-world use, a natural tension exists among these elements; therefore, a benefit/risk analysis, in accordance with ISO 14971 section 6.5, may be needed to adjudicate among conflicting elements. For example, a device might require a user to enter a username and a 10-digit password that includes capital letters, special characters, and numbers. Although such a protocol might increase security, it also could make the device totally ineffective if medical personnel in a high-stress situation cannot obtain access immediately. The balance among cybersecurity, safety, and usability must be carefully analyzed and documented, and the process used to resolve conflicts should be articulated in the overall SRM process.Cyberthreats to medical devices are increasing, and cyber risk management techniques have not kept pace. Fortunately, cybersecurity risk management practices have been developed, refined, and proven in large computer systems through the guidance of NIST SP 800-37 and the medical device community's SRM system based on ISO 14971. By incorporating cyber best practices into an already robust risk management process, forward-looking organizations can actively enhance medical device cybersecurity to make their products safer and more effective.