Page 1 Medical Device Standards for Information Security – Concepts and Relevance Dr. Georg Heidenreich IEC 62A / ISO 215 - JWG7 Convenor Siemens Healthcare GmbH
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 ?