PHD Cybersecurity Standardization of Secure Plug Play Interoperability

PHD Cybersecurity - Standardization of Secure Plug & Play Interoperability Joint meeting of IEEE EMBS and HL 7 Health Care Devices 20 -September-2016 Christoph Fischer

Background No build-in security in IEEE 11073 PHD family of standards 2

Background Various data exchange interfaces with various mostly not aligned security approaches Source: Personal Connected Health Alliance, “Continua Design Guidelines, ” August 2015 3

Situation Statement • Industry standards for PHD data exchange like USB PHDC, NFC PHDC, Bluetooth HDP, Bluetooth Smart profiles and Zig. Bee HCP do no support data access control and secure data exchange between applications. • To date, these industry standards rely on security protection by o restriction of physical access to the device (USB, NFC) and o mechanism of the transport level (Bluetooth, Bluetooth Smart, Zig. Bee). • This limits the usage of such industry standards when information security is required. • In addition, for regulated medical devices, cybersecurity must also be addressed. 4

Part 1: What means …? Achieve comprehensive understanding via definitions Part 2: What do we want to solve? Present PHD cybersecurity scenarios to be addressed Part 3: How do we attack PHD cybersecurity? Inform about PHD cybersecurity roadmap and deliverables 5

Definition of PHD cybersecurity Personal Health Device (PHD) cybersecurity is the process and the capability of preventing • • • unauthorized access, unauthorized modification, misuse, denial of use or the unauthorized use of any information that is stored on, accessed from, or transferred to and from a PHD. Source: PHD Cybersecurity Whitepaper based on FDA, “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices, ” October 2014 and “ISO 31000: 2009 Risk management - Principles and guidelines” 6

Definition of Risk Analysis Risk analysis is the process to comprehend the nature of risk and to determine the level of risk. Risk analysis provides the basis for risk evaluation and decisions about risk treatment. Source: ISO Guide 73: 2009 Risk management – Vocabulary as used in ISO 31000: 2009 Risk management - Principles and guidelines Risk analysis is the process part of PHD cybersecurity. 7

Definition of Information Security Information security is the preservation of confidentiality, integrity and availability of information. In addition, other properties, such as authenticity, accountability, nonrepudiation, and reliability can also be involved. Source: ISO/IEC 27000: 2016 Information technology - Security techniques - Information security management systems - Overview and vocabulary Information security is the capability part of PHD cybersecurity. 8

Part 1: What means …? Achieve comprehensive understanding via definitions Part 2: What do we want to solve? Present PHD cybersecurity scenarios to be addressed Part 3: How do we attack PHD cybersecurity? Inform about PHD cybersecurity roadmap and deliverables 9

Scalability of Information Security Toolbox 10

Summary of Scenarios Component / Device / System B Component / Device / System A Application A ? Application B A solution for a scalable information security toolbox appropriate for PHD communication which supports multiple access levels / rights (e. g. , restricted read access, restricted write access, full read access, full write access, full control access) over untrusted transports with limited resources (e. g. , processing power, memory, energy) is required. 11

Part 1: What means …? Achieve comprehensive understanding via definitions Part 2: What do we want to solve? Present PHD cybersecurity scenarios to be addressed Part 3: How do we attack PHD cybersecurity? Inform about PHD cybersecurity roadmap and deliverables 12

PHD Cybersecurity Team The PHD Cybersecurity Team was founded by members of IEEE 11073 PHD WG, Bluetooth Med. WG and PCHA TWG in November 2015. The mission of the PHD Cybersecurity Team is • to achieve comprehensive understanding of PHD cybersecurity in the PHD community, • create a scalable information security toolbox appropriate for PHD communication and • build the basis for secure interoperability toolbox including Plug&Play. 13

PHD Community The PHD community consists of the following groups (in no particular order): • Patients and Relatives (e. g. represented by #We. Are. Not. Waiting) • Service / Healthcare Providers (e. g. represented by governmental organizations) • Payers (e. g. represented by VA) • Manufacturers (e. g. represented by PCHA) • Regulations (e. g. represented by FDA) • Professional Organizations (e. g. represented by Bluetooth Med. WG, IEEE Cybersecurity Initiative, IEEE EMBS, VDE, INCOSE Healthcare WG) • Standard Developing Organizations (e. g. represented by IEEE 11073 PHD WG, AAMI / UL 2800, ISO / DIN, HL 7) The PHD Cybersecurity Team tries to engage / involve all groups. The 14

PHD Cybersecurity Roadmap Bluetooth SIG Med. WG AAMI / UL 2800 exchange via members in both groups PCHA TWG PHD Cybersecurity Team exchange via members in both groups IEEE 11073 PHD WG … create Bluetooth Service 2017 used by create used by PHD Cybersecurity Whitepaper 2016 PCHA TWG used by IEEE 11073 PHD WG used by IEEE Std create 11073 -XXXXX 2017 / 2018 15

PHD Cybersecurity Whitepaper The PHD Cybersecurity Whitepaper will contain • the background related to PHD cybersecurity, • a detailed risk analysis of use cases specific to PHD types (process part of PHD cybersecurity) and • a scalable information security toolbox appropriate for PHD communication (capability part of PHD cybersecurity). The whitepaper (shall) becomes the basis for secure interoperability in open consensus standards (e. g. , by IEEE 11073 PHD WG), specifications (e. g. , by Bluetooth Med. WG) and guidelines (e. g. , by PCHA TWG). 16

Status of PHD Cybersecurity Whitepaper • Part 1: Background o Content collected. Currently cleaning-up. • Part 2: process part of PHD cybersecurity o Several security assessment tools, methods and processes reviewed. o Decision to use STRIDE for threat modelling. o Decision to use embedded Common Vulnerability Scoring System (e. CVSS) to score device vulnerabilities. o Use Cases selected from no-regulated over health & fitness to class III medical devices: • • • Coffee Machine Physical Activity Tracker Pulse Oximeter Sleep Apnoea Breathing Therapy Equipment Insulin Pump Implantable Continuous Glucose Monitoring o Work on Use Cases started. • Part 3: capability part of PHD cybersecurity o Concept work in Bluetooth SIG Med. WG started. 17

Workflow System Context Pre-Mitigation Scoring (e. g. with e. CVSS) Potential Vulnerabilities Post-Mitigation Scoring (e. g. with e. CVSS) Residual Vulnerabilities Implementation l ia nt ns te tio Po tiga i M Im M ple iti m ga en tio te ns d Define & Decompose Attack Surface (e. g. with STRIDE) Scalable Information Security Toolbox 18

Summary • PHD cybersecurity is the process (e. g. , risk analysis) and the capability (e. g. , information security) of preventing successful attacks on data storage or exchange. • A solution for a scalable information security toolbox appropriate for PHD communication which supports multiple access levels / rights over untrusted transports with limited resources is required. • Members of IEEE 11073 PHD, Bluetooth Med. WG and PCHA TWG have founded the PHD Cybersecurity Team in order to align and push the work around PHD cybersecurity. • The PHD Cybersecurity Team is without any fees open to everyone. If you want to be involved just send an e-mail to christoph. fischer@ieee. org and nathaniel. hamming@contractors. roche. com. 19

Akib Uddin Alexander Mense Andrew Okeefe Asim Muhammad Bill Miao Benoit Menez Brian Ondiege Carsten Mueglitz Chris Gates Chris Roberts Chris Kelsey Christoph Fischer Craig Carlson Cyril Ndifor Daidi Zhong Eugene Vasserman Harry Qiu Jan Wittenber Martha De Cunha Maluf. Burgman Martin Rosner Matt d'Entremont Melanie Yeung Michael Kirwan Nathaniel Hamming Rick Hampton Scott Thiel Stan Wiley Sungkee Lee Todd Swansey William Saltzstein Xingwen Chen Doing now what patients need next Thank you John Garguilo Jordan Hartmann Li Lianyuan Manfred Kube

Definition of Plug&Play Interoperability • Plug&Play is that all the user has to do is make the connection – the systems automatically detect, configure, and communicate without any other human interaction [1]. • Interoperability is the ability of client components to communicate and share data with service components in an unambiguous and predictable manner as well as to understand use the information that is exchanged [2]. Source: [1] “ISO/IEEE 11073 -10201: 2004, ” December 2004. [2] Personal Connected Health Alliance, “Continua Design Guidelines, ” August 2015. 21

Scenario A Device-to-Device Communication with Multiple Access Levels Device A (e. g. Medical Device) Communication Interface Device B (e. g. Manufacturer Device) Access Level “ 3” Device C (e. g. Trusted Third-Party Device) Access Level “ 2” Device D (e. g. Untrusted Device) Access Level “ 1” 22

Scenario B Device-to-Device Communication with Change to Device Access Levels with or without Reconnecting Device A (e. g. Medical Device) Device B (e. g. Remote Control Unit) Communication Interface App Access Level “ 3” Access Level “ 2” Access Level “ 1” 23

Scenario C App-to-Device Communication with Multiple Access Levels between Apps Device B (e. g. Smartphone, Desktop PC) Device A (e. g. Medical Device) App I Communication Interface (OS) Communication Stack (e. g. Manufacturer App) Access Level “ 3” App II (e. g. Trusted Third-Party App) Access Level “ 2” App III (e. g. Untrusted Third-Party App) Access Level “ 1” 24

Scenario D App-to-Device Communication with Change to App Access Levels with or without Reconnecting Device B (e. g. Smartphone, Desktop PC) Device A (e. g. Medical Device) Communication Interface (OS) Communication Stack App Access Level “ 3” Access Level “ 2” Access Level “ 1” 25

Scenario E App-to-App Communication with Multiple Access Rights between Apps Device B (e. g. Smartphone, Desktop PC) Device A (e. g. Medical Device) App I (e. g. Device FW Update Module) Access Right “ 001” App VI (OS) Communication Stack Communication Interface (OS) Communication Stack (e. g. Device FW Update) Access Right “ 001” App II App V (e. g. Device Config Module) (e. g. Config SW) Access Right “ 010” App III App VI (e. g. Device Service Module) (e. g. Service SW) Access Right “ 100” 26

Scenario F App-to-App Communication with Change to App Access Rights with or without Reconnecting Device B (e. g. Smartphone, Desktop PC) Device A (e. g. Medical Device) App I (e. g. Device FW Update Module) Access Right “ 001” App II (OS) Communication Stack Communication Interface (OS) Communication Stack App IV Access Right “ 001” (e. g. Device Config Module) Access Right “ 010” App III (e. g. Device Service Module) Access Right “ 100” 27

Scenario G Software of unknown provenance (SOUP) in Communication Path Device A (e. g. Medical Device) Application MCU Communication MCU FW (Safety Class C) FW Stack (SOUP) Device B (e. g. Remote Control) Communication Interface Communication MCU Application MCU FW SW (Safety Class C) Stack (SOUP) 28

Scenario H End-to-End Communication over various transports and stations Source: Personal Connected Health Alliance, “Continua Design Guidelines, ” August 2015 29

Scope of Scalable Information Security Toolbox Scope of scalable information security toolbox + Proprietary Extensions Scalable means also that the information security toolbox fits into the whole end-to-end communication + Proprietary Extensions Source: Personal Connected Health Alliance, “Continua Design Guidelines, ” August 2015 30

STRIDE Background • Created by Microsoft as a design time tool to ensure CIA in a finished system. • Decomposes system data flow diagram into threat categories: o Spoofing o Tampering o Repudiation o Information disclosure o Denial of service o Elevation of privilege 31

STRIDE Background Pros Cons • • Easy to conceptualize and train Available free tool from Microsoft Does not require domain expertise Repeatable process Auditable Scalable • • • No direct support for embedded systems Does not work well with Agile development process, as it requires a full system definition to define attack surface and data flow model. No vulnerability scoring functionality Discloses an ‘atomic’ level of vulnerabilities, with no relationships between vulnerabilities being exposed (i. e. chained attacks) No export functionality into other tools (output file is however in XML) Multiple occurrences of the same vulnerability No reference to CWE identifiers No native Mac OS X version available 32

Common Vulnerability Scoring System (CVSS) Background • CVSS is widely used to score weaknesses is existing fielded software based products. • This metric is used by agencies like DHS, FTC, CVE, and FDA. • CVSS uses 14 separate attributes with varying levels of subjectability and thus varying levels of impact on the final summary CVSS score. • CVSS score is a value between 0. 0 (no issue) and 10. 0 (high level issue). Base Metric Group Temporal Metric Group Environmental Metric Group Access Vector Confidentiality Impact Exploitability Collateral Damage Potential Confidentiality Requirement Access Complexity Integrity Impact Remediation Level Target Distribution Integrity Requirement Authentication Availability Impact Report Confidence Availability Requirement 33

embedded Common Vulnerability Scoring System (e. CVSS) Background • CVSS does not support medical devices and analyses at design time, to guide and assist in development activities. • Therefore e. CVSS, a slightly modified branch of CVSS, was developed by a large medical device manufacturer (and disclosed here with their approval). • For e. CVSS was temporal base metric group removed, target distribution by awareness replaced and CIA triad elevated to be product wide. Base Metric Group Product Importance Environmental Metric Group Access Vector Confidentiality Impact Confidentiality Importance Collateral Damage Potential Confidentiality Requirement Access Complexity Integrity Impact Integrity Importance Awareness Integrity Requirement Authentication Availability Impact Availability Importance Availability Requirement 34

Christoph Fischer Senior Systems Engineer Roche Diabetes Care Gmb. H Sandhofer Strasse 116 68305 Mannheim Germany Mail: christoph. fischer@ieee. org