Security Requirements/Expectations
of Biomedical Devices
December 5, 2013
Start Time: 9AM US Pacific,
12PM US Eastern, 5PM London
1
Welcome
Conference Moderator
Michael Boyd
Portland, USA Chapter
Chief Information Security Officer &
Director of Information Security
Management
Providence Health & Services
2
Agenda
Speakers
• Kevin McDonald
Clinical Information Security, Mayo Clinic Office of Information
Security
• Dale Nordenberg
Executive Director and Co-Founder, Medical Device Innovation,
Safety and Security Consortium (MDISS)
• Roy Wattanasin
Information Security Officer, MITM
Closing Remarks
3
Medical Device Security in
a Connected World
Kevin McDonald
Clinical Information Security
Mayo Clinic
4
Secure CAT Scanner
At least with this cat scanner if there is any hacking
we only need to worry about hairballs!
5
Topics
• Mayo Clinic Overview
• Working in a Hostile Environment
• Medical Device Security in the News
• Medical Device Vendors
• Regulatory Environment
• Mayo’s Response
• Clinical Information Security
• CIS Activities and Planning
• Next Steps and Other Opportunities
Mayo Clinic Overview
• Provides Patient Care, Education and Research
• 65,000 Employees
– 4,100 Employed physicians & scientist
– 3,500 Residents & students
• Large group practices in MN, AZ, FL
– 70 Health system sites across upper Midwest
• Over 1 million patients per year
• Technology dependent
– Paperless patient care
– Interconnected systems and devices
– ~200,000 active IP addresses
• Committed to a 6 billion dollar investment in Minnesota
7
Working in a Hostile Environment
“Securing an environment of Windows platforms from abuse
- external or internal - is akin to trying to install sprinklers in a
fireworks factory where smoking on the job is permitted.”
“We only need to be lucky once. You need to be lucky every
time.”
“Another way to lose control is to ignore something when
you should address it”
“We have only two modes - complacency and panic.”
8
Medical Devices in a Hostile Environment
• Medical devices are becoming more connected and
technology dependent, thus more vulnerable
• Patient care is dependent on technology
• No network can be assumed to be secure anymore
• Skill level to cause harm is going down
• Tools to compromise and harm systems are readily
available and cheap (free)
• Devices can be in use for > 10 years
• We are way beyond just firewalls & anti-virus
9
In The News
• Deloitte Brief - 2013
– “Among the unintended consequences of health care’s digitization and
increased networked connectivity are the risks of being hacked, being
infected with malware, and being vulnerable to unauthorized access.”
• Gartner – Top Industry Predicts 2013
– “By 2016, patients will be harmed or placed at risk by a medical device
security breach.”
• Veterans Affairs Department
– Experienced 122 virus / malware infections in medical devices the last 14
months that had potential to harm patients
– Launched an initiative to isolate 50,000 networked devices
In The News (cont.)
• Department of Homeland Security – Industrial Control
Systems Cyber Emergency Team Alert
– “…reported a hard-coded password vulnerability affecting roughly 300 medical
devices across approximately 40 vendors.”
• Newspaper Articles
– Wall Street Journal “Potential Cyber attacks on Medical Devices Draw Attention”
– Reuters “FDA urges protection of medical devices from cyber threats”
– Washington Post “FDA, facing cyber security threats, tightens medical-device
standards”
– Healthcare Information Security (Nov. 2013) Michael McNeil, Global Security and
Privacy Leader at Medtronic, says “it's vital for all medical device manufacturers
learn from independent security experts and ethical hackers, such as Jay Radcliff of
consulting firm InGuardians, and the late Barnaby Jack of vendor IOActive and
before that, McAfee, who have, for example, demonstrated how they can remotely
access web-enabled medical equipment, such as wireless insulin pumps, to deliver
potentially dangerous doses of drugs.”
Medical Device Vendors
• Security as an “afterthought” (or no thought)
• Poor coding and configuration practices
–
–
–
–
–
Hard coded password
Inability to run basic anti-virus software
Default settings
Elevated privileges
Unencrypted data
• Dependent upon older OS, software and technologies with
no upgrade paths
• Devices subject to a number of vulnerabilities
–
–
–
–
Denial of service
Password guessing
Old published exploits
Remote exploitation
• Vendors hide behind FDA re-certification
Regulatory Environment
• FDA is becoming concerned
– “We are aware of hundreds of devices involving dozens of
manufacturers that have been affected by cyber security
vulnerabilities or incidents”
• FDA published draft guidance for device security
– Limit access to trusted users only
– Ensure trusted content
– Use fail safe and recover features
• FDA published recommendations for healthcare facilities
– Restrict access
– Keep AV and Firewalls up to date
– Protect network components – evaluations, patches, disabling ports
& services
– Develop strategies to maintain service
FDA Q&A
• Who is responsible for ensuring the safety and
effectiveness of medical devices that incorporate OTS
software?
– You (the device manufacturer who uses OTS software in your
medical device) bear the responsibility for the continued safe and
effective performance of the medical device, including the
performance of OTS software that is part of the device.
• Is FDA premarket review required prior to
implementation of a software patch to address a cyber
security vulnerability?
– Usually not. In general, FDA review is necessary when a change or
modification could significantly affect the safety or effectiveness of
the medical device
15
Reporting Cyber-security Issues
• Lack of reported issues
– MAUDE – Mandatory device reporting database
• No issues found for “Computer Security Issue”
• FDA Reporting
– Mandatory reporting for manufacturers and healthcare
providers in case of a death or injury – Form 3500A
– Voluntary reporting by consumers and healthcare
professionals for adverse events or problems – Form 3500B
• Device Vulnerabilities
– ICS-CERT – by e-mail or phone
16
Mayo’s Medical Device Environment
• Medical Devices
– 97,000 medical devices, ~15,000 devices attached to the network
• Varied responsibilities for purchase, installation and maintenance of
medical equipment
– Biomed, departments, IT, vendors
• Poor control over some types of equipment purchases
• Difficulty finding business owners for some devices
• Little control over what is placed on the network
• Lack of training and education on security risks
• Security of devices and response to incidents not integrated into
overall Mayo’s enterprise processes
• Need strategy to address legacy devices
– Cost of just replacing all XP devices $300M (not affordable)
Mayo’s Response
~Needs of the Patient Comes First~
• Hired a Chief Information Security Office (CISO)
– Jim Nelms
• Formed the Office of Information Security (OIS)
– Vision
• Information Security is here not to prevent, but rather to make possible
– Mission
• Enabling people, process and technology through secure techniques to
deliver the Mayo Clinic strategic and operational objectives
• Created structure for Clinical Information Security
– Dedicated to clinical and research device security
– Director – Kevin McDonald
– Principle Security Analyst – Debra Bruemmer
– Principle Security Engineers – tbn
– Additional Engineers & Analyst in 2014
Clinical Information Security (CIS)
• Enable Mayo Clinic initiatives by supporting a secure
environment for clinical and research devices by
– Developing a secure technical architecture for medical & research
devices
– Developing mitigation & management strategies for vulnerable
devices
– Providing processes & specialized knowledge to enable the
purchase, evaluation and secure maintenance of clinical &
research devices
– Integrating medical & research devices into the overall security
strategy, risk management, incident response & monitoring
processes
Activities and Planning
• Validation of security concerns
• Multi-year plan to improve the security posture of
medical devices
• Partnering with Biomed, Clinical Departments, IT
• Includes
– People
– Processes
– Technology (may be the easiest)
• Five security levels
– Basic fundamentals to world class
20
Validation of Security Concerns
• Vulnerability assessment and penetration testing for 45
medical devices over 5 days
• 12 to 14 experts each day from 4 external vendors
• Initial concerns (and more) were confirmed:
–
–
–
–
–
–
–
Hardcoded, default, weak or no passwords
Backdoor accounts
Unencrypted data and communications
Weak input validation and fragile applications
Use of remote access software and services
Unneeded services running – VNC, Telnet, FTP, etc.
Susceptibility to fuzzing and denial of service
• Surprising results
– Availability of equipment on secondary market to reverse engineer
– Social engineering of vendor support
– Access to client support sites with manuals, firmware, etc.
21
Basic Capabilities
• Inventory completion & validation
• Risk stratification
• Education
• Solution set development & implementation
• Incident response process (medical devices)
• Targeted security monitoring
• Medical device hardware & software standards
• Patch and update processes
• Device vulnerability assessments
Intermediate Capabilities
• Procurement, accreditation and retirement processes
• Solution set maintenance and compliance
• Responsibility and accountability matrix
• Enterprise device scanning
• External communication limitations
• Device security governance
• Regulatory and vendor involvement
Mature Capabilities
• Account management
• Endpoint protection
• Secure coding standards
Advanced Capabilities
• Organizational changes to improve support processes
• Ongoing testing processes: Static / Dynamic /
Penetration
• Security research program
Superior Capabilities
• Full integration into
enterprise operational
activities
• Regulatory body influence
• Vulnerability management
program
• Vendor management
program
• Operational processes
reviews
• Security metrics
Next steps
• Mitigate vulnerabilities identified
• Identify other high risk system that may need short
term mitigations
• Complete detailed planning and resource needs for
basic and intermediate capabilities
• Partner with interested groups to promote medical
device security
Other Opportunities
• Support and Departmental Systems Security
–
–
–
–
–
–
Temperature monitoring
Infant abduction
Pharmacy automation
Patient tracking
Nurse call systems
+ many more we don’t know about
• OWE (other weird equipment)
–
–
–
–
–
28
Hyperbaric chamber
Traveling gamma camera
Pneumatic tube system
Home grown stuff
+ many more we don’t know about
Summary
• The full eco-system is broken
–
–
–
–
–
–
Systems development & architecture
Testing
Patching & updates
Maintenance
Regulation
Support and incident response
• We will be living with this problem for at least a decade
• While the vendors have a responsibility to fix their
equipment we have a responsibility to protect our patients
• The technology and knowledge are available to fix the
problem
• Being “secure” is currently not a business differentiator
• It’s only a matter of time…
29
FDA & ICS-CERT References
• Cybersecurity for Medical Devices and Hospital Networks
– http://www.fda.gov/medicaldevices/safety/alertsandnotices/ucm356423.htm
• Draft Guidance - Premarket Submissions for Management of Cybersecurity in Medical
Devices
– http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocu
ments/ucm356186.htm
•
MedWatch
– https://www.accessdata.fda.gov/scripts/medwatch/
• MAUDE – Manufacturers and User Facility Device Experience
– http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/Search.cfm
•
New MDS2 for review of medical devices
– http://www.nema.org/standards/Pages/Manufacturer-Disclosure-Statement-forMedical-Device-Security.aspx
•
Industrial Control Systems Cyber Emergency Response Team
– http://ics-cert.us-cert.gov/
•
Draft Guidance for Industry & FDA
– http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/Guid
anceDocuments/UCM356190.pdf
30
Question and Answer
Kevin McDonald
Clinical Information Security
Mayo Clinic
27
31
Public Health Through
Procurement
Dale Nordenberg
MDISS
Executive Director & Co-Founder
Medical Device Innovation,
Safety and Security Consortium
32
Content
1. Defining a medical device
2. Defining and scoping a public health problem
3. Overview of medical device safety
4. Introduction to MDISS.ORG Consortium
–
Market versus regulatory driven change
5. Highlight key regulatory and standards initiatives
6. Highlight key MDISS initiatives
33
Medical Device
“A medical device is an instrument, apparatus, implement,
machine, contrivance, implant, in vitro reagent, or other similar or
related article, including a component part, or accessory which is:
• recognized in the official National Formulary, or the United
States Pharmacopoeia, or any supplement to them,
• intended for use in the diagnosis of disease or other conditions,
or in the cure, mitigation, treatment, or prevention of disease, in
man or other animals, or
• intended to affect the structure or any function of the body of
man or other animals, and which does not achieve any of it's
primary intended purposes through chemical action within or on
the body of man or other animals and which is not dependent
upon being metabolized for the achievement of any of its
primary intended purposes."
Quoted: FDA - http://www.fda.gov/aboutfda/transparency/basics/ucm211822.htm
34
Medical Device Classes
• “FDA classifies medical devices based on the risks associated
with the device. Devices are classified into one of three
categories—Class I, Class II, and Class III.
• Class I devices are deemed to be low risk and are therefore
subject to the least regulatory controls. For example, dental
floss is classified as Class I device.
• Class II devices are higher risk devices than Class I and require
greater regulatory controls to provide reasonable assurance of
the device’s safety and effectiveness. For example, condoms
are classified as Class II devices.
• Class III devices are generally the highest risk devices and are
therefore subject to the highest level of regulatory control. Class
III devices must typically be approved by FDA before they are
marketed. For example, replacement heart valves are classified
as Class III devices.”
Quoted: FDA- http://www.fda.gov/AboutFDA/Transparency/Basics/ucm194438.htm
35
Medical Device Data System (MDDS)
• “Medical Device Data Systems (MDDS) are hardware or software products
that transfer, store, convert formats, and display medical device data. An
MDDS does not modify the data or modify the display of the data, and it does
not by itself control the functions or parameters of any other medical device.
MDDS are not intended to be used for active patient monitoring.
• Examples of MDDS include:
– software that stores patient data such as blood pressure readings for
review at a later time;
– software that converts digital data generated by a pulse oximeter into a
format that can be printed; and
– software that displays a previously stored electrocardiogram for a
particular patient.
• The quality and continued reliable performance of MDDS are essential for
the safety and effectiveness of health care delivery. Inadequate quality and
design, unreliable performance, or incorrect functioning of MDDS can have a
critical impact on public health.”
Quoted: FDA
36
http://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/GeneralHospitalDevicesandSupplies/MedicalDeviceDataSystems/default.htm
Medical Device, Accessory, Component
37
Mobile Medical App
• Mobile platform: “For purposes of this guidance, “mobile
platforms” are defined as commercial off-the-shelf (COTS)
computing platforms, with or without wireless connectivity, that
are handheld in nature. Examples of these mobile platforms
include mobile computers such as smart phones, tablet
computers, or other portable computers.”
• Mobile app: “For purposes of this guidance, a mobile application
or “mobile app” is defined as a software application that can be
executed (run) on a mobile platform (i.e., a handheld commercial
off-the-shelf computing platform , with or without wireless
connectivity), or a web-based software application that is tailored
to a mobile platform but is executed on a server.”
• Mobile medical app: “For purposes of this guidance, a “mobile
medical app” is a mobile app that meets the definition of device in
section 201(h) of the Federal Food, Drug, and Cosmetic Act
(FD&C Act); and either is intended (1) to be used as an
accessory to a regulated medical device; or (2) to transform a
mobile platform into a regulated medical device.”
38
mHealth Market
• In Q1 2013, more than 27,000 mhealth apps with a
growth rate of about 500 per month
• Of these mhealth apps, only about 80 had gone
through the FDA 510(k) process at the time of the
survey.
• www.mhealthnews.com, March 2013
39
Mobile Medical Apps: Regulatory Categories
40
Basic Regulatory Requirements
• Establishment registration
• Medical device listing
• Premarket notification (510k) or premarket
approval (PMA)
• Investigational device exemption (IDE) for clinical
studies
• Quality system (QS) regulation
• Labeling requirements
• Medical device reporting (MDR)
41
FDA Recommendations
• The following FDA slides contain content quoted from:
– Safety communication, June, 2013
– Cybersecurity Guidance, Sept, 2013
42
FDA: Identified Risks
• Network-connected/configured medical devices infected or
disabled by malware;
• The presence of malware on hospital computers,
smartphones and tablets, targeting mobile devices using
wireless technology to access patient data, monitoring
systems, and implanted patient devices;
• Uncontrolled distribution of passwords, disabled
passwords, hard-coded passwords for software intended
for privileged device access (e.g., to administrative,
technical, and maintenance personnel);
• Failure to provide timely security software updates and
patches to medical devices and networks and to address
related vulnerabilities in older medical device models
(legacy devices)
43
FDA: Recommendations to Manufacturers
• Take steps to limit unauthorized device access to trusted users only,
particularly for those devices that are life-sustaining or could be directly
connected to hospital networks. Appropriate security controls may include:
user authentication, for example, user ID and password, smartcard or
biometric; strengthening password protection by avoiding hard-coded
passwords and limiting public access to passwords used for technical
device access; physical locks; card readers; and guards.
• Protect individual components from exploitation and develop strategies for
active security protection appropriate for the device’s use environment.
Such strategies should include timely deployment of routine, validated
security patches and methods to restrict software or firmware updates to
authenticated code. Note: The FDA typically does not need to review or
approve medical device software changes made solely to strengthen
cybersecurity.
• Use design approaches that maintain a device’s critical functionality, even
when security has been compromised, known as “fail-safe modes.”
• Provide methods for retention and recovery after an incident where security
has been compromised. Cybersecurity incidents are increasingly likely and
manufacturers should consider incident response plans that address the
possibility of degraded operation and efficient restoration and recovery.
44
FDA: Guidance to Manufacturers (con’t)
• Manufacturers should define and document the following
components of their cybersecurity risk analysis and
management plan as part of the risk analysis required by
21 CFR 820.30(g)2:
• Identification of assets, threats, and vulnerabilities;
• Impact assessment of the threats and vulnerabilities on
device functionality;
• Assessment of the likelihood of a threat and of a
vulnerability being exploited;
• Determination of risk levels and suitable mitigation
strategies;
• Residual risk assessment and risk acceptance criteria
45
FDA Recommendations to Health Systems
• Restricting unauthorized access to the network and networked
medical devices.
• Making certain appropriate antivirus software and firewalls are
up-to-date.
• Monitoring network activity for unauthorized use.
• Protecting individual network components through routine and
periodic evaluation, including updating security patches and
disabling all unnecessary ports and services.
• Contacting the specific device manufacturer if you think you may
have a cybersecurity problem related to a medical device. If you
are unable to determine the manufacturer or cannot contact the
manufacturer, the FDA and DHS ICS-CERT may be able to
assist in vulnerability reporting and resolution.
• Developing and evaluating strategies to maintain critical
functionality during adverse conditions
46
Public Health Perspective
• Three parameters define the importance of a public
health problem
– Breadth of exposure, e.g. incidence/prevalence
– Depth if impact, e.g. morbidity and mortality
– Preventability
47
Medical Device Exposure
• Centers for Disease Control and Prevention
(CDC) estimates annual patient encounters
–
–
–
–
35 million hospital discharges
100 million hospital outpatient visits
900 million physician office visits
Billions of prescriptions
• Most of these encounters likely include a
networked medical device
48
Medical Device Market
• Overall market estimated to be $100 - $300 billion
dollars
• Digitally enabled devices represent about $25B to
$75B or 25% of the market. An estimate in 2009
The U.S. medical devices sector includes surgical and medical instruments, orthopedic, prosthetic, and surgical
appliances and supplies; dental equipment and supplies; x-ray apparatus, tubes, related irradiation apparatus;
electrotherapy and electromedical apparatus; ophthalmic equipment; and in-vitro diagnostic substances. Annual
Survey of Manufacturers, 2006, U.S. Census Bureau, Department of Commerce
49
Medical Device Adverse Events
• Many devices can cause serious harm if they
malfunction
–
–
–
–
Linear accelerators
Infusion pumps
Defibrillators
Insulin pumps
• Difficult to identify security related malfunction as a
root cause
50
Preventable Risk
• There are many important security related
best practices and security technologies
that are available but that are not being
deployed to secure medical devices
• Opportunity exists to integrate improved
security functions in medical devices
• This renders medical device security a
preventable risk
51
Innovation Imbalance
• HIT innovation and adoption is rapid,
accelerating, and includes networked medical
devices
• HIT interoperability is accelerating
• The rate of innovation and application for ICT
security is lagging significantly behind HIT
innovation
• The gap contributes to a major public health risk
ICT – Information and Communication Technologies
52
The ‘Hand Off’
A Black Hole Where Risk Lives
Handoff strategies in settings with high consequences for failure: lessons for health
care operations
Objective. To describe strategies employed during handoffs in four settings with high
consequences for failure.
Design. Analysis of observational data for evidence of use of 21 handoff strategies.
Setting. NASA Johnson Space Center in Texas, nuclear power generation plants in
Canada, a railroad dispatch center in the United States, and an ambulance dispatch
center in Toronto.
Main measure. Evidence of 21 handoff strategies from observations and interviews.
Results. Nineteen of 21 strategies were used in at least one domain, on at least an ‘as
needed’ basis.
Conclusions. An understanding of how handoffs are conducted in settings with high
consequences for failure can jumpstart endeavors to modify handoffs to improve patient
safety.
Reference: Quoted from Int J Qual Health Care (2004) 16 (2): 125-132. doi: 10.1093/intqhc/mzh026
MDISS Consortium
53
Point of Care Risk in the Health Enterprise
Hiding Behind Every Handoff
Medical
Mobile
Devices
Technologists
Information
Technology
Clinical Informatics
Therapists
Computers
Information
Security
Nurses
Biomedical
Engineers
Medical
Devices
Physicians
Quality of
Care
Patient
Risk
Laboratorians
Data Systems
54
Enterprise Risk Industrial Control Systems
Origins of Risk: Industry Handoff Gaps
Crossing the Cultural Chasm
Build
Operate
Integrate
55
Who’s Responsible
Origins, Destinations, Directions
Manufacturers
Congress and GAO
800001
Hospitals
NIST
MDS2
FDA
MDISS Consortium
MDISS Risk
Assessment
56
Medical Device Safety
Background
Medical Device Innovation, Safety and Security
Consortium
57
Cardiac Implantable Devices: Overview
 FDA recalled 23 types of implantable products in the first half of 2010
 In 2008, approximately 350,000 pacemakers and 140,000 ICDs were
implanted in the United States, according to a forecast on the implantable
medical device market published earlier this year
–
Sanket S. Dhruva et al., Strength of Study Evidence Examined by the FDA in Premarket Approval of
CardiovascularDevices, 302 J. Am. Med. Ass'n 2679 (2009).
 Nation-wide demand for all IMDs is projected to increase 8.3 percent
annually to $48 billion by 2014 while cardiac implants in the U.S. will
increase 7.3 percent annually representing approximately $16.7 billion in
2014
–
Freedonia Group, Cardiac Implants, Rep. Buyer, Sept. 2008, http://www.reportbuyer.com/pharma
healthcare/medical devices/cardiac implants.html.
 From 1997 to 2003, approximately 400,000 to 450,000 ICDs were
implanted globally, the majority of these implants were done in the USA,
and there were at least 212 deaths attributed to failure of these ICDs
–
Robert G. Hauser & Linda Kallinen, Deaths Associated With Implantable Cardioverter Debrillator Failure and
Deactiva-tion Reported in the United States Food and Drug Administration Manufacturer and User Facility
Device Experience Database, 1 Heart Rhythm 399, t http://www.heartrhythmjournal.com/article/S15475271%2804%2900286-3/.
Medical Device Innovation, Safety and Security
Consortium
58
Medical Device Software Failures
• Between 1983 to 1997, 2,792 quality problems that
resulted in recalls of medical devices and of problems, 383
were related to device software
• Of the recalled devices, 21 percent were cardiac
• 98 percent of the software failures analyzed were
detectable by best practice quality assurance methods
– Dolores R. Wallace & D. Richard Kuhn, Failure Modes in Medical Device
Software: An Analysis of 15 Years of Recall Data, 8 Int'l J. Reliability
Quality Safety Eng'g 351 (2001), available at
http://csrc.nist.gov/groups/SNS/acts/documents/nal-rqse.pdf.
Medical Device Innovation, Safety and Security
Consortium
59
Infusion Pumps Software Failure
 Between 2005 and 2009, the FDA received approximately
56,000 infusion pump-related adverse event reports
Many of these were associated with significant morbidity and
mortality
 Software malfunction was a frequent cause for infusion pump
malfunction
 Hundreds of thousands of infusion pumps were recalled and
scores of models were implicated
 FDA is providing support to manufacturers
– Review of code submitted by manufacturers
– Collaborative development of open source safety models and
reference standards
–
White Paper: Infusion Pump Improvement Initiative April 2010, Center for Devices and Radiological Health U.S. Food and Drug Administration,
http://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/GeneralHospitalDevicesandSupplies/InfusionPumps/ucm205424.htm
Medical Device Innovation, Safety and Security
Consortium
60
Linear Accelerators Software Related
Deaths
 Therac-25 machines
– Software problems lead to 6 well known cases of death or
severe adverse events between 1985-1987 resulting in machine
recall
– Catalyzed safety concerns and resulted in initiatives to improve
safety profile of linear accelerators
• An Investigation of the Therac-25 Accidents, Nancy Leveson, IEEE
Computer, Vol. 26, No. 7, July 1993,
pp. 18-41.
 Radiation related adverse events are likely underestimated
– Many adverse events are difficult to detect because many are
initially subclinical, e.g. increased exposures leading to
malignancy
– “My suspicion is that maybe half of the accidents we don’t know
about,” said Dr. Fred A. Mettler Jr.
• Radiation Offers New Cures, and Ways to Do Harm, NY Times, January
23, 2010
Medical Device Innovation, Safety and Security
Consortium
61
Risk Reality Check - Hacking
Machines vs. People
 In 2007 and 2008, health related websites were
hacked with the intent to cause harm
– Coping with Epilepsy website
– Epilepsy Foundation website
 In both instances, computer animations were posted
that triggered migraines and seizures among visitors
with epilepsy variants associated with
photosensitivity
Hacking of ‘medical devices’ to intentionally cause harm will
occur
Medical Device Innovation, Safety and Security
Consortium
62
Silicon-Based Defects
Etiology of Carbon-Based Diseases
Implanted medical devices have enriched and extended the
lives of countless people, but device malfunctions and
software glitches have become modern `diseases' that will
continue to occur. The failure of manufacturers and the FDA
to provide the public with timely, critical information about
device performance, malfunctions, and ’fixes' enables
potentially defective devices to reach unwary consumers.”
Capitol Hill Hearing Testimony of William H. Maisel,
Director of Beth Israel Deaconess Medical Center,
May 12, 2009
Medical Device Innovation, Safety and Security
Consortium
63
Medical Device Vulnerability
Patient Safety
“These [medical device] infections have the potential to
greatly affect the world-class patient care that is
expected by our customers. In addition to
compromising data and the system, these incidents are
also extremely costly to the VA in terms of time and
money spent cleansing infected medical devices.”
Roger Baker
Assistant Secretary for Information and Technology
Department of Veterans Affairs
Medical Device Innovation, Safety and Security
Consortium
64
Medical Device Safety Act
• Controversy regarding medical device safety
• Medical devices and pharmaceuticals are treated
differently
• Medical Device Safety Act (MDSA) seeks to overturn a
2008 Supreme Court decision based on the 1976
Medical Device Act that essentially states that
manufacturers can’t be held at risk for adverse health
events due to FDA approved products
Editorial: The Medical Device Safety Act of 2009, Gregory D. Curfman, M.D., Stephen Morrissey, Ph.D., and Jeffrey M. Drazen, M.D.,
N Engl J Med 2009; 360:1550-1551, April 9, 2009
65
Medical Device Security Challenges
 The national biomedical device network remains a largely
unrecognized entity
 Multidisciplinary expertise is required to understand medical
device risks and consequently design, implement, and manage
medical devices and their associated biomedical device
networks to optimize patient safety
 Stakeholders have not yet built the multidisciplinary expertise
required to optimize medical device safety profiles along the
medical device life cycle
 Security breaches in the health care industry escalate each year
and represent an increasing patient risk as the prevalence of
networked medical devices increases
Medical Device Innovation, Safety and Security
Consortium
66
Medical Device
Security Challenges (cont.)
 Medical device security breaches can harm patients and organizations
 Medical device network dysfunction is a potential national security risk
 The security of medical devices, given that they operate as part of a
networked system, receive inadequate attention
 Limited information is reported regarding the extent of the potential
exposure, risks, and risk mitigation strategies
 Regulatory focus is often about a ‘point in time’ assessment while
networked medical devices are continuously exposed to rapidly
evolving technology risks
 Collaboration is lacking among all stakeholders in developing practical
solutions
 The engineering, informatics, and public health science to leverage
real-time data streams from networked devices is immature
Medical Device Innovation, Safety and Security
Consortium
67
Medical Device Design Issues
• Device system design is proprietary and requires professional inputs for
operation
• Patients connected to multiple devices can’t be monitored from a single
integrated platform
• Significant risks are associated with attempts to compel currently designed
devices to be interoperable
• “Neither past nor current development methods are adequate for the highconfidence design and manufacture of highly complex, interoperable medical
device software and systems (“intelligent” prosthetics, minimally invasive
surgical devices, implants, “operating room of the future”), which in years to
come will likely include nano/bio devices, bionics, or even pure
(programmable) biological systems.”
High-Confidence Medical Devices: Cyber-Physical Systems for 21st Century Health Care (Feb. 2009); by
The Networking and Information Technology Research and Development (NITRD) Program
http://www.whitehouse.gov/files/documents/cyber/NITRD%20-%20High-Confidence%20Medical%20Devices.pdf
68
Medical Device Design Issues (con’t)
• “To enable the necessary holistic cyber-physical systems
understanding, barriers must fall among the relevant disciplines:
medicine, discrete and continuous mathematics of dynamics and
control; real-time computation and communication; medical robotics;
learning; computational models and the supporting systems
engineering design, analysis, and implementation technologies; and
formal and algorithmic methods for stating, checking, and reasoning
about system properties.”
High-Confidence Medical Devices: Cyber-Physical Systems for 21st Century Health Care (Feb. 2009)
http://www.whitehouse.gov/files/documents/cyber/NITRD%20-%20High-Confidence%20Medical%20Devices.pdf
69
Key Activities Around Medical Device Security
• FDA - 2013
– FDASIA – a federal advisory committee focused on
healthcare technology safety
– Cybersecurity for medical devices guidance and safety
communication issued
• Standards and best practices
– IEC 80001
– IEC 62443 adaptation
– AAMI technical report under development for manufacturer
risk management
– MDS2 version 2.0 just released
– CIS, MDISS, and Counsel for Cybersecurity medical device
security benchmarking activity
70
Types of Standards
 Information security management system
 Defines at the highest level how an organization will conduct their
information security management
 Ensures an organization puts in place appropriate organizational
structure, policies, processes, procedures, risk management
program, incident management process
 Risk management standards
 Defines methodology for Risk Management
 Identifying threats, vulnerabilities, consequences
 Determining probability and risk
 Determining what to do with the risk once it’s identified (accept,
transfer, reduce, etc).
 Control frameworks
 Specific checkpoints to monitor people, process or capabilities in
order to control and limit risk, e.g. access Control, Backup,
Disaster Recovery, Malware Protection, etc.
71
Standards Overview
Standard
ISO/IEC 27001
Description
Type
Information Security Management Systems Information Security Management System
Target
IT Organizations
ISO/IEC 27002
The Code of Practice for Information
Security Management
Control Framework
ISO/IEC 27005
Information technology - Security
techniques — Information security risk
management
Medical devices — Application of risk
management to medical device
Application of risk management for ITnetworks incorporating medical devices
Risk Management Guide for
Information Technology Systems
Recommended Security Controls
for Federal Information Systems
and Organizations
Risk Management
Manufactures
Developers
IT Organizations
Auditors
IT Organizations
PCI-DSS
Payment Card Data Security Standard
Control Framework
IEC 62443-2-4
A Baseline Security Standard for Industrial
Automated Control Systems (IACS)
MDS
SOX
HIPAA
ISO/IEC 14971
ISO/IEC 80001:1
NIST 800-30
NIST 800-53
2
FDA Title 21 CFR 801, 803, 807, 812[1]
FDA Title 21
CFR Part 11
Risk Management
(Saftey Focused)
Risk Management
(Medical-IT / Provider)
Risk Management
Manufacturer
Control Framework
Control Framework
Lifecycle Management
Manufactures
Developers
IT Organizations
Auditors
Any organization that collects, processes or
stores credit card
information
Manufactures
Focus on Industry: Oil, Gas, Electric
Manufacture Disclosure Statement for
Medical Device Security
Device Profile and Disclosure
HealthCare Delivery Organizations (HDO)
Sarbanes–Oxley
Health Insurance Portability and
Accountability Act
Quality Systems Regulation
Regulatory Requirement
Regulatory Requirement
Manufacturers
Public Companies
HealthCare Delivery Organizations (HDO)
Regulatory Requirement
Manufacturers
Electronic Record Keeping
Regulatory Requirement
Manufacturers
HealthCare Delivery Organizations (HDO)
IT Organizations
72
ISO/IEC 80001:1
 Provider based risk management
 Focus on the responsible organization
 Incorporates updated risk management process based on the IEC/ISO
14971 safety standard
 Creates a Medical-IT Risk Manager Role
 Silo Busting effect: Works with IT, IS, Biomed Engineers, Clinical
Technology, Clinicians and manufactures and vendors
 Maintains a risk management file for all devices

Capabilities Model provides a top-level framework for
communicating security requirements and capabilities
 Defines security risk management processes to be embedded into
incident and change-release management processes
73
ISO/IEC 80001:1
Source: Quoted from ISO/IEC 80001:1 Standard
74
IEC 62443 Adaption for Healthcare
• Originally for industrial control systems and includes
best practices for vendors
• For ICS, there is certification
• MDISS has led adaptation for healthcare
• Undergoing pilot to assess adoption feasibility
• Adopting a minimal viable product approach
75
Manufacturer Disclosure Statement for
Medical Device Security
• Manufacturer Disclosure Statement for Medical Device Security
(MDS2)
• Developed by Health Information Management System Society
(HIMSS) and National Electronics Manufacturers Association
(NEMA)
• Provides a standard form to record manufacturers device
security profile
• The intent of the MDS2 is to supply healthcare providers with
important information that can assist them in assessing the
vulnerability and risks associated with electronic Protected
Health Information (ePHI) transmitted or maintained by medical
devices.
MDS2 – HIMSS/NEMA Manufacturer Disclosure Statement for Medical Device Security
http://www.nema.org/stds/hn1.cfm
76
MDISS Medical Device Risk Assessment
Platform
•
•
•
•
•
•
Operational focus for health systems
Requires multidisciplinary team
Software as a service
Aggregates information across health centers
Flexible configuration of question sets
Graphical results to share with executives to
communicate risk
• Informs procurement and legacy security tune ups
77
Our Mission
The Medical Device Innovation, Safety and Security
Consortium (MDISS) protects public health and wellbeing by advancing innovation and computing risk
management practices to ensure wide availability of
innovative and safe medical devices
Medical Device Innovation, Safety and Security
Consortium
78
Goals
• A public private partnership effectively catalyzes
the development of a safe and secure national
bio-device network
• Security risks associated with medical devices
are well understood and appreciated across the
industry
• Medical devices and associated networks are
safe and secure
Medical Device Innovation, Safety and Security
Consortium
79
Our Organization
 We are a collaborative and inclusive nonprofit
professional organization committed to advancing
quality healthcare with a focus on the safety and
security of medical devices
 As a public-private partnership, we serve providers,
payers, manufacturers, universities, government
agencies, technology companies, individuals,
patients and patient advocates
Medical Device Innovation, Safety and Security
Consortium
80
Sample Members
• VA, Kaiser, Sutter, Duke, Texas Health Resources,
HCA, etc
• Medtronic, Covidien, Intuitive Surgical, GE, etc
• Intel, TrendMicro, Symantec, McAfee, Cylance, etc
• Work closely with FDA, DHS, DOD, etc
81
Consortium Initiatives Examples
 Medical device expert network
 Collaborative medical device requirements
development
 Pre-procurement support
 Determination of scope of the security
challenges based on robust epidemiologic
methods
 Collaborative medical device security testing
 Standards, policy, guidelines, and regulatory
briefings, updates, explanation, and implications
 Education and training
Medical Device Innovation, Safety and Security
Consortium
82
Thank You
For information, please contact:
Dale Nordenberg, MD
dnordenberg@mdiss.org
---------------------------------------Acknowledgements
Significant contributions to the development and
operations of MDISS continue to be made by
representatives from numerous organizations including
Kaiser Permanente, VA/VHA, John Muir Health, DOD,
and others
Medical Device Innovation, Safety and Security
Consortium
83
Question and Answer
Dale Nordenberg
MDISS
Executive Director & Co-Founder
Medical Device Innovation, Safety
and Security Consortium
Medical Device Security
- The Time is Now
Roy Wattanasin, Information Security Officer, MITM
Medical Device Security
- The Time is Now
Roy Wattanasin
MTIM
Information Security Officer
86
Agenda
• Introduction
• Recommendations
• Resources
87
Search for Medical Device Security
• Let Me Google That For You
– http://lmgtfy.com/?q=medical+device+security
• Dick Cheney’s Defibrilator
– http://www.cnn.com/2013/10/20/us/dick-cheney-guptainterview/
88
Recommendations (1 of 2)
• Inventorying
• Raise Awareness
• Incorporate Security into Policies
• Work With Device Manufacturers
89
Recommendations (2 of 2)
• Map Data Flows
• Incorporate Disaster Recovery (DR) Procedures
• Work Together
90
Resources (1 of 2)
• Archimedes http://secure-medicine.org/
• Center for Internet Security (CIS)
https://benchmarks.cisecurity.org/about/MedicalDeviceOve
rview.cfm
• Council on Cybersecurity (CCS)
http://www.counciloncybersecurity.org/
• FDA Guidance Draft on Medical Devices
http://www.fda.gov/downloads/MedicalDevices/DeviceReg
ulationandGuidance/GuidanceDocuments/UCM356190.pdf
91
Resources (2 of 2)
• HIMSS/NEMA Manufacturer Disclosure Statement (MDS)
http://www.nema.org/Standards/Pages/ManufacturerDisclosure-Statement-for-Medical-Device-Security.aspx
• I Am The Calvary http://bit.ly/thecavalry
• National Health Information Sharing and Analysis Center
http://www.nhisac.org
• Medical Device Innovation, Safety and Security
Consortium http://www.mdiss.org
• MedSec http://www.linkedin.com/groups/MedSec-2206357
92
Question and Answer
Roy Wattanasin
MITM
Information Security Officer
Open Panel with Audience Q&A
Please feel free to use the questions
section of the GoToWebinar toolbar to
ask a question of the speakers. You may
have to click on the double arrow to
access this function.
94
Healthcare
Special Interest Group
VISION:
Establish and maintain collaborative models for information
security within healthcare organizations
MISSION:
Drive collaborative thought and knowledge-sharing for
information security leaders within healthcare organizations.
If you are interested in participating:
Contact: christineg@issa.org
Closing Remarks
Thank you to Citrix for donating this Webcast service
Online Meetings Made Easy
96
CPE Credit
• Within 24 hours of the conclusion of this webcast, you
will receive a link via email to a post Web Conference
quiz.
• After the successful completion of the quiz you will be
given an opportunity to PRINT a certificate of
attendance to use for the submission of CPE credits.
97