Killed by code - mobile medical devices

2,110 views

Published on

There is a perfect storm of consumer electronics, mobile communications and customer need - the need to help people manage chronic disease like Parkinson, diabetes and MSA and sustain life with pacemakers and ICDs

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,110
On SlideShare
0
From Embeds
0
Number of Embeds
570
Actions
Shares
0
Downloads
34
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Killed by code - mobile medical devices

  1. 1. Mob Sec Mobile Security Conference 4/11/2010 Herzliya Danny Lieberman – Software Associates. v6
  2. 2. Agenda  Mobile medical is hot  Applications  Threat scenarios  A threat model framework for secure code  Summary
  3. 3. Mobilemedicaldevices arehot Mobile consumer electronics creates potential for life-saving applications that are cheaper and more accessible than any other alternative. The FDA is not there yet. Neither is traditional IT security. Applications Threat scenarios Countermeasures
  4. 4. Datatracking Who: Patients, care-givers, doctors What: Data acquisition Why: Controlling symptoms of chronic illness requires tracking data over long periods of time. • Glucose • Heart rate • Blood pressure • Dosage (insulin, dopamine …) • ... Platforms : Smart-phones, data & location-based services. Diabetes Parkinson/MSA Alzheimer Asthma
  5. 5. Life-sustaining Who: Patients What: Implanted devices for cardiac pacing, defibrillation, drug delivery… Why: Sustain life Platforms : Embedded devices with mobile connectivity for remote monitoring & programming. Chronic heart disease Epilepsy Diabetes Depression “…the latest technology in a full complement of patient-focused CRM products”
  6. 6. Threatscenariotemplate An attacker may exploit vulnerabilities to cause damage to assets. Security countermeasures mitigate vulnerabilities and reduce risk. Asset Vulnerability Attacker
  7. 7. Radioattackscenario Patient with ICD Clear text protocol Threat T1 – A malicious attacker may exploit a clear text protocol and instruct an ICD to deliver a shock that would cause sudden cardiac death. Vulnerability V1 – Clear text communications protocol Countermeasure C1 – Encrypt network link Countermeasure C2 – Validate messages using secure tokens. Attacker
  8. 8. Implantable CardioverterDefibrillators In 2008, approximately 350,000 pacemakers and 140,000 ICDs were implanted in the US. Forecasted to $48BN in 2014. Proof of concept attack: • Reverse-engineered commands • Intercepted vital signs, history • Reprogrammed therapy settings • DoS to deplete battery • Directed the ICD to deliver 137V shocks that would induce ventricular fibrillation in a patient. 2008 ICD vulnerability study
  9. 9. Devicedefectattackscenario Patient Life Software defects Device malfunction Threat T2 – An internal short circuit is undetected by the device control software and may be fatal. Vulnerability V2 – Software doesn’t monitor hardware malfunctions Countermeasure C3 – Notify customer service when hardware issue identified. Countermeasure C4 – Implement fail-safe function
  10. 10. FDAdevicerecalls The FDA issued 23 recalls of defective devices in H1/2010. All were “Class 1” : “reasonable probability that use of these products will cause serious adverse health consequences or death.” At least 6 recalls were probably caused by software defects.
  11. 11. Maliciouscodeattackscenario ePHI Weak or well- known passwords Software defects OS vulnerabilities Malware Threat T3 – Malicious code may be used in order to exploit multiple vulnerabilities and obtain patient information Vulnerability V3 – USB, and/or Internet access enabled Countermeasure C4 – Hardware toggle USB Countermeasure C5 – Network isolation Countermeasure C6 – Software security assessment
  12. 12. Mobileclinicalassistants Mobile imaging analysis devices used by hospital radiologists had unplanned Internet access. Over 300 devices infected by Conficker and taken out of service. Regulatory requirements mandated that the impacted hospitals would have to wait 90 days before the systems could be modified to remove the infections and vulnerabilities.
  13. 13. WhereistheFDA? The FDA has refocused regulation from patient safety to auditing manufacturers’ compliance with their own standards. If the FDA has approved a medical device, consumers cannot sue. “Riegel v. Medtronic “, 2008
  14. 14. Athreatmodelsecurityframework
  15. 15. Objectives  Assess product risk  Understand what threats count  Prioritize countermeasures.  Drive profits Audit medical device manufacturer safety/security standards.
  16. 16. Assessproductrisk
  17. 17. Understandwhatthreatscount
  18. 18. Prioritizecountermeasures Product management has 1 dollar in their pocket:  Countermeasure C1 – Encrypt network link to ICD Countermeasure C21 – Validate POST requests with secure tokens.  Countermeasure C3 – Wearable “cloaker” to ensure that only authorized programmers can interact with the device.
  19. 19. Driveprofits Transparency means more eyeballs can look at issues. More eyeballs reduces cost. More eyeballs means safer devices. Safer devices means more revenue. Medical device threat models are transparent.
  20. 20. Sources  Riegel v. Medtronic, Inc. http://www.law.cornell.edu/supct/html/06-179.ZS.html  Pacemakers and implantable cardiac defibrillators: Software radio attacks and zero-power defenses. Daniel Halperin et al. Proceedings of the 29th Annual IEEE Symposium on Security and Privacy, May 2008. http://www.secure-medicine.org/icd-study/icd-study.pdf  Software transparency in imbedded medical devices http://www.softwarefreedom.org/resources/2010/transparent-medical- devices.html  Prof. Nir Giladi,Tel Aviv Souraski Hospital Neurology Department, personal communication on data tracking for MSA patients  Biotronik – cellular pacemaker, http://www.biotronik.com/en/us/19412

×