The document provides an overview of securing medical devices. It begins by outlining the objectives of understanding current device security, vulnerabilities, and considerations for securing systems. It then discusses what constitutes a medical device and why connectivity is important but introduces risks. Several risk scenarios are described, such as device hacking, data breaches, and DIY modifications. Specific examples of insulin pump and pacemaker hacks are given. The document then provides strategies for improving security, including identifying risks, using strong identities and cryptography, monitoring for issues, and securing various aspects of systems from the hardware to communications to applications. It acknowledges barriers to security but emphasizes doing as much as possible and understanding what is at stake.
2. Objectives
That this session is most informative 45 minutes since lunch today.
That attendees walk away:
● understanding the current state of medical device security (how we got here)
● knowing the key points of vulnerability in a medical device system
● with a punch-list of considerations and decision points for securing a
medical device system
And maybe to scare you a little. Then make you feel a bit better.
4. What do we mean by medical device?
Something that detects, treats or cures a
medical condition.
● Fitness and general health monitoring
● Clinic/hospital equipment
● Therapy monitoring and administration
We’re focused on medically-critical portable
monitors, therapy, and implantable devices.
5. What do we mean by medical device?
● The physical device
● Data systems/services that receive, transmit, or store device related data
● Secondary devices used for programming the physical device
● Mobile and web applications used to display or manipulate device data
6. Pop Quiz - What's the most effective strategy for
keeping a medical device secure?
Don’t connect it.
Good luck with that!
7. Why connect devices?
● Improve patient outcomes
● Upgrade products using same hardware
● Resolve issues with firmware/software
● Reduce recall costs
● Answer FDA concerns
● Business process improvement
8. Why connect devices?
It may not be optional any longer.
...
The FDA wants medical devices to have mandatory monitoring and built-in
update mechanisms.
FDA Guidance Changes
FDA Medical Device Safety Action Plan
9. Who benefits?
● Manufacturers - Upgrade products using same hardware,
Reduce recall costs, Answer FDA concerns, Business process
improvement
● Patients - Improve patient outcomes
● Clinicians - Improve patient outcomes
● Insurers - Business process improvement
10. Who is at risk?
Patients take on the majority of the risk.
12. What are some risk scenarios?
● Device hacking
● Personal data breaches
● DIY Device Mods
13. How real are these concerns?
They’re real, but don’t take my word for it.
14. Medical Device Hacks - Pacemaker
In 2008 an IEEE paper outlined a wireless vulnerability with implantable
cardioverter defibrillator (ICD).
● Unencrypted wireless communication
● Reverse engineered command protocol
● Intercepted patient data
● Capable of disrupting heart function
IEEE Pacemaker hack story
Dick Cheney Terrorist Threat
15. Medical Device Hacks - Insulin Pump
In October 2016, Johnson & Johnson went public warning their patients of a
potential health risk caused by a cyber security vulnerability.
● First manufacturer disclosure of this type
● Unencrypted wireless communication
● Potential for creating insulin overdose
● Access to patient data
● Similar vulnerabilities discovered in other big players
J & J Insulin Pump Vulnerability
16. Barnaby Jack
Renowned hacker among industry experts for his influence in the medical and
financial security fields.
● Demonstrated hacking an insulin pump from a distance of up to 90 metres
using the high-gain antenna
● Demonstrated the ability to assassinate a victim
by hacking their pacemaker.
● Developed software that allowed him to remotely
send an electric shock to pacemakers within
a 50-foot radius
17. Data Privacy Breaches
● Majority come from healthcare providers
○ In 2017, 477 healthcare breaches reported to (HHS)
○ Affected over 5 million patient records
● Hacking has become the predominant cause of major breaches
● Connected devices create a new vector for data
hacking
18. DIY Device Mods
Dana Lewis hacked into her Continuous Glucose Monitor and collected data
which was in turn used to directly control her insulin pump.
● Creating an artificial pancreas
● Utilized unprotected data transmissions
● Developed a closed-loop therapy not approved by
the FDA at the time
● Created #OpenAPS and #DIYPS
Making an Artificial Pancreas
20. DIY Device Mods
Just a few weeks ago the vulnerability in the Nintendo Switch’s Tegra X1
bootROM. I know, I know, this is not a medical device, but it illustrates an
interesting problem.
● Vulnerability in the hardware layer itself
● Likely unresolvable via software or firmware updates
● Imagine what the FDA’s response to a similar issue
in a connected medical device….
Nintendo Switch Exploit
21. FDA Guidance Arrived Late
“There's a fairly significant fleet of devices that have back-door vulnerabilities
built in”
“As we learn more, we want to incrementally raise the expectations for the
security of devices”
“It is important to us that manufacturers build security and develop a program
through the lifetime of the device for maintenance”
Modern Healthcare, January 2018
22. So where can we go from here?
1. Identify the specific risks for a given system
23. So where can we go from here?
1. Identify the specific risks for a given system
2. Everything needs an identity (devices, servers, software, people)
24. So where can we go from here?
1. Identify the specific risks for a given system
2. Everything needs an identity (devices, servers, software, people)
3. Expose the minimum data/control
25. So where can we go from here?
1. Identify the specific risks for a given system
2. Everything needs an identity (devices, servers, software, people)
3. Expose the minimum data/control
4. Leverage modern cryptography
26. So where can we go from here?
1. Identify the specific risks for a given system
2. Everything needs an identity (devices, servers, software, people)
3. Expose the minimum data/control
4. Leverage modern cryptography
5. Verify firmware/software authenticity
27. So where can we go from here?
1. Identify the specific risks for a given system
2. Everything needs an identity (devices, servers, software, people)
3. Expose the minimum data/control
4. Leverage modern cryptography
5. Verify firmware/software authenticity
6. Monitor, track and react
30. Points of Vulnerability
● Physical device
● Communication
● Data at rest
● Firmware/software exploits
● Web or mobile applications
● Humans!
31. How do we start eliminating all this risk?
Start with a solid foundation based on modern security patterns.
32. Public Key Infrastructure
● The foundation of a secure architecture
● Utilize strong cryptography - long keys
● All systems own and never share their keys
● Protect the certificate authorities
● Have a plan for certificate life-cycles - keep ‘em short
● Leverage certificate expiration and revocation practices
● Key up-to-date on cipher suites and key algorithms
33. Identity, Identity, Identity
● Everything in your platform needs an identity
● Leverage cryptographic identities for devices and infrastructure
● Establish trust between parties within your system
● Control access inter-system access
● Create a data chain of custody
● Detect bad actors and isolate or eliminate access
34. Securing the Hardware
● Utilize a hardware based security modules / coprocessor (HSM, TPM)
● Trusted Execution Environments
● Digitally sign and encrypt the firmware/software
● Validate firmware/software on boot (Secure Boot)
● Protect data storage
● Tamper protection
● Disable JTAG or similar programming interfaces (remove, blow fuse, etc)
35. Securing Wireless - Bluetooth
● Never operated with plain text data packets
● BLE 4.2 if possible - allows strong encryption and key exchange (ECDH)
● Use secure connections
● Use the strongest possible pairing method the hardware supports to avoid
MITM attacks - Out of Band, Numeric Comparison - Something called “Just
Works” probably isn’t gonna cut it.
● Consider additional encryption at the software and/or firmware layer
36. Communication - Wired/Cellular/WIFI
(MQTT, AMQP, HTTP, etc)
● Never operate with plain text data packets
● Use TLS 1.2 or greater on all connections
● Consider Mutual TLS (mTLS) where possible
● Consider VPN Tunnelling for low powered embedded systems
● Secure your networks
37. Code Signing
● Developer utilizes certificate from a code signing authority
● Signing firmware/software
○ Generate one way hash of binaries
○ Encrypt hash with code signing identity private key
● Distribute binaries with certificate and hash
● Verification process
○ Decrypt provided hash
○ Generate one way hash of binaries
○ Compare decrypted and generate hashes
38. Firmware/Software Updates
● Periodically update firmware/software
● Resolve defects and/or security flaws
● Provide a secure mechanism to transfer firmware/software to device
● Leverage a secure boot mechanism to establish binary trust
● Provide a “no brick” mechanism to update
39. Data at Rest
● Sensitive data should be encrypted at rest
- Required for HIPAA compliance
● Prefer higher-layer encryption if possible
● Applies to all aspects of the architecture
40. Securing Mobile and Web Applications
● Use modern authentication solutions such as OAuth or OpenID
● Keep session lengths short
● Leverage biometric security
● Consider multi-factor authentication
● Critically consider which data to show
● Proxy devices and their software require extra care
Do you pass the phone-left-at-the-coffeeshop test?
41. Device Management
● Take inventory of devices
● Monitor usage and traffic patterns
● Manage firmware/software versions
● Use the data collected to detect and diagnose potential security problems
42. Whoa! - Do I need ALL of this?
It is not possible to do everything perfect, and you aren’t alone.
44. What’s in your way?
● Operational needs
● Budget
● Hardware
● User Experience
45. What’s in your way?
“We have to get to market and we don’t have time for all these
security changes.”
46. What’s in your way?
“These extra security modules won’t fit in our per-unit budget.”
47. What’s in your way?
“Our wireless module only supports BLE 4.0 and can’t sacrifice
battery life for extra encryption.”
48. What’s in your way?
“We can’t require our users to do some complex pairing process.”
49. Game Plan
1. Understand your specific risks
2. Evaluate the strategies and patterns that best apply within your constraints
3. Do as much as you possibly can
4. Never forget what’s at stake
52. Blockchain? - because we know someone will ask
If a public distributed ledger makes sense to secure your identities and audit your
devices, then… maybe.
● Identities
● Audit trails
● Access management