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.
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)
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
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!
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
http://www.bbc.com/news/technology-40042584
Pacemakers, insulin pumps and other devices in hospitals harbour security problems that leave them vulnerable to attack, two separate studies warn.
One study solely on pacemakers found more than 8,000 known vulnerabilities in code inside the cardiac devices.
The other study of the broader device market found only 17% of manufacturers had taken steps to secure gadgets.
The reports come soon after more than 60 health organisations in the UK fell victim to a cyber-attack.
Bugs in code, lack of knowledge about how to write secure code and time pressures made many devices vulnerable to attack, suggested the study.
Environment 20 years ago: no network, just serial connections (still the case in many labs)
The old protocols are still used. Just the communication medium has changed. Who needs checksums on the application layer when TCP is used?
Security requirements often contradict with Safety, Reliability, and Usability Requirements
Security vs. Reliability
Anti-Malware: Is AV on a medical device a good idea?
What if pattern updates have an impact on the reliability?
What if the AV software blocks essential system functions?
Security vs. Usability
Passwords are bad, because nobody can remember secure 16 character passwords
Fingerprint reader -> gloves
Iris scanner -> glasses
Tap'n'go
Security vs. Safety
How secure can you make a Medical Device?
Locked device after 3x wrong password kills patients
Should respiratory equipment go to sleep after 30 minutes?
Do we really need that feature?? (e.g. Remote Upgrade of Cardiac implants)
100% security not reachable
Safety is more important, but Security risk -> safety risk
Abbott warning letter
Hardcoded credential
A device manufacturer receives a user complaint that a gas blood analyzer has been
infected with malware and there was concern that the malware may alter the data on the
device. The outcome of a manufacturer investigation and impact assessment confirms the
presence of malware and finds that the malware does not result in the manipulation of
unencrypted data stored and flowing through the device. The device’s safety and essential
performance is not impacted by the malware and the manufacturer’s risk assessment
determines that the risk of patient harm due to the vulnerability is controlled. The device
manufacturer communicates to users on how to remove the malware and decides to
develop a defense-in-depth strategy; these changes would be considered a cybersecurity
routine update and patch, a type of device enhancement.
Awareness is key. In a connected world, attacks are much more likely than ever before.
Microsoft Security Development Lifecycle is a good start. It fits in most existing development processes and introduces only minor changes.
Security must be designed into products. It can’t be added on top of a finished product.
Education is the essential part. Engineers and developers need to know how to build secure products. It is not sufficient to have a security expert who does the security testing.
A standard set of security requirements that all products must meet is very important. Specific requirements can be added per product type or per product.These requirements must be verified in security testing activities. On the source level Code Reviews and Static Code Analysis is the minimum.Fuzzing and penetration testing should also be part of the testing activities.
There are new attacks and vulnerabilities every day. Products that have already been commercialized have to be assessed for new risks regularly.
Provide a central contact for incident and vulnerability notifications. Respond to and handle those notifications in a timely manner.
Finally, patch or provide patches for your products. This is not easy because every change to a product has to be verified and validated. Lots of documentation is required to do changes to already registered and released products.
People are taught to code like 1970 in the first place and then after years someone tells them how to do it right
Use of unsafe functions
Blindly trust the user
Use of unsanitized user input in SQL queries or system calls