International Workshop on Safety & Security of (wireless) medical sensor networks

TU Delft – 21 January 2014

Wireless Connectivity of Medical Devices - Developer needs

Geoff R Duke Ceng MSaRS MSEE CSQE (ASQ)

LifeScan Scotland Limited, Beechwood Park North, Inverness, Scotland IV2 3 ED, United Kingdom www.LifeScan.comTel: +44 (0) 1463 721000 Fax: +44 (0) 1463 722000 1

LifeScan Scotland Limited, Beechwood Park North, Inverness, Scotland IV2 3 ED, United Kingdom www.LifeScan.comTel: +44 (0) 1463 721000 Fax: +44 (0) 1463 722000

Disclaimer:

This presentation has been compiled bythe author from information that is in thepublic domain and also contains originalwork produced by the authorrepresenting opinions based on his ownpersonal experiences and knowledge. Noreference exists or is implied to anycompany that the author has beenemployed by or with whom he has beenprofessionally engaged.

2

Scope

Introduction Wireless Medical Devices, Mobile Apps & Connectivity Network Security ‘State of the art’ Risk Management Wireless/Radio Frequency Issues Human Factors Threat detection, alerting and actions Development Partners – audits contracts and quality Questions Further Reading

3

Introduction Wireless mobile medical devices – implanted > therapeutics 500 Mil. smart-phone users with healthcare application by 2015

Critical patient data interchange and control over drug delivery

What is the intended use – can it kill someone?

Can or should just anyone be doing this?

4

Wireless Medical Devices ?Wide range of risks based on intended use - for example:

Central systems in hospitals - home systems sending data to HCPs

O2, Heart Rate, Respiratory, Renal, Blood Glucose, Cholesterol

Pacemakers, Defibrillators, Neuro-stimulators

Therapeutic/Advisory/Assistive software only

Information that changes patient behaviour that can cause injury

Automated drug delivery

Implantables/In-vitro/future use with roaming 3G/4G phones etc …

5

Mobile Medical Apps (MMA)

The FDA recognises of mobile apps:

Extensive variety of actual and potential functions

Rapid pace of innovation in mobile apps

Potential benefits and risks to public health

Many simple apps are used by General Medical Practitioners in UK

6

Connectivity - Examples

7

Network Security – HCP*Access to a patient’s eHealth record must be for one of the following purposes:

Access must be consistent (with the access controls set by the patient)

Necessary to lessen or prevent serious threat to an individual’s life, health or safety (and where the patient’s consent cannot be obtained)

Necessary to lessen or prevent a serious threat to public health and safety

For a patient’s nominated or authorised representative, in accordance with the patient’s access controls

For the patient, or with the patient’s consent

For purposes relating to indemnity cover for a healthcare provider. People seeking access to information must be who they claim to be!

*HCP = Health Care Professional

8

Network Security – UserThese issues should always be looked at from the perspective of the

user:

The user (patient) is only interested in carrying out the task in hand Extraneous tasks should be carried out by the system The best user interface is invisible and is only noticeable when it doesn’t

work (e.g. you only notice your tap/faucet when water doesn’t come out) Users/Patients come from a variety of different backgrounds: cultures, age,

technical ability, physical and cognitive abilities etc. User should, however, be expected to protect medical data and passwords

like they would their bank account – but probably have no concept of associating the two.

Theft/Loss/Opportunism considerations

9

Physical Security Snippets“North East Lincolnshire Council (UK) has been hit with a fine of £80,000 after losing an

unencrypted memory stick “

“Security breaches include cases of incorrect disclosure, physical loss or theft of storage devices, misuse of old documents as templates, errors in handling fax and email, sending documents to the wrong address and even papers being stolen from pubs. “

“A briefing released this week said that information security breaches in the public sector are almost always down to failures of information governance and management, rather than technology.”

“…most public sector organisations are doing well in ensuring their technical infrastructure and policies are watertight, but failing to reduce the risks around physically handling data.”

10

‘State of the art’The global technology market is full of technological buzz terms:

Cloud computing, Software-defined technologies 2G, 3G, 4G ‘Next Generation Security’

The global ‘marketing machine’ takes charge before critical thinking happens(Wow - I want that thing!)

11

Risk Mgt. Hazards and Effects Risk/Harm to patient can come about when low security

attributable to poor design and foresight compromises safety.

Safety and Security are not conflicting entities – they go hand in hand.

Examples of wireless-related hazards and effects include: Degraded, Lost, corrupted, or time-delayed transmissions Competing wireless signals or electromagnetic interference (EMI) Compromise of wireless security Misuse due to lack of or inadequate instructions for use

All the above are symptomatic of limited technical Risk Management

12

Risk Management Quote

“Risk management is a more realistic term than safety. It implies that hazards are ever-

present, that they must be identified, analyzed, evaluated and controlled or

rationally accepted.”

Jerome Lederer, director of the Flight Safety Foundation for 20 years and NASA's first director of Manned Flight Safety

13

Risk Management Quote“In flying I have learned that

carelessness and overconfidence are usually far more dangerous

than deliberately accepted risks.”

Wilbur Wright in a letter to his father, September 1900

14

Risk Management Rationale Need to consider what is required for something to fail Not a positive thinking culture and not a popular state of mind Design for reliability as per best practice e.g. MIL-STD-338 Residual risk identification and declaration Documentation of risk-based verification activities The following parties must collaborate with each other Project Managers System Engineers Test and Verification Engineers Regulatory Affairs Personnel Compliance Managers Regulatory and Compliance Associates Quality Engineering Reliability Engineering

15

Wireless/Radio – Issues Consider International Telecommunication Union (ITU)

Radiocommunication Sector (ITU-R)4 recommendations) for medical devices: Medical devices serve patients located in diverse locations that can

change Whether your device needs to have primary or secondary radio

service classification, which depends upon the wireless frequency band you choose and the resultant impact on medical device operation.

Applicable interference mitigation techniques shared RF wireless frequency band is planned.

For implantable and body-worn medical devices, tissue propagation characteristics and specific absorption rates need to be considered.

16

Human Factors Constraints Introduce human factors engineering into entire design and

development Consider device safety and usability issues Perform task and function analyses, risk analyses, prototype tests Include participants from the user population(s) [clinical studies] AAMI/ANSI HE75:2009

Managing the risk of use error Usability testing – (UI logic as well as appearance) Design controls Software Labelling (includes instructions for use etc…)

Useful Link:

http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/HumanFactors/UCM290561.pdf 17

Threat Detection, Alerting & Actions Everyone must ensure that communications have encryption enabled

to safeguard from:

Spoofer programs Sniffers Trojans Backdoors.

Individual’s computers are often targeted because of their relatively scarce security settings.

Physical and logical controls should be put into place to protect the system.

Monitoring 24/7/365 for suspicious activity and isolating quickly The most likely sources of are independent hackers with the intention

of gaining profit, current and former disgruntled employees, competitive firms, and foreign espionage agencies.

Use of cryptographic methods (SSL, 128-bit encryption)

18

It didn’t just ‘happen’

Clear documentation of Design History and RiskEngineering Community thinks in boxesTraditional IT does not like showing detailPotted history rather than archaeology for reader!

19

Conclusions Designers must know that their creations are vulnerable Risk Mgt/Safety Engineering not well understood in IT Threat detection alerts, quarantine and automatic action Devices should locked down and Data should be

encrypted Frequency Agile is more secure than fixed frequency Strict purchase controls for developers is pre-requisite Audits must have a technical & capability maturity focus

and look closely at ISOTR80002-1 as well as ISO-80001 ISO-27001 and apply IEC-62304 as best practice guidance.

20

Questions & Clarifications

21

Further Reading

22

Security Resources @Stake - http://www.atstake.com Cain & Abel – http://www.oxid.it CERT Coordination Center – http://www.cert.org Cisco Corporation – http://www.cisco.com/security Federal Bureau of Investigation - http://www.fbi.gov/hq.htm GFI Software – http://www.gfi.com Insecure.org – http://www.insecure.org Internet Security Systems - http://www.iss.net LinkSys Corporation – http://www.linksys.com McAfee Security - http://us.mcafee.com/default.asp Microsoft Corporation – http://www.microsoft.com/security Nessus – http://www.nessus.org Network Associates – http://www.nai.com SANS Institute – http://www.sans.org Security Focus – http://www.securityfocus.com Snort – http://www.snort.org Symantec Corporation – http://www.symantec.com Tenable Network Security - http://www.tenablesecurity.com U.S. Computer Emergency Readiness Team - http://www.us-cert.gov Zone Labs – http://www.zonelabs.com http://www.cryptolaw.org/

23

Bibliography MEDDEV 2.1/6 January 2012: http://ec.europa.eu/health/medical-devices/files/meddev/2_1_6_ol_en.pdf http://www.metadieta.it/software/kit-iphone http://www.snappump.com/Snap-vs-Leading-Pump http://epocrates.com/mobile http://www.metadieta.it/software/database-alimentare-e-ricette http://www.krio.me/internet-security-threats-and-protection-methods/ http://www.wired.com/threatlevel/ http://www.fda.gov/Safety/MedWatch/SafetyInformation/SafetyAlertsforHumanMedicalProducts/ http://www.emc.com/collateral/emc-perspective/h12485-taking-charge-security-hyperconnected-world.pdf https://www.gov.uk/government/publications/end-user-devices-security-guidance-google-chrome-os-26/end-user-devices-security-

guidance-google-chrome-os-26#summary-of-platform-security http://www.datacenterknowledge.com/archives/2012/12/18/software-defined-technologies-bring-the-data-centers-closer-together/ http://www.theguardian.com/technology http://www.firehost.com/secure-cloud/enterprise/ http://www.massdevice.com/news/insulin-pump-hacker-gets-federal-attention-reps-ask-gao-investigation http://www.wired.com/images_blogs/threatlevel/2012/04/Letter-to-OMB-on-Medical-Devices.pdf http://www.beaker.com/blog/index.php/2011/06/16/computer-hackers-to-target-pacemakers-insulin-pumps/ http://www.wired.com/threatlevel/2012/04/security-of-medical-devices/ http:// www.medicaldevice humanfactors.org http://www.itu.int/en/about/Pages/default.aspx http://www.itu.int/dms_pub/itu-t/oth/29/05/T29050000100002PDFE.pdf http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-131209-udi-guidance.pdf http://www.qmed.com/mpmn/article/using-risk-management-successfully-deploy-wireless-medical-devices http://www.sjm.com/corporate/media-room/media-kits/new-products/connectivity http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_048587.hcsp?dDocName=bok1_048587 http://www.goodreads.com/author/quotes/8518.Lyall_Watson https://community.ja.net/library/advisory-services/introduction-cryptographic-techniques http://www.eng.utah.edu/~nmcdonal/Tutorials/EncryptionResearchReview.pdf http://www.fda.gov/downloads/AdvisoryCommittees/CommitteesMeetingMaterials/RiskCommunicationAdvisoryCommittee/UCM202837.pdf

24

Standards and Guides AAMI/ANSI HE75:2009 ’ Human factors engineering— Design of medical devices’ IEC62304:2006 ’ Medical device software -- Software life cycle processes’ ISO/TR80002-1 :2009 ’ Medical device software -- Part 1: Guidance on the application of ISO 14971 to medical device software’ IEC 80001-1 ‘Application of risk management for it-networks incorporating medical devices – Part 1: Roles, responsibilities and activities’ ISO/IEC 27001:2005 – Information technology – Security techniques – Information security management systems – Requirements’ IEC 62366:2007 'Medical devices -- Application of usability engineering to medical devices‘ ISO 14971:2012 'Medical devices -- Application of risk management to medical devices' US FDA 21 CRF PART 820 QSR (CGMP) Subpart C – Design Controls ISO/IEC 27001:2005. Information technology - Security techniques - Information security management systems - Requirements The Health Insurance Portability and Accountability Act of 1996 (HIPAA; Pub.L. 104–191, 110 Stat. 1936, enacted August 21, 1996) http://www.fda.gov/downloads/RegulatoryInformation/Guidances/ucm126955.pdf http://www.eetasia.com/ART_8800544143_499495_NT_8af477cf.HTM http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/HumanFactors/UCM290561.pdf http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm077272.pdf AAMI TIR45:2012 ‘Technical Information Report Guidance on the use of AGILE practices in the development of medical device

software’

25

Auditing Software Suppliers Establish existence of a contractually

enforceable quality agreement Understand and assess Capability Maturity Understand Process-centricity of personnel

(Implicit knowledge of what needs to be done) Collaboration and partnering Issue Tracking and Traceability Software development process IEC62304 Mapping of plans to intentions

(Project>Product relationship) Requirements management and contract

review Software implementation (coding) Requirement testing Defect/Enhancement recording and tracking Configuration management Recalls/Complaints /requests Risk management e.g. E.g. ISO 14971 and

IEC/TR 80002-1. ITU guidelines and gnosis RF Testing Facilities

Customer service Backup/Restore Process and Disaster Recovery

plan Electronic Records Electronic Signatures Hosting Threat detection Risk Mitigation policy Engineering/Reliability knowledge and

orientation of Risk Management (Safety Eng.) Awareness of difference between project risk

and product risk. Version naming conventions Coding Standards Development and test environment validation Static Analysis tools Change Management and technical impact

assessments Outsourcing – sub-contractor purchase

controls Configurable Off The Shelf content

Critical aspects that require audit and attention in the field of medical devices:

26