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.

1. Securing IoT
Medical Devices
John Bailey
Co-Founder and Chief Maker
DevMode

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.

3. Disclaimer
We have NDAs.
We’ll discuss general patterns based on publicly available information.

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.

11. What’s at stake?
In short, people's lives…

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

19. DIY Device Mods

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

28. IoT Connection Strategies

29. Other Systems In Play
Things get pretty wild!

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.

43. Survey SAYS....

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

50. Conclusions
Connected devices are a reality.
Security is a must.
Smart patterns exist.
Hire a pro.

51. Thank You.
John Bailey
DevMode.com
john@devmode.com

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