What Healthcare Can Learn From Interesting Directions in IoT Security

What Healthcare Can Learn From Interesting Directions in IoT Security

Short presentation given at Archimedes Workshop on Medical Device Security 2016

C65347082fd2c5ec7c783f214e2d49e0?s=128

Zach Lanier

May 16, 2016
Tweet

Transcript

  1. What Healthcare Can Learn from Interesting Directions in IoT Security

    ZACH LANIER Director of Research
  2. What Healthcare Can Learn from Interesting Directions in IoT Security

    ZACH LANIER Director of Research (a.k.a IDIoTS)
  3. About This Talk

  4. Who is this clown? • Zach Lanier • Director of

    Research, Cylance • Old net, web/app, mobile/ embedded security research/ pen test type • Previously at Accuvant Labs and Duo Security • Co-author, "Android Hacker's Handbook" (Wiley, April 2014)
  5. Agenda • Challenges Faced • Some “Lessons” • Field Innovations

    (?) in IoT Security • Solutions “we” would like to see • Case Studies / Predictions • Q&A
  6. About the Internet of Things • “The Internet of Things

    is the network of physical objects that contain embedded technology to communicate and sense or interact with their internal states or the external environment.” (Gartner IT Glossary) • “Machine to machine (M2M) refers to technologies that allow both wireless and wired systems to communicate with other devices of the same type.”
 • IoT Growth Estimates • Gartner: 26 billion units by 2020 • ABI Research: 30 billion units by 2020
  7. The Internet of Things “Line of Insanity”TM Sane Reasonable Insane

    Questionable Egg Tray IP Camera Door Lock Door Bell
  8. Challenges

  9. Challenges: “Process” • Verification of healthcare professionals' credentials • (i.e.

    "are you actually a doctor?") • Rights / privileges (technical) should be predicated on these credentials, such as "STOP HEART COMMAND”
  10. Challenges: “Technology” • Hardware • Ensuring integrity / trustworthiness of

    code (limited execution environment / power consumption / clock speed) • Flashing devices • Can be convoluted process • Emergency situations => need immediate access • Backend/software challenges • Security of supporting infrastructure • Web services • Communications channels
  11. Challenges: “User Awareness/Behavior” • Users may not know how to

    update device firmware or apps • If that’s even a capability • Disparity in management: web console v. mobile app v. physical “update” button • Lack of feedback or notification for updates or errors • How does a user know their IoT or medical device was updated or, worse, compromised?
  12. Examples / Lessons

  13. Example: Basic Hardware Security + = + Least common denominator:

    Logic analyzer Bus Pirate UART headers Console!
  14. Example: Home Automation Gateway Magical cloud service/site M ZigBee ZigBee

    ZigBee HTTPS HTTPS HTTPS Mobile app Web browser "Gateway" Lights Pool pump Automated cat entertainment toy XSS, CSRF, auth bugs, etc. Key extraction, replay, injection, etc. Unfettered console access, no priv sep for services, same "support" creds on multiple devices
  15. Example: Hardcoded Passwords

  16. Example: Hardcoded Passwords Don’t.

  17. Example: Hardcoded Passwords Don’t. Just…don’t.

  18. Example: Hardcoded Passwords Don’t. Just…don’t. Example from an IP camera’s


    mobile app:
  19. Example: IP Camera

  20. Example: “Media” Controller IoT/embedded device • Undocumented network diagnostics script

    on embedded webserver
  21. Example: “Media” Controller IoT/embedded device • Undocumented network diagnostics script

    on embedded webserver • Pre-auth command injection
  22. Example: “Media” Controller IoT/embedded device • Undocumented network diagnostics script

    on embedded webserver • Pre-auth command injection • as root
  23. Example: “Media” Controller IoT/embedded device • Undocumented network diagnostics script

    on embedded webserver • Pre-auth command injection • as root FOO_COMMAND=%2Fsbin%2Fiwpriv+ra0+set+FOO %3DFOOSTART%3B%2Fsbin%2Fiwpriv+ra0+set+FOOTXLEN %3D24%3B%2Fsbin%2Fiwpriv+ra0+set+FOO%3DTXCONT %3B&FOOCHANNEL=&FOOTXLEN=24&FOOTXCNT=&FOOTXM ODE=&FOOTXBW=&FOOTXGI=&FOOTXMCS=&FOOTXANT=&F OORXANT=&FOORXFER=&ResetCounter=&FOOAUTOALC=&FO OIPG=&FOOPAYLOAD=&FOO=TXCONT
  24. Example: “Media” Controller IoT/embedded device • Undocumented network diagnostics script

    on embedded webserver • Pre-auth command injection • as root FOO_COMMAND=%2Fsbin%2Fiwpriv+ra0+set+FOO %3DFOOSTART%3B%2Fsbin%2Fiwpriv+ra0+set+FOOTXLEN %3D24%3B%2Fsbin%2Fiwpriv+ra0+set+FOO%3DTXCONT %3B&FOOCHANNEL=&FOOTXLEN=24&FOOTXCNT=&FOOTXM ODE=&FOOTXBW=&FOOTXGI=&FOOTXMCS=&FOOTXANT=&F OORXANT=&FOORXFER=&ResetCounter=&FOOAUTOALC=&FO OIPG=&FOOPAYLOAD=&FOO=TXCONT
  25. Field Innovations (?) in IoT (Security?)

  26. Electric Imp • Easy build and deployment environment • Provides

    cloud service for messaging, fleet management/tracking, etc. • Simple-but-robust libraries • Comms, security, I/O, etc. • Very tight (minimal, no superfluous functionality) firmware and execution environment • Production hardware is near-if-not- completely impossible to instrument/ debug (e.g. JTAG / ICE) • Tied to Imp Cloud for (most) services
  27. Particle • Easy build and deployment environment • Provides cloud

    service for messaging, fleet management/ tracking, etc. • Simple-but-robust libraries • Comms, security, I/O, etc. • Tied to Particle Cloud for deployment and management • Easy hardware debugging • i.e. dump firmware
  28. Atmel ATSHA204 • Dedicated crypto and key storage • Low

    power • Additional physical imposition/ footprint • Increased expense • Additional technical debt • Deprecation • Additional software programming considerations
  29. Solutions We Would Like To See

  30. Solutions We Would Like To See

  31. Solutions We Would Like To See • On-board crypto co-processors

    w/strong algorithms/ciphersuites
  32. Solutions We Would Like To See • On-board crypto co-processors

    w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms
  33. Solutions We Would Like To See • On-board crypto co-processors

    w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification
  34. Solutions We Would Like To See • On-board crypto co-processors

    w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification • Innovations in communications to address lack of connectivity
  35. Solutions We Would Like To See • On-board crypto co-processors

    w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification • Innovations in communications to address lack of connectivity • Ready-made frameworks for medical/healthcare security
  36. Solutions We Would Like To See • On-board crypto co-processors

    w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification • Innovations in communications to address lack of connectivity • Ready-made frameworks for medical/healthcare security • Communications
  37. Solutions We Would Like To See • On-board crypto co-processors

    w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification • Innovations in communications to address lack of connectivity • Ready-made frameworks for medical/healthcare security • Communications • Backend services
  38. Solutions We Would Like To See • On-board crypto co-processors

    w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification • Innovations in communications to address lack of connectivity • Ready-made frameworks for medical/healthcare security • Communications • Backend services • Auditing / Accounting
  39. Solutions We Would Like To See • On-board crypto co-processors

    w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification • Innovations in communications to address lack of connectivity • Ready-made frameworks for medical/healthcare security • Communications • Backend services • Auditing / Accounting • Access Control / AuthZ / AuthC
  40. Solutions We Would Like To See • On-board crypto co-processors

    w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification • Innovations in communications to address lack of connectivity • Ready-made frameworks for medical/healthcare security • Communications • Backend services • Auditing / Accounting • Access Control / AuthZ / AuthC • etc.
  41. Predictions

  42. Predictions

  43. Predictions • Malware targeting IoT

  44. Predictions • Malware targeting IoT • Ransomware

  45. Predictions • Malware targeting IoT • Ransomware • Lock user

    out of device
  46. Predictions • Malware targeting IoT • Ransomware • Lock user

    out of device • Siphon data
  47. Predictions • Malware targeting IoT • Ransomware • Lock user

    out of device • Siphon data • Physical damage
  48. Predictions • Malware targeting IoT • Ransomware • Lock user

    out of device • Siphon data • Physical damage • e.g. overheat device
  49. Predictions • Malware targeting IoT • Ransomware • Lock user

    out of device • Siphon data • Physical damage • e.g. overheat device • Attacks against IoT as vector into enterprise/org
  50. Predictions • Malware targeting IoT • Ransomware • Lock user

    out of device • Siphon data • Physical damage • e.g. overheat device • Attacks against IoT as vector into enterprise/org • Mobile aside, how many connected/IoT devices are people bringing day-in-day-out?
  51. QUESTIONS AND ANSWERS