© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Managing Risk
Applying Cyber Risk Management To Medical Device Design Robert J. Caruso and Melissa Masters
About the Authors Robert J. Caruso, CISSP, is an information security architect in Corporate Information Security at Battelle Memorial Institute in Columbus, OH. E-mail: [email protected] Melissa Masters, BS, RAC, is director of electrical, software, and systems engineering in Consumer, Industrial, and Medical at Battelle Memorial Institute in Columbus, OH. E-mail: [email protected]
32
Recent U.S. Food and Drug Administration patient privacy and corporate proprietary (FDA) guidance recognizes that today’s medical information. Integrity means guarding against devices face a host of cyberthreats. Medical improper information modification or destrucdevice manufacturers, in turn, face the need to tion and includes ensuring information assess and mitigate cyber risks. By combining nonrepudiation and authenticity. Availability is the cyber risk framework of the National ensuring timely and reliable access to and use Institute of Standards and Technology (NIST) of information. with the existing International Organization for As embedded medical devices grow in Standardization (ISO) 14971 Safety Risk complexity and ability, an end-to-end cybersecuManagement (SRM) process,1 manufacturers rity framework is needed to ensure that they can leverage proven best practices to make their achieve the confidentiality, integrity, and devices safer and more effective. availability required for successful operation. The cyberthreat to medical devices is based Cybersecurity concerns have factored into on two factors. First, increasingly faster and medical device design for some time, but more efficient processors now additional attention has been Opening unintended enable full operating systems focused on the topic by recent to run on small implant FDA communications, doorways can devices. Previously, only including a recent guidance compromise medical dedicated firmware could have document2 and a safety devices in three major been used. Second, modern communication.3 These areas of cybersecurity: hardware can readily connect documents, however, lack to networks using wired and confidentiality, integrity, clear instructions on what wireless protocols. Both factors and availability. needs to be considered and offer markedly increased tested—a comprehensive capability for patients, physicians, caregivers, standard could be years away. To ensure safety and healthcare technology management (HTM) and effectiveness and reduce exposure to professionals, at the cost of opening unforeseen liability, device manufacturers need to be and unintended doorways into a device. proactive in defining and applying cybersecuOpening unintended doorways can comprority controls for their medical devices. mise medical devices in three major areas of The problem facing medical device developcybersecurity: confidentiality, integrity, and ment teams is complex; it involves securing a availability. Confidentiality refers to preserving device against an ever-growing number of authorized restrictions on information access cybersecurity threats while balancing usability, and disclosure, including means for protecting performance, and safety. A viable approach
Horizons Spring 2014
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Managing Risk
Horizons Spring 2014
33
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Managing Risk
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 experi-
Figure 1. Risk Management Framework
34
Horizons Spring 2014
ence 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.
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Managing Risk
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
Control Prefix
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
Family
Control Prefix
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.
Family
AC
Access Control
MP
Media Protection
AT
Awareness and Training
PE
Physical and Environmental Protection
AU
Audit and Accountability
PL
Planning
CA
Security Assessment and Authorization
PS
Personnel Security
CM
Configuration Management
RA
Risk Assessment
CP
Contingency Planning
SA
System and Services Acquisition
IA
Identification and Authentication
SC
System and Communications Protection
IR
Incident Response
SI
System and Information Integrity
MA
Maintenance
PM
Program Management
Table 1. Eighteen Security Control Families5
Horizons Spring 2014
35
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Managing Risk
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.
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: “AC-4 Control: The information system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems based on [assignment: organization-defined information flow control policies].” 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
Figure 2. Security- and Assurance-Related Controls5
36
Horizons Spring 2014
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
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Managing Risk
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 incorporat-
ing 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. n
References 1. International Organization for Standards. ISO 14971:2007: Medical Devices: Application of Risk Management to Medical Devices. Available at: www.iso.org/iso/catalogue_ detail?csnumber=38193. Accessed Feb. 25, 2014. 2. U.S. Food and Drug Administration. Content of Premarket Submissions for Management of Cybersecurity in Medical Devices: Draft Guidance for Industry and Food and Drug Administration Staff. Available at: www.fda.gov/downloads/ MedicalDevices/DeviceRegulationandGuidance/ GuidanceDocuments/UCM356190.pdf. Accessed Feb. 25, 2014.
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.
3. U.S. Food and Drug Administration. FDA Safety Communication: Cybersecurity for Medical Devices and Hospital Networks. Available at: www.fda.gov/medicaldevices/safety/ alertsandnotices/ucm356423.htm. Accessed Feb. 25, 2014. 4. National Institute of Standards and Technology. NIST Special Publication SP 800-37 Revision 1: Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach. Available at: http://csrc.nist.gov/publications/nistpubs/ 800-37-rev1/sp800-37-rev1-final.pdf. Accessed Feb. 25, 2014. 5. National Institute of Standards and Technology. NIST Special Publication 800-53 Revision 4: Security and Privacy Controls for Federal Information Systems and Organizations. Available at: http://nvlpubs.nist.gov/nistpubs/ SpecialPublications/NIST.SP.800-53r4.pdf. Accessed Feb. 25, 2014. 6. Gollakota S, Hassanieh H, Ransford B, et al. They Can Hear Your Heartbeats: Non-Invasive Security for Implanted Medical Devices. Available at: http://groups.csail.mit.edu/netmit/IMDShield/ paper.pdf. Accessed Feb. 25, 2014.
Horizons Spring 2014
37
Managing Risk
Applying Cyber Risk Management To Medical Device Design Robert J. Caruso and Melissa Masters
About the Authors Robert J. Caruso, CISSP, is an information security architect in Corporate Information Security at Battelle Memorial Institute in Columbus, OH. E-mail: [email protected] Melissa Masters, BS, RAC, is director of electrical, software, and systems engineering in Consumer, Industrial, and Medical at Battelle Memorial Institute in Columbus, OH. E-mail: [email protected]
32
Recent U.S. Food and Drug Administration patient privacy and corporate proprietary (FDA) guidance recognizes that today’s medical information. Integrity means guarding against devices face a host of cyberthreats. Medical improper information modification or destrucdevice manufacturers, in turn, face the need to tion and includes ensuring information assess and mitigate cyber risks. By combining nonrepudiation and authenticity. Availability is the cyber risk framework of the National ensuring timely and reliable access to and use Institute of Standards and Technology (NIST) of information. with the existing International Organization for As embedded medical devices grow in Standardization (ISO) 14971 Safety Risk complexity and ability, an end-to-end cybersecuManagement (SRM) process,1 manufacturers rity framework is needed to ensure that they can leverage proven best practices to make their achieve the confidentiality, integrity, and devices safer and more effective. availability required for successful operation. The cyberthreat to medical devices is based Cybersecurity concerns have factored into on two factors. First, increasingly faster and medical device design for some time, but more efficient processors now additional attention has been Opening unintended enable full operating systems focused on the topic by recent to run on small implant FDA communications, doorways can devices. Previously, only including a recent guidance compromise medical dedicated firmware could have document2 and a safety devices in three major been used. Second, modern communication.3 These areas of cybersecurity: hardware can readily connect documents, however, lack to networks using wired and confidentiality, integrity, clear instructions on what wireless protocols. Both factors and availability. needs to be considered and offer markedly increased tested—a comprehensive capability for patients, physicians, caregivers, standard could be years away. To ensure safety and healthcare technology management (HTM) and effectiveness and reduce exposure to professionals, at the cost of opening unforeseen liability, device manufacturers need to be and unintended doorways into a device. proactive in defining and applying cybersecuOpening unintended doorways can comprority controls for their medical devices. mise medical devices in three major areas of The problem facing medical device developcybersecurity: confidentiality, integrity, and ment teams is complex; it involves securing a availability. Confidentiality refers to preserving device against an ever-growing number of authorized restrictions on information access cybersecurity threats while balancing usability, and disclosure, including means for protecting performance, and safety. A viable approach
Horizons Spring 2014
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Managing Risk
Horizons Spring 2014
33
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Managing Risk
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 experi-
Figure 1. Risk Management Framework
34
Horizons Spring 2014
ence 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.
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Managing Risk
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
Control Prefix
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
Family
Control Prefix
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.
Family
AC
Access Control
MP
Media Protection
AT
Awareness and Training
PE
Physical and Environmental Protection
AU
Audit and Accountability
PL
Planning
CA
Security Assessment and Authorization
PS
Personnel Security
CM
Configuration Management
RA
Risk Assessment
CP
Contingency Planning
SA
System and Services Acquisition
IA
Identification and Authentication
SC
System and Communications Protection
IR
Incident Response
SI
System and Information Integrity
MA
Maintenance
PM
Program Management
Table 1. Eighteen Security Control Families5
Horizons Spring 2014
35
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Managing Risk
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.
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: “AC-4 Control: The information system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems based on [assignment: organization-defined information flow control policies].” 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
Figure 2. Security- and Assurance-Related Controls5
36
Horizons Spring 2014
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
© Copyright AAMI 2014. Single user license only. Copying, networking, and distribution prohibited.
Managing Risk
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 incorporat-
ing 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. n
References 1. International Organization for Standards. ISO 14971:2007: Medical Devices: Application of Risk Management to Medical Devices. Available at: www.iso.org/iso/catalogue_ detail?csnumber=38193. Accessed Feb. 25, 2014. 2. U.S. Food and Drug Administration. Content of Premarket Submissions for Management of Cybersecurity in Medical Devices: Draft Guidance for Industry and Food and Drug Administration Staff. Available at: www.fda.gov/downloads/ MedicalDevices/DeviceRegulationandGuidance/ GuidanceDocuments/UCM356190.pdf. Accessed Feb. 25, 2014.
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.
3. U.S. Food and Drug Administration. FDA Safety Communication: Cybersecurity for Medical Devices and Hospital Networks. Available at: www.fda.gov/medicaldevices/safety/ alertsandnotices/ucm356423.htm. Accessed Feb. 25, 2014. 4. National Institute of Standards and Technology. NIST Special Publication SP 800-37 Revision 1: Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach. Available at: http://csrc.nist.gov/publications/nistpubs/ 800-37-rev1/sp800-37-rev1-final.pdf. Accessed Feb. 25, 2014. 5. National Institute of Standards and Technology. NIST Special Publication 800-53 Revision 4: Security and Privacy Controls for Federal Information Systems and Organizations. Available at: http://nvlpubs.nist.gov/nistpubs/ SpecialPublications/NIST.SP.800-53r4.pdf. Accessed Feb. 25, 2014. 6. Gollakota S, Hassanieh H, Ransford B, et al. They Can Hear Your Heartbeats: Non-Invasive Security for Implanted Medical Devices. Available at: http://groups.csail.mit.edu/netmit/IMDShield/ paper.pdf. Accessed Feb. 25, 2014.
Horizons Spring 2014
37
