This document provides an introduction to medical device security. It defines medical devices and provides examples. Intended use determines if a device is regulated. Software can be a medical device. Regulations and standards like IEC 62443 govern security. Old devices increase interconnectivity and associated risks. Security goals are confidentiality, integrity and availability to prevent patient harm. Common vulnerabilities include unpatched systems and weak credentials. Risk assessments must consider safety impacts. Manufacturers must integrate security into development and handle incidents and vulnerabilities.

1. Introduction to
Medical Device Security
Daniel Heppner

2. MEDICAL DEVICES

3. Medical Devices
“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 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.”
Source: https://www.fda.gov/aboutfda/transparency/basics/ucm211822.htm

4. Examples
• Implantable medical devices
– Pulse generator (pacemaker)
• In Vitro Diagnostics devices
– Blood coagulation analyzer
• Diagnostic Imaging systems
– Computed tomography
• …
• When is a device a medical device?
• Can medical devices be software-only?

5. Intended Use
• When is a device a medical device?
 Depends on the intended use!
• The intended use is not what the device is
designed to be used for or what the device
could be used for.
• It is just what’s on the label – what the device
is meant to be used for.

6. Software as a Medical Device (SaMD)
• Can medical devices be software-only?  YES!
• When is your app considered medical device software?
– When it meets the definition of a medical device.
– When it is used specifically for diagnostic and/or
therapeutic purposes.
– When it has a medical purpose.
• Depends on the intended use
– Example: menstrual cycle (period) tracking vs.
contraception (prevention of pregnancy)

7. DIRECTIVES, REGULATIONS,
STANDARDS

8. Directives and Regulations
• A regulation is a binding legislative act
• A directive is a legislative act that sets out a goal that must
be achieved somehow
– European Union
• Medical Devices Directive (MDD)
• In Vitro Diagnostics Directive (IVDD)
• In the healthcare industry everything is regulated by
governments, which is good and bad
• Different regulations apply in different countries
• Implement a set of standards to meet the regulatory
requirements

9. Standards
• The good thing about standards is that there
are so many of them :)
• IEC 62443 is one of the more important
cybersecurity standards for industrial IT
security
• FDA releases guidelines (recommendations,
not standards) to help implementing security

10. MEDICAL DEVICE CYBERSECURITY

12. Old World Meets the New World
• Increase in interconnectivity between medical
devices and other clinical systems
• Increasing concern that the connectivity of
these medical devices will directly affect
patient safety

13. Security Goals
• Confidentiality
– Protection of personal and sensitive data
– Patient data gets stolen and/or disclosed: Mostly financial impact or
loss of reputation for companies.
– High impact for the patients, for example: App for Hemophilia on an
App Store
• Such a patient costs about 15.000.000€ per year
• Company that owns the store platform has your health data and is allowed to
process all user data
• What happens if the fact that you suffer from that disease is disclosed?
– Example: What if your next employer already knows that you have
unusually high blood pressure and you may not be that resilient?

14. Security Goals
• Integrity
– Patient/personal data and measurement and
diagnosis results need to be protected from tampering
– Indirect safety risk: False results can lead to incorrect
treatment or wrong decisions
– Direct safety risk: Patients could be harmed by the
device (e.g. movement of mechanical components, X-
Ray overdose, malfunction of life-sustaining functions)
– Both direct and indirect safety risks could potentially
lead to patient harm or even death

15. Security Goals
• Availability
– ​Device is not accessible: results not available or no
measurement possible
– Device not working: Patient death if device is life-
sustaining
• Impact on Integrity and Availability can directly
lead to patient harm (Safety Risk)
• Confidentiality “only” impacts personal life

16. Priorities
1. Safety
2. Reliability
3. Usability
4. Security
• These priorities can not and will not change in the future.
• It is way more important that the device is safe than that it
is secure. It is acceptable to implement safety risk control
measures that decrease the overall level security, if the
newly introduced security risk is assessed.
• Most security vulnerabilities also introduce safety risks.

17. Risk Assessments
• How can we determine the actual risk of a vulnerability in a
medical device?
• Industry has been performing safety risk assessments for decades,
but the current methods do not work for security risks.
• Vulnerability scoring (e.g. CVSS) does not work well either, because
it leaves out potential safety risks. It also assigns C, I and A equal
scores, which is not correct.
• New hybrid methods have to be developed!

18. Common Vulnerabilities

19. Common Vulnerabilities
• ​Unpatched operating systems
• Firewall disabled
• Hardcoded credentials
• Weak default credentials
• Insecure user management
• Insecure protocols (FTP, VNC, …)
• Insecure WCF endpoints
• Software runs with high privileges

20. Legacy Systems
• How to deal with legacy systems that have been
in use for more than 20 years?
• Those devices are usually not upgradable to
modern software versions, because of
unsupported hardware.
• Hardware upgrades are expensive. Who pays for
that?
• Imagine IoT would have been around for about
20 years

21. Recent Events
• Vulnerabilities in Miele disinfection machines
– Vulnerabilities were reported but Miele apparently did not
know how to handle notifications, which resulted in full
disclosure. Now they are hiring security professionals :)
• Abbott Warning Letter
– First time ever the FDA published a warning letter complaining
about security vulnerabilities
• WannaCry Ransomware
– Kept medical device manufacturers (including myself) very busy
during the last weeks

22. Next Actions
• Medical device manufacturers must…
– understand that security risks are potential safety risks.
– integrate secure development activities into their
development processes.
– design security into the product.
– educate their engineers and service personnel.
– do security testing.
– review the security concept regularly.
– handle incidents and vulnerabilities.
– patch all the things!

23. How to Fix the Insecure World?
• Don’t teach people how to write code – teach
them how to write secure code
• Teach secure development practices in schools
and at universities
• Educate people by doing security awareness
trainings and campaigns
• Clean up the internetz from tutorials that
contain security vulnerabilities

24. References
• https://www.fda.gov/aboutfda/transparency/basics/ucm211822.htm
• http://www.mddionline.com/blog/devicetalk/why-you-must-know-difference-between-intended-
use-and-indications-use-04-25-17
• https://en.wikipedia.org/wiki/Medical_software
• https://www.whitecase.com/publications/article/mobile-health-apps-are-they-regulated-medical-
device
• https://en.wikipedia.org/wiki/Cyber_security_standards
• https://www.fda.gov/iceci/enforcementactions/warningletters/2017/ucm552687.htm
• https://www.wired.com/2017/03/medical-devices-next-security-nightmare/
• https://www.microsoft.com/en-us/SDL
• https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocument
s/ucm482022.pdf
• http://www.himss.org/file/1317711/download?token=pCH3RABX
• https://www.heise.de/newsticker/meldung/Miele-verspricht-Sicherheits-Update-fuer-
Desinfektionsautomaten-3669611.html