Cybersecurity Whitepaper

IEEE 11073 PHD Cybersecurity Whitepaper

Author: Christoph Fischer Date: 10-Nov-2015 Status: Draft 1 Revision 1 Table of contents [1] Purpose Up to date the IEEE 11073™ Personal Health Devices (PHD) standard family does not provide any method to ensure security of data exchange. It assumes that data exchange is secured by other means, for example, a secure transport channel. Currently there is an ongoing discussion about adding command & control (C&C) functionalities to IEEE Std 11073-20601 Optimized Exchange Protocol (OXP). Latest with adding this functionality to device specialization which are used by medical devices or have security concerns also the topic Cybersecurity must be considered. Unfortunately there is no IEEE Std available applicable for IEEE 11073™ PHD the institute, “IEEE Standards on Cybersecurity“, March 2015, Vol. 39, Issue 1, p. 13 (www). In addition, various groups have started or will start activities around Cybersecurity IEEE Cybersecurity, “Building Code for Medical Device Software Security” (www)NCCoE, “Use Case: WIRELESS MEDICAL INFUSION PUMPS”, Draft, December 2014 (www).

The purpose of this whitepaper is to prepare common ground and to guide the discussion about Cybersecurity in the IEEE 11073™ PHD standard family. Based on the FDA definition of Cybersecurity FDA Guidance, “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices”, October 2014 (www) is in the context of IEEE 11073™ PHD with Cybersecurity meant the process and the capability of preventing unauthorized access, modification, misuse or denial of use, or the unauthorized use of information that is stored, accessed, or transferred between PHD. The aim is to enable manufacturers using IEEE 11073™ PHD standard family to develop a set of cybersecurity controls to assure medical device security and maintain medical device functionality in order to fulfill regulations FDA Guidance, “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices”, October 2014 (www).

This document is inspired by the Use Case Wireless Medical Infusion Pump from NCCoE NCCoE, “Use Case Wireless Medical Infusion Pump”, December 2015, Draft (www).

1.1 Mission In order to address the need for security is the mission of the IEEE 11073™ PHD working group to create a “toolbox” to develop personal health devices with a secure data communication interface appropriate for the specialization.

1.2 Scope In scope of this mission is security for IEEE 11073™ PHD interfaces including Authentication, Authorization, Integrity, Confidentiality, Privacy, Availability, Accessibility and TraceabilityAudit trail. Out of scope is physical security (i.e. tampering the PHD).

[2] Terms 2.1 Abbreviations In the context of IEEE 11073™ PHD the following abbreviations are used:

FDA Food and Drug Administration OXP Optimized Exchange Protocol IEEE Std 11073-20601-2014 Optimized Exchange Protocol PHD Personal Health Devices IEEE Std 11073-20601-2014 Optimized Exchange Protocol PHI Protected Health Information PHR Personal Health Records

2.2 Definitions In the context of IEEE 11073™ PHD the following definitions are used:

Accessibility Extent to which products, systems, services, environments and facilities can be used by people from populations with the widest range of user needs for the widest range of goals in the widest range of contexts of use [ISO 9241-20:2007 and ISO 9241- 171:2007]. Asset Is anything that has value to an individual or an organization ISO/ICE 27032:2012(E) Information technology — Security techniques — Guidelines for cybersecurity. Authentication Is the act of verifying the identity of a user, process, or device as a prerequisite to allowing access to the device, its data, information, or systems FDA Guidance, “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices”, October 2014 (www). Authorization Is the right or a permission that is granted to access a device resource FDA Guidance, “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices”, October 2014 (www). Availability Data, information, and information systems are accessible and usable on a timely basis in the expected manner (i.e. the assurance that information will be available when needed) FDA Guidance, “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices”, October 2014 (www). Confidentiality The property of information that is not made available or disclosed to unauthorized individuals, entities, or processes IEEE Standards Definition Database (www).

Data, information, or system structures are accessible only to authorized persons and entities and are processed at authorized times and in the authorized manner, thereby helping ensure data and system security. Confidentiality provides the assurance that no unauthorized users (i.e. only trusted users) have access to the data, information, or system structures FDA Guidance, “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices”, October 2014 (www).

The property of information that is not made available or disclosed to unauthorized individuals, entities, or processes IEEE Standards Definition Database (www). Harm Harm refers to the impact of a threat on device functionality, system data integrity and availability, and end-user/patient safety and satisfaction. Integrity Means that data, information and software are accurate and complete and have not been improperly modified FDA Guidance, “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices”, October 2014 (www).

A property whereby data has not been altered in an unauthorized manner since it was created, transmitted or stored IEEE Standards Definition Database (www). Privacy The service used to prevent the content of messages from being read by other than the intended recipients IEEE Standards Definition Database (www).

Is to assure that individuals’ health information is properly protected while allowing the flow of health information [HIPAA]

An aspect of system security (preventing undesired system use) that deals with providing access to the parties to which the information belongs and to parties that have explicitly been allowed access to certain information (also known as Confidentiality) [Continua] TraceabilityAudit trail The ability to know the source which has accessed your data. [3] IEEE 11073 PHD standard family Figure 1 shows categories and typical devices supporting the personal health space. Agents (e.g., blood pressure monitors, weighing scales, and pedometers) collect information about a person (or persons) and transfer the information to a manager (e.g., cell phone, health appliance, or personal computer) for collection, display, and possible later transmission. The manager may also forward the data to remote support services for further analysis. The information is available from a range of domains including disease management, health and fitness, or aging independently applications.

The communication path between agent and manager is assumed to be a logical point-to- point connection.

Generally, an agent communicates with a single manager at any point in time. A manager may communicate with multiple agents simultaneously using separate point-to-point connections. The overlay shows the focus area of the IEEE 11073™ Personal Health Devices Working Group. The primary concentration is the interface and data exchange between the agents and manager. However, this interface cannot be created in isolation by ignoring the remainder of the solution space. Remaining cognizant of the entire system helps to move data reasonably from the agents all the way to the remote support services when necessary.

Note: Give typical example of physical transport layers.

Figure 1: IEEE 11073 focus area

[4] Actors Personal health devices could have up to seventeen actor roles from seven categories, which an individual may have who interact with one or more of the PHD. Actor category number six is a potentially bad actor whereas seven is a bad actor. 1. Manufacturer: In their domain trained individuals or group working for an enterprise (e.g. legally responsible distributing company, supplier) which handle the complete or participating in a part of the products’ life-cycle from idea over development over maintenance to end of life. a. R&D Engineer: Plan, design, specify, develop and/or test the system components as part of research and development (R&D). b. ProducerSupplier: Build out of raw materials and/or sub-components the system components in a factory. c. Technical Support: Helps customer with complains about system components and create bridge to R&D (e.g. service and investigation). d. Seller: Demonstrate system to individuals (e.g. patient, payer) who deside or have influence if the system is used or not. 2. Operator: In their domain trained individuals or group working for an enterprise (e.g. clinic, medical practice, diabetes center) supporting the work of the Health Care Provider by managing the equipment. a. IT Network Professional: Responsible for the enterprise network and computing facilities. b. IT Security Professional: Responsible for securing the enterprise network and computing facilities. c. Biomedical Engineer: Responsible for configuring, testing and maintaining the system components owned by or used in the perimeter of the enterprise. 3. Business User: In their domain trained individuals or group working for an enterprise (e.g. health insurance company, governmental organization, health care supply store) participating in the supply chain. a. Payer: Pays for the system components and services. Depending on the local rules this actor decide or is part of the decision it the system is used or not. b. Distributor: Brings the system components from the manufacturer to the patient. Depending on the local rules this actor decide or is part of the decision it the system is used or not. 4. Health Care Provider (HCP): In their domain trained individuals or group working for an enterprise (e.g. clinic, medical practice, diabetes center) interacting with the patient and operating the system components for demonstration purposes or to adapt the therapy. a. Counselor: Looks typically on a short-cycle basis after the patient and help them to manage their disease via training and consulting (e.g. Diabetes Nurse Educator). Depending on the local rules this actor decide or is part of the decision it the system is used or not. b. Nurse: Supporting the physician and helps the patient during their stay in the HCP perimeter. Depending on the local rules this actor decide or is part of the decision it the system is used or not. c. Physician: Diagnose disease and setup initial therapy. Authorize products which are subject to prescription. After therapy is running looks typically on a long-cycle basis after the patient in order to adapt the therapy. Depending on the local rules this actor decide or is part of the decision it the system is used or not. 5. End User: On the system trained individuals using it typically on a daily basis. a. Patient: Use the system components in order to threat his disease (e.g. person with diabetes). Patients must generally have elementary knowledge about his disease and knowledge about personal hygiene. Depending on the local rules this actor decide or is part of the decision it the system is used or not. b. Caregiver: Cares for the patient who is sick or disabled. Children, elderly persons or handicapped patients may need assistance provided by a reliable caregiver (e.g. parents). These caregivers need to have knowledge equivalent to the level required for patients. 6. Third-Party User (potentially bad actor): Typically untrained individuals which might interact with system components out of curiosity, by trying to help the patient or by attempting to turn off an alarm. This actor may obtain unsupervised access to system components. a. Patient Visitor: Enters the patient’s perimeter as a visitor. 7. Malicious entity (bad actor): Typically highly skilled individuals or group performing cyberattacks on system components. a. Hacker: Circumvents security and breaks into system components usually with malicious intent (e.g. blackmail, theft, become famous) but typically not with the intend to harm the patient. b. Attacker: Circumvents security and breaks into system components in order to harm the patient.

Some actor roles may be combined. For example, in some enterprises are maybe the IT Network Professional, IT Security Professional and Biomedical Engineer the same person or a counselor is also distributor.

uc [Package] Actors [System Users]

Manufacturer Operator Business User

IT Security Professional R&D Engineer Producer Technical Support Seller IT Network Professional Biomedical Engineer Payer Distributor

Potentially bad actor Bad actor

Health Care Professional End User Third-party User Malicious Agent (HCP)

Counselor Nurse Physican Patient Caregiver Patient Visitor Hacker Attacker

Figure 2: Actors

[5] Assets For the intended actors (see Figure 2) the PHD controls, stores and transmits various assets (the data asset inventory) in which also a (potentially) bad actor might be interested. The assets of interest are listed in Table I.

Table I: Assets Name Description Credentials Login credentials such as username and passwords, tokens, PINs, wireless secure codes, etc. Therapy data Therapy relevant data such as treatment settings, measurements, etc. Device data Non-therapy relevant data (e.g. language selection). Logs History of actions executed by the PHD which provides support to the manufacturer, HCP, etc. Indication Information from a PHD telling the user that the PHD needs attention for example status, reminder, error, warning and maintenance. Device control Control over the device functionalities. Protected Health Information Protected health information includes any information about health (PHI) status, provision of health care or payment for health care that can be linked to a specific individual.

Note: IEEE 11073™ PHD does not support define storage and transmission of PHI which falls under privacy regulations. Instead data is only linked to an anonymous System-ID. Personal Health Records (PHR) Personal health records are electronic records with individually identifiable health information that can be typically drawn from multiple sources and that is managed, shared and controlled primarily from the individual.

Note: IEEE 11073™ PHD does not support define storage and transmission of PHR which falls under privacy regulations. Instead data is only linked to an anonymous System-ID.

[6] Threat Surfaces The threat surface is the collection of possible entry points or ‘attack vectors’ where a (potentially) bad actor can try to control, modify data, enter data or extract data from the product system or impair the product functionality, communication. The assets of a PHD could be accessed by various entry points which also a (potentially) bad actor might use. The entry points of interest are listed in Table III.

Table II: Threat Surfaces Name Description IEEE 11073™ PHD Agent to Any kind of data exchange over a transport transport layer (e.g. USB, Manager Interface Bluetooth) accessible from outside the agent enclosure using IEEE 11073™ OXP. IEEE 11073™ PHD Manager to Any kind of data transport layer (e.g. USB, Bluetooth) exchange Agent Interface accessible from outside the manager enclosure using IEEE 11073™ OXP. Following threat surfaces are not in scope IEEE 11073™ PHD Manager to Any kind of data exchange interface (e.g. GSM, TCP/IP) from the Remote Support Services Interface manager to another device.

Note: Not in the scope of IEEE 11073™ PHD because not using OXP. User Interface Any kind of user interface (e.g. button, switch, LED, LCD, touch screen) of the PHD.

Note: Not in the scope of IEEE 11073™ PHD because not using OXP. Non-OXP external data interfaces Any kind of data exchange interface (e.g. RS232, Bluetooth Smart, SD Memory Card) accessible from outside the PHD enclosure which is not using IEEE 11073™ OXP.

Note: Not in the scope of IEEE 11073™ PHD because not using OXP. Internal data interfaces Any kind of data exchange interface (e.g. UART, JTAG) accessible only from inside the PHD enclosure (i.e. require opening of enclosure in a way which - if ever – is only done by a manufacturer actor).

Note: Not in the scope of IEEE 11073™ PHD because physical security is out of scope.

[7] Threat Sources The entry points of a PHD could be the target of various potential threat sources. The potential threat sources and their objectives are listed in Table III.

Table III: Threat Sources Threat Sources Threat Objectives Unintentional attack/outbreak accidental damage or exposure of all any kind of assets Employee Personnel (i.e., accidental damage or exposure of all any kind of assets Manufacturer, Operator, Business User, HCP) untrained use Employee Personnel (i.e., gaining unauthorized access to all any kind of assets Manufacturer, Operator, Business User, HCP) accidental use Personnel Employee (i.e., sabotage, gaining unauthorized access to all any kind of assets Manufacturer, Operator, Business User, HCP) with malicious intent Third-party User sabotage, gaining unauthorized access to all any kind of assets Malicious EntityActor sabotage, break in to access all any kind of assets Exploitation of PHD vulnerability sabotage, gaining unauthorized access to all any kind of assets to obtain access to other resources Malware sabotage, break in to access all any kind of assets Catastrophic event organizational operations

Note: Not in the scope of IEEE 11073™ PHD because this affects more than PHD and OXP.

[8] Threat Events Threat events are anything that has the potential to intentionally or unintentionally cause harm to the product, system data, the business, and/or ultimately end-users/patients. The threat sources could expose the PHD to various potential threat events. The potential threat events are listed in Table IV.

Table IV: Threat Events Name Description Non-adversarial threats Damage that occurs from inside employees with no ill will towards the organization; may possibly come from lack of user knowledge resulting in leak of information. Cause adverse impact to obtain Obtaining sensitive information, PHI, at the expense of damaging information organization and/or PHD. Coordinated campaign Multiple attempts to cause physical and network harm to organization and/or PHD. Crafted or created attack tools Developing tools with desire to damage PHD and/or organization’s network. Conduct an attack Desire to cause physical and network harm to organization and/or PHD. Personal injury Desire to cause physical harm to an individual. Exploit and compromise systems Targeting organizational vulnerabilities with the desire to harm the organization. Defective equipment or software Equipment or software that does not function as designed; could include software bugs. Deliver/insert/install malware Distribute malware to organizational systems with desire to damage organizational systems and devices. Following threat events are out of scope Reconnaissance Intelligent navigation of organization networks with desire to understand network infrastructure (i.e. network scans).

Note: Not in the scope of IEEE 11073™ PHD because OXP only provide point-to-point connection. Catastrophic event Unforeseen events such as weather or disaster.

Note: Not in the scope of IEEE 11073™ PHD because this affects more than PHD and OXP.

[9] Threat Mitigations Matrix Mitigations consist of taking for each threat surface from Table III the relevant threat event from Table IV, identifying the assets that can be affected by that from Table I in order to identify the potential harm and then applying a risk mitigation strategy.

Note: Without concrete implementation each assets accessible via IEEE 11073™ OXP must be considered to be affected by a threat event. Therefore assets are not part of the table. Note: Today OXP has beside base band security no additional security implemented therefore the possibility to break is 100%.

Note: Normally this must be done for the whole transport (including underlaying transport layer). They must consider already …. This whitepaper deals with the “high” level above OXP as shown in …

Check risk table and add columns.

Table V: Threat Mitigations Matrix Threat Potential Security Threat Events Mitigation strategies Surfaces Harms Categories IEEE Non-adversarial 11073™ threats In addition, e.g. limit what PHD Agent employees may do with access to Manager controls, provide IT Interface awareness/training program Crafted or created attack tools In addition, e.g. firewalls, intrusion detection systems, protection against message modification and message replay Coordinated campaign In addition, e.g. firewalls, intrusion detection systems, protection against message modification and message replay Crafted or created attack tools In addition, e.g. firewalls, intrusion detection systems, protection against message modification and message replay Conduct an attack In addition, e.g. implementation of access controls, limiting access to key employees Personal injury In addition, e.g. implementation of access controls, limiting access to key employees Exploit and compromise systems In addition, e.g. monitoring of system activity, implementation of access controls, and physical security monitoring Defective equipment or software In addition, e.g. monitoring of system activity, implementation of access controls, and physical security monitoring Deliver/insert/install malware In addition, e.g. antivirus/antimalware software, firewall IEEE Non-adversarial 11073™ threats In addition, e.g. limit what PHD employees may do with access Manager to controls, provide IT Agent awareness/training program Interface Crafted or created attack tools In addition, e.g. firewalls, intrusion detection systems, protection against message modification and message replay Coordinated campaign In addition, e.g. firewalls, intrusion detection systems, protection against message modification and message replay Crafted or created attack tools In addition, e.g. firewalls, intrusion detection systems, protection against message modification and message replay Conduct an attack In addition, e.g. implementation of access controls, limiting access to key employees Personal injury In addition, e.g. implementation of access controls, limiting access to key employees Exploit and compromise systems In addition, e.g. monitoring of system activity, implementation of access controls, and physical security monitoring Defective equipment or software In addition, e.g. monitoring of system activity, implementation of access controls, and physical security monitoring Deliver/insert/install malware In addition, e.g. antivirus/antimalware software, firewall

[10] References [11] the institute, “IEEE Standards on Cybersecurity“, March 2015, Vol. 39, Issue 1, p. 13 (www) [12] IEEE Cybersecurity, “Building Code for Medical Device Software Security” (www) [13] NCCoE, “Use Case: WIRELESS MEDICAL INFUSION PUMPS”, Draft, December 2014 (www) [14] FDA Guidance, “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices”, October 2014 (www) [15] ISO/ICE 27032:2012(E) Information technology — Security techniques — Guidelines for cybersecurity [16] IEEE Std 11073-20601-2014 Optimized Exchange Protocol (www) [17] IEEE Standards Definition Database (www) [18] NCCoE, “Use Case Wireless Medical Infusion Pump”, December 2015, Draft (www)