Page 1

Medical Device Standardsfor Information Security– Concepts and Relevance

Dr. Georg HeidenreichIEC 62A / ISO 215 - JWG7 Convenor Siemens Healthcare GmbH

Page 2

Why ?What can manufacturers do ?Which standards….?How to adapt Risk Management?From which domains can we learn ?

.

Page 3

Why ?

.

Page 4

SocietalExpectations

Legislation

System Goals

TechnologyGoals

Quality ofCare Privacy

Safety &Performance

Data Protection

Safety Effectiveness

Security

Reliability MaintainabilityInteroperability Segregation

PhysicalSafety

Persistence

Expectations, Law, Technology

IntegrityNonRepudiation AuthenticityAvailabilityPerformance

ISO TC 215 / IEC SC62A Joint-Working Group 7:

”Safe, effective and secure health software and health IT systems,including those incorporating medical devices”

MDR

GDPR

Page 5

Data

Protection

Intended Use

Foreseeable

Use Error

Misuse

UnauthorizedUse

Attack

Product Goals

What the customer reallyneeds…

Market Access through

Safety and Performance

Page 6

Data

Protection

Product Goals including Cybersecurity

What the customer reallyneeds…

Market Access through

Safety and Performance

Intended Use

Foreseeable

Use Error

Misuse

UnauthorizedUse

Attack

Intended effects of unintended use

Page 7

Product Security vs. Product Safety

ProductSecurityincident

Safetyincident

Security processes aim at protecting asystem from being influenced by theenvironment in a way that the authorizedusers and system owner do not intend.

Safety processes aim at keeping a systemfrom influencing its environment in a waythat the authorized users and system ownerdo not intend.

Security provides "a form of protection where a separation is created between the assets and the threat." These separations aregenerically called "controls," and sometimes include changes to the asset or the threat. source: OSSTMM 3, Institute for Securityand Open Methodologies (ISECOM)

Page 8

What can manufacturers do?

.

Page 9

Security in Clinical IT Networks

DOCUMENTSSECURE

PROCESSSECURITYCONTROLS

ISO 13485Quality

ISO 14971Risk

Standards for Medical Device CybersecurityWHAT

Policies & InfrastructureAccess Control

Certificates and Keys for Encryption, Signature

Skills & Organizational Measures

Awareness

Responsibility

Device

Network

Organization

CIO uses foreign emailaddress to send ‚evil‘

monitoring attachment,gets >30 %

Technology supports security – it can not substitute responsible use

Page 10

Threat/RiskAnalysis

Specify security for ITadministrators and device

users

Secure Manufacturing of Medical Devices

Specify Secure UseBuild Device with

Security Controls

SecureDevelopment

Lifecycle

Provide SecurityUpdates

DOCUMENTS

Surveillance,Mitigation,Migration

Build Device with

Security Controls

Tools, OTS-SW,Design, Coding,

Release

SECURE

PROCESSSECURITYCONTROLS

ISO 13485Quality

ISO 14971Risk

Standards for Medical Device CybersecurityWHAT

Page 11

JWG7 Standards for Medical Device Security

1b) Secure ManufacturingSegregationCoding

3) Product Security Features

4) Documentation: Secure Use

1a) Secure Tools and Components

IEC 82304: Product Safety

IEC 62304: Software Lifecycle

2) Maintenance: Security Updates

Page 12

Pre-Market„Medical Device - Software Lifecycle Processes“

Unit Implementation

Secure Unit Design„accept all / fail gracefully“, & „expose little“ cf. Reliability

FunctionalRequirements

Cybersecurity (IEC 62443-4-1 or IEC 80001-5-1)

Protection Controls (from system security Threat/Risk Analysis)encryption, signature, firewall, audit logs, backup, access control

Architecture Secure Designe.g. segregation of SOFTWARE ITEMS (also: segmentation)

Verify implementation of Software mitigations

Detailed Design

Safety / IEC 62304

(DKE AK 811.3.3)content derivedfrom establishedstandards

IEC 62443-4-1NISTOWASP

Software DevelopmentPlanning Security gates in process, trusted communication, trusted tools

Fuzz Testing, Penetration Testing, On-Premise-TestingSoftware System Testing

Software Integration

Secure CodingSecure coding principles, signed code & code signature verification

OTS Security processes with suppliers, trusted OTS

Redo TRA, Inform users/authorities, Provide updates, Participate in CERT/ISAOsSoftware Maintenance

Page 13

‚MDS2‘ Product security information

13

Manufacturer Disclosure Statement on Medical Device Security = MDS MDS = MDS2

• Legislative foundation is HIPAA / US Law „45 CFR Part 160 and Part 164”Privacy Rule in, Subparts A and ESecurity Rule in Subparts A and C

• Base standard is IEC 80001-2-2

• ‚20 Questions‘ - Issued in 2013 by cooperation of MITA & HIMSS

• De-facto requirement in U.S. markets, ZVEI trying to leverage this in Germany

• Version 2 (end of 2018) will specify• Two more questions• Machine-readable format (CSV, SPDX)• Software-Bill-Of-Material (SBOM)

Page 14

Post-Market

Deployment

Vulnerability Disclosure

Corrective Action

Validation

Threat/Risk Analysis

Configuration

Migration

Design & Implementation

Incident Handling

Factory Customer-site

• Application

• Platform

• Databases

• Operatingsystem

• Drivers, etc

Decommissioning

AAMI TIR97

ISO 30111

Page 15

Which Standards may be relevant ?

Page 16

Security & Safety

Protection Goals:• Essential Function*• Information Assets(Data, functions, software)

Protection Goals:• Health• Safety

Product := System plus Documents- Intended Use- Instructions for Use- Intended Operational Environment

SecurityThreats

SafetyHazards

IEC 60601

ISO 14971

IEC 80001

IEC 62443

NIST SP800

OWASP

BSI / KRITIS

IEC 80001-5-1 (Process) IEC 60601-4-5 (Controls)

Confidentiality of data inthe device

Integrity of data andfunctions

Availability ofdata & services

Medical Device

Standards for Medical Device CybersecurityWHICH

Page 17

IEC TC 62Design & DevelopmentStandards for „Safety“IEC 60601 / ISO 80601

Intended Use

Foreseeable

Use Error

Misuse

UnauthorizedUse

Attack

„Security“ „Safety“

Standards and Regulation for Market Access

JTC1 / SC 27 – ISO 2700xIEC TC 65 – IEC 62443Development & Service

Standards

„Cybersecurity“

What thecustomer pays

for…

FDA / HHS /HIPAAEU General Data Protection

- Safety standards for medical devices rely onthe assumption of the „friendly operator“,since availability usually is more importantthan security.

consider misuse - as far as possible

prot

ect s

afet

y-re

leva

nt fu

nctio

ns

Standards for Medical Device CybersecurityWHICH

Page 18

Threat/RiskAnalysis

Specify security for ITadministrators and device

users

Secure Manufacturing of Medical Devices

Specify Secure UseBuild Device with

Security Controls

SecureDevelopment

Lifecycle

Provide SecurityUpdates

DOCUMENTS

Surveillance,Mitigation,Migration

Build Device with

Security Controls

Tools, OTS-SW,Design, Coding,

Release

SECURE

PROCESSSECURITYCONTROLS

ISO 13485Quality

ISO 14971Risk

Standards for Medical Device CybersecurityWHICH

Page 19

Threat/Risk AnalysisNIST SP800-30ETSI TS 102 165 TVRAIEC 62443-3-2ISO 20004 TRA

IETFRFC 7525 BPC 195 Secure Use Of TLS / DTLSRFC 6125 Identity for PKI Certificates on TLS

ISO18004 Timestamps18033 Encryption18367 CryptoAlgorithm18370 Dig Signatures19592 Secret Sharing19772 Auth Encryption27040 Secure Storage

Standards for Medical Device CybersecurityWHICH

SAFECODEOWASPISO 2700x(Product Development)

ISO 27034 MS SDL, IEC 62443-4-1 IEC 80001-5-1, BSI CSE 132

ISO 15408 Common CriteriaNIST SP800-53 Security ControlsEN 45502-1 & ISO 14708-1 Active ImplantsISO 22696 PHD Identifict‘n & Authenticat‘nISO 11633-1/2 RemoteServiceIEC 60601-4-5 ControlsIEC 60601-1 SafetyISO 13606-4 EHR

NIST FIPS140-2 Crypt Mod180-4 Hashing186-4 Dig Sign193 PlatfrmResilience197 Encryption198-1 Hash Msg Auth200 Min Sec Reqmts201 Person Authentic202 SHA-3

IEC 80001-2-2, -2-8, -2-9HIMSS NEMA MDS2

CLSI AUTO-11-A2

ISO 15026-1/2Assurance Case

NIST FIPS 199 Sys Categories

ISO 15443 -1/2Security Assurance

ISO/IEC 29147 DisclosureISO/IEC 30111 Vuln/Incident

ISO 2700xInformation Security

Management(Product Operations)

Specify Secure UseBuild Device with

Security Controls

SecureDevelopment

Lifecycle

Provide SecurityUpdates

Page 20

How to adapt Risk Management?

.

Page 21

Information Security vs. Product Safety

Product

Secu

rityin

ciden

tS

afetyin

ciden

t

Security processes aim at protecting a system frombeing influenced by the environment in a way that theauthorized users and system owner do not intend.

Safety processes aim at keeping a system frominfluencing its environment in a way that theauthorized users and system owner do not intend.

Security provides "a form of protection where a separation is created between the assets and the threat." These separations are generically called "controls," andsometimes include changes to the asset or the threat. source: OSSTMM 3, Institute for Security and Open Methodologies (ISECOM)

Page 22 Data Protection GoalsSafety Goals

Medical Device

External Incident:Wrong Input, Wrong

Benevolent Use

Safety:Degradation or Loss

Performance /Effectiveness:

Degradation or Loss

Confidentiality, Integrity,Availability:

Degradation or Loss

Wrong Device Data/Network Output

Function Slowdown /ShutdownPhysical Harm

Internal Incident(Unintended /Wrong

Function/Data)

Privacy Breach

Hacker,Zero-Day Eploit(unfoeseeable)

MitigateUnintended

Consequences(Internal)

DocumentUnintended

Consequences(External)

„Foreseeable Misuse“ covers Cybersecurity →ISO 14971 covers the overall Risk Management

a) Device cannot distinguish ‚benevolent‘ from ‚malicious‘.

b) Not all attack scenarios are ‚foreseeable‘ when placing on themarket.

Attack, Vulnerability(remote, foreseeable)

Malevolent Use,Vulnerability

(local, foreseeable)

Security-only = dark box fill

Security-related = white text

Safety-related = orange frame

Analyze RootCauses

CRIMINALUSE

(local)

Page 23

Example Threat/Risk Analysis (TRA):STRIDE and Mitigations

From: Jeremy Clark,Lecture Notes,Concordia Univ, CA,

Page 24

Example Threat/Risk Analysis (TRA):ETSI TS 102 165-1 V5.2.3 (2017-10)

24

TVRA Method1. Identification of Target Of Evaluation ToE2. Identification of objectives3. Identification of security functionalities4. Systematic inventory of the assets5. Systematic identification of vulnerabilities

1. Weakness2. Vulnerability3. Attack Method

Practicality: Knowledge, Time, Expertise, Opportunity, Equipment, Intensity //benefit: gain/fame

6. Calculation of likelihood and impact7. Establishment and classification of the risks8. Identification of countermeasures9. Cost-benefit analysis for countermeasures10.Detailed specification of security requirements

Page 25

Example Threat/Risk Analysis (TRA):Application Threat Modeling by OWASP(https://www.owasp.org/index.php/Application_Threat_Modeling )

The threat modeling process• is part of an SDLC• produces list of threats, mitigations and documents (assumptions,

solutions, residual risk)• looks at a system from a potential attacker's perspective• can be decomposed into 3 high level steps:

• Step 1: Decompose the Application.

• Step 2: Determine and rank threats.

• Step 3: Determine countermeasures and mitigation.

Page 26

Hacker,Zero-DayExploit

~Gain / Effort

Safety Cybersecurity

Attack,Vulnerability

(remote)

Security-only = green box fill

Security-related = white text

Safety-related = orange box/frame

CRIMINAL USE(local)Internal Fault

Wrong Input

Wrong BenevolentUse

Reduceprobability

Reduceimpact

Page 27

From which domains can we learn ?

.

Page 28

IEC 62443 Industry Automation and Control SecurityFamily Overview

28

Gen

eral

Productdevelopmentrequrements

Technical securityrequrements for

IACS components

ISA-62443-4-1 ISA-62443-4-2

Securitytechnologies for

IACS

ISA-TR62443-3-1

Security levels forzones and condults

ISA-62443-3-2

System securityrequrements and

security levels

ISA-62443-3-3

Requirements for anIACS securitymanagement

system

ISA-62443-2-1 ImplementationGuidance for anIACS securitymanagement

system

ISA-62443-2-2instalation andmaintenance

requirements forIACS suppliers

ISA-62443-2-4

Terminology,concepts and

models

ISA-62443-1-1

Master glossary ofterms and

abbreviations

ISA-62443-1-2

Sytems securitycompliance metrics

ISA-62443-1-3

IACS securitylifecycle and use-

case

ISA-62443-1-4

Sys

tem

Com

pone

nt

Patch managementin the IACSenvironment

ISA-62443-2-3

Pol

icie

s&

proc

edur

es

* IEC 80001-5-1

* IEC 60601-4-5

Page 29

Idea of application of IEC 62443

• Consider different tiers, e.g. those of IEC 62443

• Assign each “Foundation“ process to one of these tiers

• Responsibility for lower tiers is with suppliers, manufacturers, providers

• Responsibility for upper tiers is with the HDO

.

Page 30

IEC 62443 Reference Model and clinical ICT networks:

Hospital

Patient-centric processes

Clinical Workflow (IT)

Clinical IT Function (IHE Actor)

Medical Device, POCT, LabProcess

Basic Control

OperationsManagement

EnterpriseSystems

SupervisoryControl

Medical Device

Order Placer / Filler /Image Archive

Hospital InformationSystem

Enterprise System

IHE ScheduledWorkflow

Page 31

Enterprise Process

Clinical Workflow

Clinical Function (single. atomic step)

Device / Point-Of-Care / Component

Processes in the tiers of IEC 62443

Device

IT QualityManagement

Data Protection/ Privacy

IT Security Risk Benefits& Safety

Organization& Roles

Research /Trials

Patient Admin/ ClaimsEpidemiology

Data / ServiceTerms &Model

Imaging LabConfigurationManagement

IT Component IT Network HealthSoftware

Clinical SafetyReimbursement,Reporting, Tax

Accounting &Billing

Inventory &Purchase

HumanResources

Page 32

Thank you for your attention!

.

Page 33

Cybersecurity – Related Work

UP.KRITIS (Germany)• „Best-Practice“

BSI (Germany)• CS067 „Anforderungen an netzwerkfähige Industriekomponenten “• CS 132 „Empfehlungen für Hersteller vernetzter Medizingeräte“

IEC 62443- Industrial Automation and Control Systems• Recognized by the Food&Drug Administration

EU – DG GROW• Medical Device SW workgroup

COM477 / ENISA / Cybersecurity Certification Framework• Product scope ?• Medical device domain ?