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. 2.

    What Healthcare Can Learn from Interesting Directions in IoT Security

    ZACH LANIER Director of Research (a.k.a IDIoTS)
  2. 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)
  3. 5.

    Agenda • Challenges Faced • Some “Lessons” • Field Innovations

    (?) in IoT Security • Solutions “we” would like to see • Case Studies / Predictions • Q&A
  4. 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
  5. 7.

    The Internet of Things “Line of Insanity”TM Sane Reasonable Insane

    Questionable Egg Tray IP Camera Door Lock Door Bell
  6. 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”
  7. 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
  8. 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?
  9. 13.

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

    Logic analyzer Bus Pirate UART headers Console!
  10. 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
  11. 22.

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

    on embedded webserver • Pre-auth command injection • as root
  12. 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
  13. 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
  14. 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
  15. 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
  16. 28.

    Atmel ATSHA204 • Dedicated crypto and key storage • Low

    power • Additional physical imposition/ footprint • Increased expense • Additional technical debt • Deprecation • Additional software programming considerations
  17. 32.

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

    w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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.
  26. 47.

    Predictions • Malware targeting IoT • Ransomware • Lock user

    out of device • Siphon data • Physical damage
  27. 48.

    Predictions • Malware targeting IoT • Ransomware • Lock user

    out of device • Siphon data • Physical damage • e.g. overheat device
  28. 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
  29. 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?