A cyber risk scoring system for medical devices

Accepted Manuscript

A cyber risk scoring system for medical devices Ian Stine, Mason Rice, Stephen Dunlap, John Pecarina PII: DOI: Reference:

S1874-5482(17)30063-X 10.1016/j.ijcip.2017.04.001 IJCIP 219

To appear in:

International Journal of Critical Infrastructure Protection

Received date: Revised date: Accepted date:

23 December 2016 27 March 2017 29 March 2017

Please cite this article as: Ian Stine, Mason Rice, Stephen Dunlap, John Pecarina, A cyber risk scoring system for medical devices, International Journal of Critical Infrastructure Protection (2017), doi: 10.1016/j.ijcip.2017.04.001

This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

ACCEPTED MANUSCRIPT

A cyber risk scoring system for medical devices Ian Stine, Mason Rice1 , Stephen Dunlap, John Pecarina

CR IP T

Department of Electrical and Computer Engineering, Air Force Institute of Technology, Wright-Patterson Air Force Base, Ohio 45433, USA

Abstract

ED

M

AN US

The increased connectivity of medical devices expedites patient treatment and provides lifesaving capabilities, but the lack of emphasis on device security has led to several cyber security breaches. Most medical professionals do not have adequate expertise in information technology or cyber security, yet they are responsible for assessing which medical devices provide the best balance of risk and probability of success. This paper proposes a cyber risk scoring system that considers a physician’s worst-case assessment of the potential of a medical device to impact a patient. The scoring system also relies on a security questionnaire based on the STRIDE model that helps generate a risk score for the medical device. Three test scenarios involving medical devices are used to demonstrate the application and utility of the risk scoring system.

PT

Keywords Medical Devices; Cyber Risk Assessment; Cyber Risk Scoring System

CE

Submitted: December 23, 2016; Revision: March 27, 2017; Accepted: March 29, 2017

AC

1. Introduction In 1961, Dr. Lawrence L. Weed began the development of the first electronic medical record system called the Problem-Oriented Medical Information System (Promise) [14]. His design was intended to reduce paperwork 1

Corresponding author: Mason Rice ([email protected])

Preprint submitted to IJCIP

April 14, 2017

ACCEPTED MANUSCRIPT

AC

CE

PT

ED

M

AN US

CR IP T

and simplify patient record keeping. Around the same time, physicians were developing the first implantable pacemaker [1]. These two electronic systems would eventually be incorporated into the Internet of Things (IoT). Along with record keeping and pacemakers, all manner of medical devices – thermometers, infusion pumps and electrocardiograms – are being brought online. Medical devices have made headlines as independent security researchers discover vulnerabilities that enable unauthorized access to the devices or cause the devices to function in a manner outside the manufacturers’ original intentions. In June 2015, Computerworld [21] published an article about medical equipment such as x-ray machines, picture archiving and communication systems (PACS) and blood gas analyzers being used by hackers as pivot points to gain access to healthcare networks. There are no published reports of cyber attacks on medical devices that have resulted in patient harm or death, but this does not mean that they are not possible. Indeed, several researchers have shown that devices such as infusion pumps, pacemakers and insulin pumps can be manipulated to harm patients [10, 11, 32]. Industry and governmental agencies have recognized the need to enhance the cyber security of medical networks and devices. However, while government and industry work to improve device security, healthcare organizations are left to manage the modernization of their facilities, equipment, devices and procedures without an adequate understanding of the risks. Cyber security risk management needs to be incorporated in the entire healthcare process to ensure patient safety. The scoring system presented in this paper is designed to enhance the cyber risk assessment process for medical devices that leverage network connections. The scoring system is intended to aid healthcare organizations in identifying medical devices with the potential to harm patients or negatively affect patient care. To achieve this goal, three key objectives are addressed: (i) usability; (ii) cost; and (iii) easy-to-understand results. The utility of the proposed scoring system is validated using four test cases based on extensive research of marketed medical devices. 2. Regulation of medical device cyber security In 2009, the U.S. Congress enacted the Health Information Technology for Economic and Clinical Health (HITECH) Act. The act provides incentives for using (and penalties for not using) electronic medical, health and patient 2

ACCEPTED MANUSCRIPT

AC

CE

PT

ED

M

AN US

CR IP T

records [33], and was the first step in a lengthy ongoing endeavor to secure protected health information (PHI) [22]. Over the next four years, healthcare organizations began to increase their acceptance of network-enabled medical devices, but the healthcare sector also saw an increasing number of network breaches. According to the Identify Theft Resource Center, from 2009 to 2012, the healthcare industry moved from the industry sector with the fourth most data breaches to the sector with the second most breaches, trailing only the business sector [22]. This dramatic increase in security breaches occurred immediately after the HITECH Act was signed into law. Fortunately, the security breaches raised awareness of the growing problems associated with networked medical devices. The National Infrastructure Protection Plan produced by the U.S. Department of Homeland Security designates the Department of Health and Human Services (DHHS) as the entity responsible for ensuring the security of public health and healthcare [16]. In 2013, President Obama issued Presidential Policy Directive 21 (PPD-21) that emphasizes the need to address the growing security issues. The directive outlines the roles and responsibilities, strategic imperatives and implementation guidance, and hands them over to sector-specific agencies. In particular, the directive assigns to the Department of Health and Human Services the responsibility for securing healthcare and public health [19]. Full 47 years after the first implantable pacemaker, the Joint Commission on Accreditation of Healthcare Organizations released a sentinel event alert about the safe implementation of health information and converging technologies [13]. The alert highlights many factors that contribute to harmful computer-technology-related errors. The factors include an over-reliance on vendor advice (without oversight by an objective third party), not carefully considering the impact that technology can have on healthcare processes and the failure to quickly fix technology when it becomes counterproductive. It should be noted that the production and marketing of medical devices are highly regulated. For a device to reach the market, it must conform to specific requirements outlined in the Code of Federal Regulations and pass an extensive approval process conducted by the U.S. Food and Drug Administration.

3

ACCEPTED MANUSCRIPT

AN US

CR IP T

2.1. Code of Federal Regulations The Code of Federal Regulations (CFR) is a codification of general and permanent rules published in the Federal Register by the departments and agencies of the U.S. Federal Government [31]. Title 21 of the Code of Federal Regulations contains the portions of the code that are regulated by the Department of Health and Human Services and the Food and Drug Administration. Parts 800 to 898 specifically cover the manufacturing and security of medical devices. The code emphasizes the need to ensure patient and operator safety. One of the key regulatory requirements is that a medical device should be categorized as Class 1, Class 2 or Class 3 based on its safety and clinical effectiveness. All the regulations use broad terms to discuss the documents and content that a manufacturer must present in order for a medical device to gain approval. The interpretation and enforcement of these requirements are left to the agency responsible for enforcing the regulations.

AC

CE

PT

ED

M

2.2. Food and Drug Administration guidance The Food and Drug Administration is a subordinate organization to the Department of Health and Human Services. The Food and Drug Administration claims responsibility for: (i) ensuring the safety, efficacy and security of medical devices; and (ii) advancing public health by helping speed innovations that make medical products more effective, safer and more affordable [30]. Because of its involvement in the regulatory process, the Food and Drug Administration is uniquely positioned to influence and regulate medical device cyber security. To enhance industry and public understanding of its interpretation of Title 21 of the Code of Federal Regulations, the Food and Drug Administration periodically releases guidance on various subjects [29]. In January 2005, the Food and Drug Administration released Guidance for Industry – Cybersecurity for Networked Medical Devices Containing Offthe-Shelf (OTS) Software [24]. This document identifies the manufacturer as the responsible party for the continued safe and effective performance of a medical device, including the performance of off-the-shelf software that is part of the device. The document also covers the reporting requirements for cyber security patches by stating that, in most cases, a manufacturer would not need to report a cyber security patch as long as it has evaluated the change and has recorded the correction in the product records. However, if a software patch impacts the safety or effectiveness of a medical device, the manufacturer should report the correction to the Food and Drug Administration [24]. 4

ACCEPTED MANUSCRIPT

AC

CE

PT

ED

M

AN US

CR IP T

While the guidance specifically states that it is intended for devices containing off-the-shelf software, these concepts are incorporated on a larger scale in two recent guidance documents: (i) Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (issued on October 2, 2014) [25]; and (ii) Postmarket Management of Cybersecurity in Medical Devices (issued on December 28, 2016) [27]. The premarket guidance provides recommendations and information that a manufacturer should include in a Food and Drug Administration medical device premarket submission related to effective cyber security management. This guidance is intended to reduce the risk to patients by decreasing the likelihood that device functionality is intentionally or unintentionally compromised by inadequate cyber security [25]. The Food and Drug Administration guidance ties the suggestions for validation and risk analysis back to 21 CFR 820.30(g), which is the requirement for manufacturers to conduct design validation. This linkage enables the Food and Drug Administration to reject submissions that do not comply with the requirements. The Food and Drug Administration recommends five elements for cyber security and vulnerability management approaches [25]: (i) identification of assets, threats and vulnerabilities; (ii) assessment of the impacts of threats and vulnerabilities on device functionality and end users/patients; (iii) assessments of the likelihood of threats and vulnerabilities being exploited; (iv) determination of the risk levels and suitable mitigation strategies; and (v) assessment of the residual risk and risk acceptance criteria. Manufacturers are expected to self-identify vulnerabilities, associated risks and provide a list of actions taken to address the security issues. While the premarket guidance focuses on the requirements for receiving device approval, the postmarket guidance clarifies lifecycle management recommendations and emphasizes that manufacturers should monitor, identify and address cyber security vulnerabilities and exploits [27]. The guidance also clarifies expectations related to the reporting requirements. In the majority of cases, actions taken by manufacturers to address cyber security vulnerabilities and exploits involve routine updates and patches that do not require advance notification or reporting under 21 CFR Part 806. For a small subset of cyber security vulnerabilities that may compromise the essential clinical performance of medical devices (and present a reasonable probability of serious health consequences or death), the Food and Drug Administration requires notifications by the device manufacturers [27]. The postmarket guidance also references Executive Order (EO) 13691 – 5

ACCEPTED MANUSCRIPT

CE

PT

ED

M

AN US

CR IP T

Promoting Private Sector Cybersecurity Information Sharing. The executive order encourages the development of information sharing analysis organizations (ISAOs) to serve as focal points for information sharing and collaboration in the private sector and collaboration between the private sector and government. In addition to encouraging information sharing, the information sharing analysis organizations collect data and participate in the collaborative establishment of standards and best practices related to cyber security [23]. Executive Order 13691 outlines measures that should be taken to ensure that any collected information is treated as protected critical infrastructure information [27]. The postmarket guidance also specifies key definitions and elements that should be incorporated as part of a postmarket risk management strategy. Most of these elements are consistent with those identified in the NIST Framework for Improving Critical Infrastructure Cybersecurity [17]. The Food and Drug Administration guidance documents present wellsupported recommendations for improving the cyber security of devices. While the documents represent the Food and Drug Administration’s views, a statement included with each guidance document – “FDA’s guidance documents, including this draft guidance, do not establish legally enforceable responsibilities” – may undermine many of the suggestions. Thus, the guidance documents, which describe the agency’s thinking on a variety of subjects, should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited. The use of the word “should” in the guidance means that “something is suggested or recommended, but not required” [27]. The flexibility of the Food and Drug Administration guidance enables manufacturers to make their own decisions about cyber security. However, the lack of a concrete legal foundation makes it difficult to enforce cyber security requirements. 3. State of cyber security in healthcare

AC

From a cyber security perspective, the primary organizations reporting on the safety and security of medical devices are the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) and the Food and Drug Administration. While ICS-CERT has published numerous alerts and advisories warning about vulnerable devices, the Food and Drug Administration has rarely officially recalled a device as a result of its cyber vulnerabilities [28]. The Food and Drug Administration did, however, release an unprecedented 6

ACCEPTED MANUSCRIPT

CR IP T

alert for Hospira Symbiq Infusion Pumps, which were identified as having a vulnerability that could enable attackers to control the doses of medication provided to patients [9]. This indicates that the Food and Drug Administration treats cyber vulnerabilities in a manner similar to other device flaws. The proposed scoring system could help the Food and Drug Administration categorize medical devices based on their potential cyber security risks and outline enhanced testing requirements for the devices.

AC

CE

PT

ED

M

AN US

3.1. Risk framework implementation trends The healthcare industry appears to be adapting as cyber security awareness increases. In March 2016, Dimensional Research [5] released the results of a survey that focused on the adoption of security frameworks. In the survey, 338 participants were asked a range of questions in order to understand the security frameworks that have been adopted, the motivations for the adoption of frameworks and the degree to which the frameworks are adopted. The adoption of at least one security framework was the norm; however, the healthcare industry had the lowest adoption percentage of 61%. In contrast, the education industry reported 77% adoption while the other four industries (banking, information technology, government and manufacturing) reported 83% to 88% adoption. The survey also reported that only 3% of the respondents used a security framework other than the top four: (i) Payment Card Industry Data Security Council Standard; (ii) NIST Framework; (iii) CIS Critical Security Controls; and (iv) ISO/IEC 27001/27002. While the NIST Framework was reported as having the lowest adoption of the top four frameworks, the report indicated that, by the end of 2016, its adoption rate was expected to grow from 29% to 43%. This indicates that, although the NIST Framework is relatively new, many consumers are accepting the framework. Of the participants who reported the adoption of the NIST Framework, more than half indicated that significant investments are needed to ensure complete conformance to the five functions [5]. In summary, it is clear that healthcare is behind other industries in terms of cyber security controls and their widespread implementation.

3.2. Mayo Clinic In 2013, the Mayo Clinic invited computer security experts to test the security of approximately 40 medical devices [20]. Every device that was

7

ACCEPTED MANUSCRIPT

AN US

CR IP T

tested had substantial flaws. One of the experts noted that hospitals appeared to be roughly a decade behind the standard security curves of other industries. As a result of the tests, the Mayo Clinic began to update its information technology security practices. Some of the changes included incorporating language that specifically addresses medical device cyber security in documents and bolstering its in-house security team. One of the updated documents is the Mayo Clinic’s information technology medical equipment proposal questionnaire, which asks questions about product capabilities, lifecycle and account management, and whether the product manufacturer allows independent testing [3, 15]. Security experts have applauded the efforts undertaken by the Mayo Clinic, but they also recognize that few hospitals have the resources or influence to implement security measures [20].

PT

ED

M

3.3. Improving the current state Most of the recent improvements focus on addressing the lack of baked-in security in medical devices and improving communication within industry. Both these efforts will take time to mature and produce measurable results. In the meantime, the use and improvement of risk management practices in organizations may help protect patients and healthcare organizations from vulnerable devices. As discussed above, one reason for the lack of adoption of robust risk management practices is cost. The Mayo Clinic had the resources to establish its own internal security group in an attempt to identify flawed devices and implement risk management processes. However, most organizations lack the resources necessary to maintain security teams. Therefore, a low-cost, easy-to-use system for identifying and ranking high-risk medical devices would enhance risk management processes.

CE

4. Foundational components

AC

With the emphasis placed on securing healthcare networks, it is inevitable that the healthcare sector and regulatory agencies will effect change. The changes will promote better awareness of cyber security and improve the security of the medical devices and networks. The risk scoring system presented in this paper is intended to be used as part of a risk management framework (e.g., NIST Framework) and was designed using current industry concepts presented by the Escal Institute of Advanced Technologies (SANS Institute) and the Forum of Incident Response and Security Teams (FIRST).

8

ACCEPTED MANUSCRIPT

Table 1: NIST Framework core functions.

Description

Identify

Develop the organizational understanding for managing the cyber security risk to systems, assets, data and capabilities.

Protect

Develop and implement the appropriate safeguards to ensure the delivery of critical infrastructure services.

Detect

Develop and implement the appropriate activities to identify the occurrence of cyber security events.

Respond

Develop and implement the appropriate actions for detected cyber security events.

Recover

Develop and implement the appropriate activities to achieve resilience and restore the capabilities impaired by cyber security events.

AN US

CR IP T

Core Function

AC

CE

PT

ED

M

4.1. NIST Framework The NIST Framework was developed in response to Executive Order 13636 that called for a voluntary risk-based cyber security framework to enable organizations to manage cyber security risks. The framework, which is designed to be used by organizations that are responsible for securing the critical infrastructure, is endorsed by the Food and Drug Administration [25, 27]. To account for variations in the systems being secured, the framework contains modular components that can be implemented based on the desired results of a risk management process [17]. The NIST Framework establishes a hierarchical structure using five core functions to organize basic cyber security activities. Table 1 presents the core functions and their descriptions. Each function is further divided into categories based on cyber security outcomes tied to programmatic needs and specific activities. Sub-categories within each category represent specific outcomes of technical or management activities. While the sub-categories are not exhaustive, they provide results that support the outcomes in each category. The framework ties informative references to each sub-category to provide users with standards, guidelines and practices that are common among the critical infrastructure sectors [17]. The flexible nature of the 9

ACCEPTED MANUSCRIPT

CR IP T

NIST Framework makes it a great choice for healthcare organizations, but a complete implementation could require more resources than are currently available. The risk scoring system presented in this paper is designed to alleviate some of the resource requirements by simplifying the process of calculating and ranking the cyber security risk of medical devices.

CE

PT

ED

M

AN US

4.2. FIRST Common Vulnerability Scoring System The Common Vulnerability Scoring System (CVSS), created by FIRST, is designed to be a robust scoring system for information technology vulnerabilities [6]. The scoring system was developed using collaborative input and is free to use. Several entities, including the National Vulnerability Database (NVD) and the Common Vulnerabilities and Exposure (CVE), use the scoring system in their databases [18]. Common Vulnerability Scoring System (Version 3) generates three groups of metrics: (i) base; (ii) temporal; and (iii) environmental. The base group covers the intrinsic qualities of a vulnerability, the temporal group reflects the characteristics of a vulnerability that change over time and the environmental group captures the characteristics of a vulnerability that are unique to a user’s environment. The base metrics produce scores ranging from 0 to 10, which can then be modified by scoring the temporal and environmental metrics [6]. The Common Vulnerability Scoring System calculator created by FIRST presents a user with the various metrics divided into the three metric groups with a series of defined values for each metric. After values are selected for the metrics in a specific group, the data is combined to generate the base score. The base score must be generated to receive the temporal and environmental scores [7]. These scores draw on increasing amounts of information to provide a more accurate score for a given situation. The scores can be used as part of a larger risk management process. The Common Vulnerability Scoring System calculator provides a simple user interface that requires minimal knowledge of the scoring system.

AC

4.3. SANS Institute attacker objectives The SANS Institute is a cooperative research and education organization that specializes in information security and cyber security. Its InfoSec Reading Room has published a paper by Assante and Lee [2] that discusses the industrial control system cyber kill chain. The paper defines nine attacker objectives based on the types of effects. The categories capture three types of effects (i.e., loss, denial and manipulation) and the three effects are seen in 10

ACCEPTED MANUSCRIPT

Table 2: SANS Institute attacker objectives.

System Component View Control

Denial

View Control Safety

Manipulation

View Control Sensing Safety

AN US

Loss

CR IP T

Action

M

up to four different areas of a system: (i) view; (ii) control; (iii) safety; and (iv) sensing. Table 2 presents the categories and areas. A modified version of the categories is used by the risk scoring system presented in this paper to describe the potential effects of medical devices.

ED

5. Risk scoring system objectives

CE

PT

Swift action is needed to help identify medical devices that pose great risk to patient safety. The proposed framework is designed to help healthcare organizations identify medical devices that have the potential to harm patients or impact the ability of physicians to arrive at accurate diagnoses, and to conduct basic assessments of the security measures associated with the devices. The three key objectives with regard to the risk scoring system are: (i) ease of use; (ii) low cost; and (iii) easy-to-understand results.

AC

Ease of use Acquisition processes vary greatly in the healthcare sector. Purchases are typically made through group purchasing organizations or by groups within single organizations. In both cases, the individuals who decide which devices are to be purchased often lack the skills needed to identify and rank cyber security risks. In order to maximize the usability of the risk scoring system, it is important to ensure that the inputs needed are easy to understand. This is accomplished by presenting all the inputs in a questionnaire format (i.e., 11

ACCEPTED MANUSCRIPT

yes/no or column of values), similar to the method used by the Common Vulnerability Scoring System.

AN US

CR IP T

Low cost The cost of using the proposed scoring system is relatively low compared with creating an in-house cyber security team. All that is required is an individual with medical knowledge who can accurately answer the outcome assessment questions and an individual who can input the answers to the security questions presented as part of the device assessment. Understandably, healthcare organizations may not know the answers to the device assessment portion, but a device manufacturer should be able to provide the answers via a questionnaire similar to that used by the Mayo Clinic [15].

ED

M

Easy-to-understand results Arguably the most important part of any scoring system is the ease with which a user can interpret the results. To make this process as easy as possible, the proposed scoring system ensures that the results align with the vulnerability severity ratings outlined in the National Vulnerability Database. These ratings are also used to describe the values output by the Common Vulnerability Scoring System. As mentioned above, the Common Vulnerability Scoring System rates vulnerabilities on a 0–10 scale (10 is the worst). The National Vulnerability Database rating system specifies three categories based on the scores [18]: (i) Low: 0 to 3.9; (ii) Medium: 4 to 6.9; and (iii) High: 7 to 10.

PT

6. Risk scoring system

AC

CE

The proposed risk scoring system has two components: (i) a worst-case assessment of the outcome if the medical device were to be compromised; and (ii) an assessment of the security features of the device. These two components provide the inputs to the scoring system. The incorporation of environmental security factors in the scoring system is left for future work. 6.1. Outcome assessment The Food and Drug Administration postmarket guidance recognizes the difficulty of estimating the probability of occurrence of a cyber security exploit. In the absence of adequate probability data, the Food and Drug Administration suggests using a reasonable worst-case estimate or setting the 12

ACCEPTED MANUSCRIPT

Table 3: Possible cyber effects.

Possible Effects

CR IP T

Loss or denial of view Loss or denial of control Manipulation of view Manipulation of control Denial or manipulation of safety

AC

CE

PT

ED

M

AN US

default value of the probability to one [27]. Setting the event occurrence probability to one means that it is inevitable that the event will occur. Following this suggestion, the outcome assessment of the scoring system assumes that the device will be compromised and, thus, the worst-case outcome should be used as the basis for the scoring system. Since the proposed scoring system requires assessments of the outcomes of events that may not have occurred as yet, it is important to identify and describe the events that are possible. The attacker objectives specified by the SANS Institute provide a basis for describing potential events (Table 2). Several similarities are observed when examining the sub-categories in relation to medical devices. Every medical device has a human-machine interface (HMI), which is used to control the device and its safety features to ensure user and patient safety. In most situations, external sensors are directly connected to or co-located with a medical device. For sensor data to be manipulated, physical modification would be required or the data would have to be modified in transit. Identifying this limitation enables the attacker objective that describes actions impacting sensing (i.e., manipulation of sensors) to be eliminated. Furthermore, the manipulation of data in transit is covered by the manipulation of view. To simplify the assessment process, it is important to limit the number of categories with minimal differences. Since the end goal is to assess the potential of a device to impact a patient or diagnosis, the loss or denial of any of the sub-categories often represents a similar end-state. Therefore, the various sub-categories are combined to produce the final list of possible effects shown in Table 3. These five effects are the situations for which the medical device’s outcome assessment will be made. The final piece is to define the possible outcomes that could occur in each 13

ACCEPTED MANUSCRIPT

Table 4: Severity levels.

Description

Negligible

Inconvenience or temporary discomfort to the patient.

Minor

Temporary injury or impairment to the patient not requiring professional medical intervention.

Serious

Injury or impairment to the patient requiring professional medical intervention.

Critical

Permanent impairment or life-threatening injury to the patient.

Catastrophic

Patient death.

AN US

CR IP T

Common Term

Table 5: Device potential diagnosis outcomes.

Description

Negligible

Inconvenience to medical staff with no effect on patient diagnosis.

Minor

Low potential for misdiagnosis with additional redundant data sources available.

ED

Potential for misdiagnosis with additional collaborative data sources available.

PT

Serious Critical

M

Common Term

N/A.

CE

Catastrophic

Misdiagnosis with no additional independent data sources.

AC

of the five attacker objective categories. The Food and Drug Administration postmarket guidance references ANSI/-AAMI/ISO 14971:2007/(R)2010: Medical Devices – Application of Risk Management to Medical Devices [27], which provides five key categories for which the agency provides descriptions (Table 4). While the severity levels describe the potential effects on a patient, there is no mention of the impact a device may have on a diagnosis. A simple solution 14

ACCEPTED MANUSCRIPT

Table 6: Device potential outcomes.

Description

Negligible

Inconvenience or temporary discomfort to the patient, or inconvenience to medical staff with no effect on patient diagnosis.

Minor

Temporary injury or impairment to the patient not requiring professional medical intervention, or low potential for misdiagnosis with additional redundant data sources available.

Serious

Injury or impairment to the patient requiring professional medical intervention, or potential for misdiagnosis with additional collaborative data sources available.

Critical

Permanent impairment or life-threatening injury to the patient, or misdiagnosis with no additional independent data sources.

Catastrophic

Patient death.

M

AN US

CR IP T

Common Term

AC

CE

PT

ED

is to check whether the device can affect a diagnosis and then determine if the device is the sole source of the information, if a secondary device presents redundant data or if the data is corroborated by additional data. By following this logical progression and using the same terminology suggested by the Food and Drug Administration, four potential descriptions are created. Note that the catastrophic outcome is not defined for a diagnosis because the original definition already results in patient death. Table 5 presents the descriptions of the effects on a diagnosis. Having described the effects on a patient and on a diagnosis, the descriptions can be merged into a single set. This new set is used to categorize the worst-case potential outcome associated with a device for each of the attacker objectives. Table 6 shows the final descriptions of the common terms used in device assessments. Note that catastrophic refers to direct patient death and, therefore, does not require a description of the impact on the diagnosis. This was done intentionally because direct loss of life presents a higher risk to a patient than indirect effects that may be prevented through other environmental variables. Table 7 shows a sample assessment decision matrix. The first five rows contain the attacker objectives and each receives a single mark in the column 15

ACCEPTED MANUSCRIPT

Table 7: Sample device assessment decision matrix. Minor

Serious

Critical

Catastrophic

AN US

CR IP T

Attacker Objective Negligible Loss/Denial of View Loss/Denial of Control Manipulation of View Manipulation of Control Denial or Manipulation of Safety Column Total

Table 8: STRIDE model.

Threat

Property

Spoofing

Authentication Integrity

M

Tampering

Non-Repudiation

Information Disclosure

Confidentiality

ED

Repudiation

Availability

Elevation of Privilege

Authorization

PT

Denial of Service

CE

corresponding to the worst potential outcome for each event. The last row presents the column totals. This information is used by the risk scoring system to calculate an appropriate risk score.

AC

6.2. Device assessment The device assessment, which is the second component of the risk scoring system, helps evaluate if the manufacturer has addressed basic cyber security concepts when producing the device. Microsoft has developed the STRIDE model for classifying threats [4]. Table 8 shows the STRIDE model. Each threat is associated with a specific information technology property that helps combat the threat. 16

ACCEPTED MANUSCRIPT

Table 9: STRIDE properties with associated device security questions.

Integrity

Does the system use multi-factor authentication? Does the system enforce secure credential creation, use and maintenance principles?

CR IP T

Authentication

Security Questions

Can the system detect and prevent parameter manipulation? Does the system protect against tampering and reverse engineering? Were secure software design principles followed during development, including third-party software?

AN US

Property

Does the system verify and log all user actions with attribution?

Confidentiality

Does the system follow standard encryption practices to secure connections?

Availability

Was the system built and tested for high availability (e.g., fuzz testing and load testing)?

Authorization

Does the system support the management of all users and privileges?

ED

M

Non-Repudiation

PT

Microsoft also specifies standard mitigation techniques. Using these techniques as a foundation, questions were created that target each of the six properties associated with the STRIDE model. Table 9 presents the properties and the associated questions.

AC

CE

6.3. Scoring system The Food and Drug Administration currently recommends that the Common Vulnerability Scoring System be used to categorize vulnerabilities in medical devices. The Common Vulnerability Scoring System uses a 0–10 scale whose scores are collected into various severity levels specified in the National Vulnerability Database [27]. Creating a scoring system that ties to this existing scale ensures that the users of both systems can recognize the risk relationships associated with devices. In addition to using the 0– 10 scale, Common Vulnerability Scoring System (Version 3.0) also generates three separate scores. Each score considers additional factors in producing 17

ACCEPTED MANUSCRIPT

Table 10: Attacker objective scores based on the numbers of critical or catastrophic outcomes.

Negligible

Minor

Serious

Critical

Catastrophic

0

0

0.3

1

N/A

N/A

1

0

0.25

0.4

3.5

6

2

0

0.2

0.3

3

3.5

3

0

0.1

0.2

2.1

2.8

4

0

0.05

0.1

1.8

2.3

5

N/A

N/A

N/A

1.5

2

AN US

CR IP T

Number of Critical/ Catastrophic Outcomes

AC

CE

PT

ED

M

a progressively more accurate and useful score [8]. Following this strategy, the outcome assessment is used to generate a basic score that describes the potential of the device to impact patient health and the ability of a physician to provide an accurate diagnosis. Since the National Vulnerability Database severity levels have three key areas, the first step was to define what meaning, if any, should be tied to these boundaries. Because minimizing patient death is the top concern, devices with possible outcomes that contain values scored as critical or catastrophic should all end up in the highest of the three ranges (i.e., 7–10). It was also determined that a 2:1 ratio would be reasonable for each level, meaning that two critical ratings should represent a similar value as one catastrophic rating, two serious ratings should be scored similarly as one critical rating, and so on. Having restricted the catastrophic outcomes to the upper score range and established the relationships between values, it was reasonable to construct the scoring system around three key ideas: (i) all devices with at least one catastrophic outcome should have a base score greater than or equal to 7; (ii) a ratio of 2:1 should be maintained between each category (e.g., a device with two critical values should be roughly equivalent to a device with one catastrophic value); and (iii) no device can receive a score higher than 10. 18

AN US

CR IP T

ACCEPTED MANUSCRIPT

M

Figure 1: Ranges of potential values based on the numbers of critical or catastrophic outcomes.

AC

CE

PT

ED

If the values of each category were to be set as constants, the range of values would be difficult to fit on a 0–10 scale without modification. For example, if the catastrophic outcome was set to 7, then, in order to ensure that the minimum threshold is met, a device with two or more catastrophic values would already exceed the maximum value of 10. To solve this problem and meet the three objectives, a scaling value system based on the numbers of critical or catastrophic outcomes was developed. The scoring system examines the inputs and determines their individual values based on the numbers of values contained in the critical or catastrophic categories. Table 10 contains the individual values of each category based on the total number of potential outcomes rated as critical or catastrophic. Figure 1 shows the ranges of potential values based on the numbers of critical or catastrophic outcomes. Table 11 identifies the upper and lower limits of each range depending on the presence or absence of catastrophic outcomes. The base score is the summation of the determined worst-case values over all the categories: 19

ACCEPTED MANUSCRIPT

Table 11: Key potential values based on the numbers of critical or catastrophic outcomes.

Lowest Value without a Catastrophic Outcome

Lowest Value with a Catastrophic Outcome

Highest Value without a Catastrophic Outcome

Highest Possible Value

0

0

N/A

5

5

1

3.5

6

5.1

7.6

2

6

6.5

6.9

7.9

3

6.3

7

6.7

8.8

4

7.2

7.7

7.3

9.3

5

7.5

8

7.5

10

AN US

CR IP T

Number of Critical/ Catastrophic Outcomes

M

Base Score = Σ Attacker Objective Score

(1)

AC

CE

PT

ED

The base score established by the outcome assessment is augmented by the results of the device assessment in order to obtain the device risk score. As mentioned above, each question is associated with a specific property that is required to be assessed. The properties potentially impact multiple attacker objectives used in the outcome assessment, but may have no impact on other objectives. The association matrix in Table 12 shows how various security principles are tied to the attacker objectives. Each attacker objective that is marked as being impacted by a security principle can be adjusted when the associated security question is answered. The association matrix adds some weight to the categories, but their individual values are represented consistently. In other words, implementing security measures that address all the questions related to a specific property affect the score equally given that their impact in the association matrix is identical. Some properties are associated with multiple questions. In these cases, each question is weighted equally and the proportional value impacts the score (e.g., a device meeting two of the three security questions related to integrity receives two-thirds credit instead of full credit for meeting all three 20

ACCEPTED MANUSCRIPT

Table 12: Property association matrix. Authenticity

Integrity

Non-Repudiation

Confidentiality

Availability

Authorization

Loss/Denial of View

Yes

Yes

No

No

Yes

No

Loss/Denial of Control

Yes

Yes

No

Manipulation of View

Yes

Yes

Yes

Manipulation of Control

Yes

Yes

Yes

Denial or Manipulation of Safety

Yes

Yes

Yes

CR IP T

Attacker Objective

Yes

No

Yes

No

Yes

Yes

No

Yes

Yes

No

Yes

AN US

No

questions). The risk score for a device is computed as:

ED

M

F inal Attacker Objective Score = Original Attacker Objective Score  Σ Device Assessment Credit × 1− 20 (2) Device Risk Score = Σ F inal Attacker Objective Score

(3)

CE

PT

Note that the original attacker objective score is the sum of the values associated with each of the individual attacker objectives and represents the old base score. The device assessment credit is divided by 20 to provide reasonable impact scaling. Note that the Common Vulnerability Scoring System also uses constant values in its equations [8].

AC

7. Test scenarios The four scenarios described in this section involve real medical devices, three of which have known vulnerabilities. Details of the exploits are omitted for reasons of sensitivity, but their potential to cause harm to patients is public knowledge. As in the case of the Common Vulnerability Scoring System, each score is rounded to the nearest tenth.

21

ACCEPTED MANUSCRIPT

Table 13: Medication delivery device outcome assessment. Attacker Objective Negligible Loss/Denial of View Loss/Denial of Control Manipulation of View Manipulation of Control Denial or Manipulation of Safety Column Total

Minor

Serious

Critical X

Catastrophic

CR IP T

X X X X

2+2+2=6

AN US

1.5 + 1.5 = 3

PT

ED

M

7.1. Digital thermometer device This scenario involves a device that is used to determine a patient’s external body temperature. The device displays the temperature reading on an LCD screen and transmits the data via a Bluetooth connection to a paired device. Since the device cannot directly impact a patient during normal use, the potential effects on the patient fall in the negligible category and, in the worst case, a physician might have to confirm an inaccurate reading with a second device or may simply touch the patient’s forehead to validate the reading. These effects dictate that the negligible category should be used for all five attacker objectives. This results in an outcome assessment score of 0 for the device. Since the first stage of the assessment score is 0, the second stage also results in a score of 0 regardless of the implemented security measures. These scores imply that the digital thermometer is an innocuous device that has no potential to directly harm a patient or produce a misdiagnosis.

AC

CE

7.2. Medication delivery device This scenario involves a device that controls the dose of medication delivered to a patient. The device has networking capabilities and at least one remote connection. Since this is an assessment of the worst-case potential outcome, the scenario assumes that the medication being delivered is either lifesaving or has the potential to be lethal in the event of an improper dosage. Another assumption is that the delivery schedule must be maintained or a critical level event could occur. Table 13 shows the outcome assessment with five critical or catastrophic values. Using the information provided by the outcome assessment, the value 22

ACCEPTED MANUSCRIPT

Table 14: Medication delivery device security questionnaire.

Security Questions

Integrity

Does the system use multi-factor authentication? Does the system enforce secure credential creation, use and maintenance principles?

No No

Can the system detect and prevent parameter manipulation? Does the system protect against tampering and reverse engineering? Were secure software design principles followed during the development of all the software, including third-party software?

No

CR IP T

Authentication

Yes/No

AN US

Property

Yes Yes

Does the system verify and log all user actions with attribution?

Yes

Confidentiality

Does the system follow standard encryption practices to secure all connections?

Yes

Availability

Was the system built and tested for high availability (e.g., fuzz testing and load testing)?

Yes

Authorization

Does the system support the management of all users and privileges?

Yes

ED

M

Non-Repudiation

AC

CE

PT

for each attacker objective can be obtained from Table 10. Table 13 also presents the individual attacker objective values as the sums of the individual columns. Inserting the appropriate values into Equation (1) produces the outcome assessment score: Base Score = Σ Attacker Objective Score = 1.5 + 1.5 + 2 + 2 + 2 = 9

The computed value of 9 is one of the highest possible scores. The high score implies that the medical device may need additional testing to ensure that the security measures have been properly implemented. The second half of the assessment involves an analysis of the security 23

ACCEPTED MANUSCRIPT

Table 15: Medication delivery device value adjustment matrix. Authenticity

Integrity

Non-Repudiation

Confidentiality

Availability

Authorization

Loss/Denial of View

0

2/3

N/A

N/A

1

N/A

Loss/Denial of Control

0

2/3

N/A

Manipulation of View

0

2/3

1

Manipulation of Control

0

2/3

1

Denial or Manipulation of Safety

0

2/3

1

CR IP T

Attacker Objective

1

N/A

1

N/A

1

1

N/A

1

1

N/A

1

AN US

N/A

AC

CE

PT

ED

M

features using the questionnaire. The contents of Table 14 are used in the device assessment. Based on the responses to the device assessment questions, the property association (value adjustment) matrix in Table 15 is filled in with the assessed values. These values are the individual device assessment credits that are used in Equation (2). Table 16 shows the original and final component scores as well as the calculations. The resulting risk assessment score for the medication delivery device is 7.6. The minimum score achievable based on the outcome assessment is 7.1; thus, the device covers several, but not all, of the security properties. The Hospira infusion pump considered in this scenario was found to have flaws that could enable an unauthorized user to control the device and change the dose administered to a patient [26]. This test scenario is similar to what might have been uncovered a risk assessment process. The scores calculated during each step of the process can raise awareness of the potential of the device to harm patients and could provide the impetus for further testing. 7.3. Implantable device This scenario involves a device that is surgically implanted in a patient to regulate the patient’s heart. After it is implanted, the device is controlled via a wireless connection. If the device becomes unresponsive, a critical level event could occur (e.g., the patient undergoes surgery to replace the device). 24

ACCEPTED MANUSCRIPT

Table 16: Medication delivery device attacker objective risk score components.

Original Component Score

Equation

Final Component Score

Loss/Denial of View

1.5

1.5 × (1 − (0+2/3+0+0+1+0)/20

1.4

Loss/Denial of Control

1.5

1.5 × (1 − (0+2/3+0+0+1+0)/20

1.4

Manipulation of View

2

2 × (1 − (0+2/3+1+1+0+1)/20

1.6

Manipulation of Control

2

2 × (1 − (0+2/3+1+1+0+1)/20

1.6

Denial or Manipulation of Safety

2

2 × (1 − (0+2/3+1+1+0+1)/20

1.6

M

AN US

CR IP T

Attacker Objective

Table 17: Implantable device outcome assessment. Minor

Serious X

ED

Attacker Objective Negligible Loss/Denial of View Loss/Denial of Control Manipulation of View Manipulation of Control Denial or Manipulation of Safety Column Total

Critical

Catastrophic

X X

PT

X X

CE

0.1

1.8

2.3+2.3+2.3=6.9

AC

If the controlling application fails to display device information, a serious event could occur (e.g., misdiagnosis of the current health condition because the device is the sole source of data). A manipulation of the device outside the set parameters or a failure of the device safety controls could result in a catastrophic event (e.g., patient dies due to device hyperactivity). Table 17 presents the outcome assessment for the implantable device. Since there are four critical or catastrophic values, Table 10 can be used 25

ACCEPTED MANUSCRIPT

Table 18: Implantable device security questionnaire.

Property

Security Questions

Yes/No No No

Can the system detect and prevent parameter manipulation? Does the system protect against tampering and reverse engineering? Were secure software design principles followed during the development of all the software, including third-party software?

No

Non-Repudiation

Does the system verify and log all user actions with attribution?

No

Confidentiality

Does the system follow standard encryption practices to secure all connections?

No

Availability

Was the system built and tested for high availability (e.g., fuzz testing and load testing)?

No

Authorization

Does the system support the management of all users and privileges?

No

AN US

No No

ED

M

Integrity

CR IP T

Does the system use multi-factor authentication? Does the system enforce secure credential creation, use and maintenance principles?

Authentication

PT

to identify the individual values. Based on these values, a potential impact score is calculated using Equation (1):

AC

CE

Base Score = Σ Attacker Objective Score = 0.1 + 1.8 + 2.3 + 2.3 + 2.3 = 8.8

This score of 8.8 falls in the high risk category, which implies that the device may need additional validation of its security measures. The second half of the assessment involves the analysis of the device security features using the questionnaire in Table 18. The questionnaire results are used to populate the property association matrix in Table 19. Table 20 shows the original and final component values and the use of 26

ACCEPTED MANUSCRIPT

Table 19: Implantable device value adjustment matrix. Authenticity

Integrity

Non-Repudiation

Confidentiality

Availability

Authorization

Loss/Denial of View

0

0

N/A

N/A

0

N/A

Loss/Denial of Control

0

0

N/A

Manipulation of View

0

0

0

Manipulation of Control

0

0

0

Denial or Manipulation of Safety

0

0

0

CR IP T

Attacker Objective

0

N/A

0

N/A

0

0

N/A

0

0

N/A

0

AN US

N/A

Attacker Objective

Original Component Score

Final Component Score

Loss/Denial of View

0.1

0.1 × (1 − (0+0+0+0+0+0)/20

0.1

Loss/Denial of Control

1.8

1.8 × (1 − (0+0+0+0+0+0)/20

1.8

2.3

2.3 × (1 − (0+0+0+0+0+0)/20

2.3

ED

Manipulation of Control

2.3

2.3 × (1 − (0+0+0+0+0+0)/20

2.3

CE

Manipulation of View

M

Equation

PT

Table 20: Implantable device attacker objective risk score components.

2.3

2.3 × (1 − (0+0+0+0+0+0)/20

2.3

AC

Denial or Manipulation of Safety

Equation (2). The risk score of 8.8 obtained by adding the final component values implies that the manufacturer did not take security into account when developing the device. Indeed, the high risk score is a clear warning to potential users that the implantable device is exploitable. The implantable device scenario is based on the findings of Halperin et 27

ACCEPTED MANUSCRIPT

Table 21: Electrocardiogram device outcome assessment for intended use. Negligible X

Minor

Serious

Critical

Catastrophic

X X X

0+0+0=0

1+1=2

CR IP T

X

AN US

Attacker Objective Loss/Denial of View Loss/Denial of Control Manipulation of View Manipulation of Control Denial or Manipulation of Safety Column Total

al. [10] and Jack [12] related to implantable cardioverter-defibrillator devices. These devices are equipped with vulnerable RF transmitters that enable physicians to interact with the devices during patient care and treatment (without having to operate on patients). Halperin et al. and Jack have demonstrated that attackers could reprogram the devices to shock patients.

AC

CE

PT

ED

M

7.4. Electrocardiogram device This scenario involves an electrocardiogram device that connects via a Bluetooth connection to a laptop (or smart device) that runs a patient monitoring application. While the device monitors vital processes in the human body, it is intended for use in situations where the patient is not in immediate danger (e.g., diagnosis). Thus, the greatest impact on the patient is the manipulation of the physician’s diagnosis by presenting false readings. In such a situation, there is often another device that confirms or contradicts the data presented by the electrocardiogram device. This limits the worstcase impact of any manipulation of view or control to the serious category. If alternate methods are available to verify the readings, the worst-case impact is reduced to the minor category. Since the device cannot impact the patient physically, a denial or manipulation of safety has a negligible outcome and a loss or denial of view or control would also be negligible because the device is only used to take readings in non-life-threatening situations. Given the assessments of the worst-case potential outcomes, Table 9 is used to identify the associated values for the case where there are no critical or catastrophic ratings. Table 21 shows the outcome assessment for the electrocardiogram device. Using these values in Equation (1) yields the base score: 28

ACCEPTED MANUSCRIPT

Table 22: Electrocardiogram device security questionnaire.

Security Questions

Integrity

Non-Repudiation

Does the system use multi-factor authentication? Does the system enforce secure credential creation, use and maintenance principles?

No No

Can the system detect and prevent parameter manipulation? Does the system protect against tampering and reverse engineering? Were secure software design principles followed during the development of all the software, including third-party software?

No

CR IP T

Authentication

Yes/No

AN US

Property

Yes No

Does the system verify and log all user actions with attribution? Does the system follow standard encryption practices to secure all connections?

No

Availability

Was the system built and tested for high availability (e.g., fuzz testing and load testing)?

No

Authorization

Does the system support the management of all users and privileges?

No

No

ED

M

Confidentiality

CE

PT

Base Score = Σ Attacker Objective Score = 0+0+1+1+0 = 2

AC

The base score of 2 implies that the device that has little or no ability to directly harm a patient and, with careful use, the device would rarely impact a diagnosis. Table 22 shows the security questionnaire assessment for the electrocardiogram device. Table 23 shows the resulting value adjustment matrix. Entering the values from the value adjustment matrix in Equation (2) yields the objective risk score components shown in Table 24. Summing the values yields a risk score of 2, which implies that the device lacks implemented security controls. Note that, without rounding the individual 29

ACCEPTED MANUSCRIPT

Table 23: Electrocardiogram device value adjustment matrix. Authenticity

Integrity

Non-Repudiation

Confidentiality

Availability

Authorization

Loss/Denial of View

0

1/3

N/A

N/A

0

N/A

Loss/Denial of Control

0

1/3

N/A

Manipulation of View

0

1/3

0

Manipulation of Control

0

1/3

0

Denial or Manipulation of Safety

0

1/3

0

CR IP T

Attacker Objective

0

N/A

0

N/A

0

0

N/A

0

0

N/A

0

AN US

N/A

Table 24: Electrocardiogram attacker objective risk score components for intended use.

Original Component Score

Loss/Denial of View

0

Equation

Final Component Score

0 × (1 − (0+1/3+0+0+0+0)/20

0

ED

M

Attacker Objective

0

0 × (1 − (0+1/3+0+0+0+0)/20

0

1

1 × (1 − (0+1/3+0+0+0+0)/20

1

Manipulation of Control

1

1 × (1 − (0+1/3+0+0+0+0)/20

1

Denial or Manipulation of Safety

0

0 × (1 − (0+1/3+0+0+0+0)/20

0

Loss/Denial of Control

AC

CE

PT

Manipulation of View

attacker objective scores, the risk score would be 1.9 instead of 2. Since the electrocardiogram device is intended for use in non-emergency situations, the lack of security does not pose a risk to patient health. However, if the device 30

ACCEPTED MANUSCRIPT

Table 25: Electrocardiogram device outcome assessment for unintended use. Minor

Serious

Critical

Catastrophic X

CR IP T

Attacker Objective Negligible Loss/Denial of View Loss/Denial of Control Manipulation of View Manipulation of Control Denial or X Manipulation of Safety Column Total 0

X X X

AN US

2.3+2.3+2.3+2.3=9.2

M

were to be used outside the defined parameters (e.g., during surgery or in an emergency situation), the worst-case outcomes would be drastically different. Table 25 shows the assessment if the device were to be used in an emergeny situation (e.g., in an ambulance). Entering the new values in Equation (1) yields the base score:

ED

Base Score = Σ Attacker Objective Score = 2.3 + 2.3 + 2.3 + 2.3 + 0 = 9.2

AC

CE

PT

The new base score of 9.2 is dramatically different from the earlier assessment due to the patient’s condition and the absence of devices that could confirm or contradict the readings. Since the device security assessment remains the same, the same adjustment matrix can be used; Table 26 shows the calculations. The lack of security results in a risk score of 9.2. Note that, without the rounding of the individual attacker objective scores, the risk score would be 9 instead of 9.2. This is an extremely high risk score and indicates that alternative devices should be considered. The electrocardiogram scenario is based on the Nasiff CardioCard, which was investigated as part of this research effort. During the testing process, it was discovered that the Nasiff CardioCard incorporates a default static pairing key that could not be managed. This could enable a Bluetooth 31

ACCEPTED MANUSCRIPT

Table 26: Electrocardiogram device attacker objective risk score components for unintended use.

Original Component Score

Equation

Final Component Score

Loss/Denial of View

2.3

2.3 × (1 − (0+1/3+0+0+0+0)/20

2.3

Loss/Denial of Control

2.3

2.3 × (1 − (0+1/3+0+0+0+0)/20

2.3

Manipulation of View

2.3

2.3 × (1 − (0+1/3+0+0+0+0)/20

.2.3

Manipulation of Control

2.3

2.3 × (1 − (0+1/3+0+0+0+0)/20

2.3

Denial or Manipulation of Safety

0

0 × (1 − (0+1/3+0+0+0+0)/20

0

M

AN US

CR IP T

Attacker Objective

PT

ED

device within range to execute a denial-of-service attack on any active Nasiff CardioCard. Due to the static nature of the device and the lack of security, the Nasiff CardioCard is also vulnerable to spoofing and man-in-the-middle attacks that could manipulate vital readings.

AC

CE

7.5. Analysis of results and future work The four scenarios presented in this paper cover four medical devices in the market, three of which have known vulnerabilities. Applying the proposed risk scoring system to each device yields a score that expresses the potential of the device to harm a patient. The scoring system identifies devices with potential outcomes in the catastrophic categories, except in scenarios where all three of the following criteria are met: • Two or fewer attacker objectives receive critical or catastrophic ratings. • Only a single attacker objective receives a catastrophic rating. 32

ACCEPTED MANUSCRIPT

• At least one of the remaining attacker objectives is deemed to be negligible.

PT

8. Conclusions

ED

M

AN US

CR IP T

When these three criteria are met, the resulting score is at least 6, which is still relatively high in the overall risk scale. Attempts were made to raise the lower values to the desired range, but the artificial inflation yielded scores that were not representative of their relative severity (i.e., devices with one catastrophic outcome could score higher than devices with two catastrophic outcomes). To keep the relative score balance, it was deemed acceptable to have outliers with a single catastrophic outcome to fall below the critical category score threshold of 7. The scoring system presented in this paper provides a solution for risk assessment, one of the key components of the risk management process. The scoring system, which uses a scale that is widely accepted, helps proactively identify medical devices that manifest high levels of cyber security risk. A simple interface enhances the usability of the scoring system and limits the amount of user training needed to apply the scoring system. Little or no cost is associated with implementing the scoring system; this makes it attractive and accessible to organizations with resource constraints. Future work will focus on presenting the risk scoring system to physicians for feedback and collecting additional scoring data. Other work will focus on considering environmental factors (e.g., network security features) in the risk scoring system. Another enhancement is to expand the assessment to account for the presence of other devices in the network.

AC

CE

Over the past several years, many collaborative attempts have been made to identify ways to enhance cyber security in the healthcare sector. The collaborations have produced risk management frameworks and processes that are designed to protect patients and healthcare sector entities. The risk management practices are extensive and the implementation costs are high. As a result, organizations with limited resources have been slow to adopt cyber security risk management processes. The proposed risk scoring system is relatively easy to use, has a low operational cost and provides intuitively appealing results. It yields consistent scores for medical devices based on their potential to impact patient health

33

ACCEPTED MANUSCRIPT

CR IP T

and wellbeing. The scoring system is designed to enable medical device vendors and healthcare providers to effectively evaluate the cyber risk of medical devices. Additionally, it could help insurance carriers and legislators understand the cyber risk of medical devices as they work on crafting incentives for implementing cyber security solutions in the healthcare sector. Note that the views expressed in this paper are those of the authors and do not reflect the official policy or position of the U.S. Air Force, U.S. Army, U.S. Department of Defense or U.S. Government. Acknowledgement

AN US

This research was partially supported by the U.S. Department of Homeland Security Industrial Control Systems Cyber Emergency Response Team (ICS-CERT).

References

ED

M

IMPORTANT NOTE TO IJCIP TYPESETTERS: I have checked and edited the references in this paper myself. Please DO NOT MODIFY the references – except to add hyperlinks. Please contact the Journal Manager Ms. Ramya Vasudevan if you have any questions. Professor Sujeet Shenoi, Editor-in-Chief, IJCIP

PT

[1] L. Altman, Arne H. W. Larsson, 86; had first internal pacemaker, The New York Times, January 18, 2002.

CE

[2] M. Assante and R. Lee, The Industrial Control System Cyber Kill Chain, InfoSec Reading Room, SANS Institute, Bethesda, Maryland (www.sans.org/reading-room/whitepapers/ICS/ industrial-control-system-cyber-kill-chain-36297), 2015.

AC

[3] Association for the Advancement of Medical Instrumentation, Mayo Clinic emphasizes security with device vendors, AAMI News, April 2016.

[4] Department of Electrical Engineering and Computer Science, University of California, Berkeley, Introduction to Microsoft Software Development Lifecycle (SDL) Threat Modeling, Berkeley, California (people.eecs.berkeley.edu/~daw/teaching/cs261-f12/hws/ Introduction_to_Threat_Modeling.pdf), 2015. 34

ACCEPTED MANUSCRIPT

[5] Dimensional Research, Trends in Security Framework Adoption: A Survey of IT and Security Professionals, Sunnyvale, California (static. tenable.com/marketing/tenable-csf-report.pdf), 2016.

CR IP T

[6] Forum of Incident Response and Security Teams, Common Vulnerability Scoring System V3: Development Update, Morrisville, North Carolina (www.first.org/cvss), 2015. [7] Forum of Incident Response and Security Teams, Common Vulnerability Scoring System Version 3.0: Calculator, Morrisville, North Carolina (www.first.org/cvss/calculator/3.0), 2015.

AN US

[8] Forum of Incident Response and Security Teams, Common Vulnerability Scoring System Version 3.0: Specification Document, Morrisville, North Carolina (www.first.org/cvss/specification-document), 2015.

M

[9] P. Fowler, FDA issues unprecedented alert over medical device cyber security risk, Snell and Wilmer, Phoenix, Arizona (www.swlaw.com/blog/product-liability-update/2015/08/17/ fda-issues-unprecedented-alert-over-medical-device-cyber-security-risk), August 17, 2015.

PT

ED

[10] D. Halperin, T. Heydt-Benjamin, B. Ransford, S. Clark, B. Defend, W. Morgan, K. Fu, T. Kohno and W. Maisel, Pacemakers and implantable cardiac defibrillators: Software radio attacks and zero-power defenses, Proceedings of the IEEE Symposium on Security and Privacy, pp. 129– 142, 2008.

CE

[11] Industrial Control Systems Cyber Emergency Response Team (ICSCERT), Advisory (ICSA-15-174-01) Hospira Symbiq Infusion System Vulnerability, Idaho Falls, Idaho (ics-cert.us-cert.gov/ advisories/ICSA-15-174-01), 2015.

AC

[12] B. Jack, “Broken hearts:” How plausible was the Homeland pacemaker hack? IOActive, Seattle, Washington (blog.ioactive.com/2013/02/ broken-hearts-how-plausible-was.html), February 25, 2013.

[13] Joint Commission on Accreditation of Healthcare Organizations, Safely Implementing Health Information and Converging Technologies, Sentinel Event Alert, Issue 42, Oakbrook Terrace, Illi35

ACCEPTED MANUSCRIPT

nois (www.jointcommission.org/assets/1/18/SEA_42.PDF), December 11, 2008.

CR IP T

[14] S. Lohr, The “miracle” of digital health records, 50 years ago, The New York Times, February 17, 2012.

[15] Mayo Clinic, Medical Equipment Procurement Questionnaire, Information Technology, Rochester, Minnesota (www.mayo.edu/pmts/ mc7200-mc7299/mc7231.pdf), 2016.

AN US

[16] J. McNeill and R. Weitz, How to Fix Critical Infrastructure Protection Plans: A Guide for Congress, No. 2404, The Heritage Foundation, Washington, DC (www.heritage.org/research/reports/2010/04/ how-to-fix-homeland-security-critical-infrastructure-protection-plans-a-guide-f 2010. [17] National Institute of Standards and Technology, Framework for Improving Critical Infrastructure Cybersecurity, Version 1.0, Gaithersburg, Maryland, 2014.

ED

M

[18] National Institute of Standards and Technology, CVSS v3 Information, NVD Common Vulnerability Scoring System Support v2, Gaithersburg, Maryland (nvd.nist.gov/cvss.cfm), 2017. [19] B. Obama, Presidential Policy Directive – Critical Infrastructure Security and Resilience, PPD-21, The White House, Washington, DC, 2013.

PT

[20] M. Reel and J. Robertson, It’s way too easy to hack the hospital, Bloomberg Businessweek, November 2015.

CE

[21] D. Storm, MEDJACK: Hackers hijacking medical devices to create backdoors in hospital networks, Computerworld, June 8, 2015.

AC

[22] L. Thomson, Health care data breaches and information security: Addressing threats and risks to patient data, in Health Care IT: The Essential Lawyer’s Guide to Health Care Information Technology and the Law, A. Peabody (Ed.), ABA Publishing, Chicago, Illinois, pp. 253–267, 2013.

[23] U.S. Department of Homeland Security, Information Sharing and Analysis Organizations (ISAOs), Washington, DC (www.dhs.gov/isao), 2017. 36

ACCEPTED MANUSCRIPT

CR IP T

[24] U.S. Food and Drug Administration, Guidance for Industry – Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software, Silver Spring, Maryland (www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/ GuidanceDocuments/ucm077812.htm), 2005.

[25] U.S. Food and Drug Administration, Content of Premarket Submissions for Management of Cybersecurity in Medical Devices: Guidance for Industry and Food and Drug Administration Staff, Silver Spring, Maryland (www.fda.gov/ucm/groups/fdagov-public/ @fdagov-meddev-gen/documents/document/ucm356190.pdf), 2014.

AN US

[26] U.S. Food and Drug Administration, Cybersecurity Vulnerabilities of Hospira Symbiq Infusion System: FDA Safety Communication, Silver Spring, Maryland (www.fda.gov/MedicalDevices/Safety/ AlertsandNotices/ucm456815.htm), 2015.

M

[27] U.S. Food and Drug Administration, Postmarket Management of Cybersecurity in Medical Devices: Guidance for Industry and Food and Drug Administration Staff, Silver Spring, Maryland (www.fda.gov/ucm/groups/fdagov-public/@fdagov-meddev-gen/ documents/document/ucm482022.pdf), 2016.

PT

ED

[28] U.S. Food and Drug Administration, Medical Device Recalls, Silver Spring, Maryland (www.accessdata.fda.gov/scripts/cdrh/cfdocs/ cfRES/res.cfm), 2017.

CE

[29] U.S. Food and Drug Administration, Search for FDA Guidance Documents, Silver Spring, Maryland (www.fda.gov/ RegulatoryInformation/Guidances/default.htm), 2017.

AC

[30] U.S. Food and Drug Administration, What We Do, Silver Spring, Maryland (www.fda.gov/AboutFDA/WhatWeDo/default.htm), 2017. [31] U.S. Government, Code of Federal Regulations, Title 21 (Food and Drug), 800 Series, Washington, DC, 2016. [32] E. Weise, Johnson and Johnson warns of insulin pump hack risk, USA Today, October 4, 2016.

37

ACCEPTED MANUSCRIPT

AC

CE

PT

ED

M

AN US

CR IP T

[33] Wikipedia, Electronic Health Record (en.wikipedia.org/wiki/ Electronic_health_record), 2016.

38