Integration Roundup- Standards and Safety

Transcription

1 Integration Roundup- Standards and Safety Erin Sparnon, MEng Engineering Manager (610) , ext ECRI Institute

2 Today s Agenda Using Standards to achieve Integration (20 min) Tales from the Field- stories of integration safety (10 min) Medical Device Security (10 min) Q and A 2010 ECRI Institute

3 About your Speakers Erin Sparnon, ECRI Institute Axel Wirth, Symantec 2010 ECRI Institute

4 What is IHE? Integrating the Healthcare Enterprise (IHE) is an International Standards Profiling Organization Vision: To enable seamless and secure access to information whenever and wherever it is needed Mission: To improve healthcare by providing specifications, tools and services for interoperability

5 IHE Enables Interoperability by: Developing consensus-based, open source Technical Frameworks (specifications) and Integration Profiles, and making them available in the public domain Coordinating the use of established standards, such as CDA or FHIR (HL7), DICOM (within IHE Radiology and Pathology Profiles), LOINC & CDISC (for Laboratory Orders and Reporting), or IEEE x (for mhealth, Medical and Personal Health Devices) to address clinical needs, in support of optimal, organized, and safe patient care Facilitating product conformance testing to elicit feedback and demonstrate adherence of products to IHE specifications Systems developed in accordance with IHE communicate with one another better, are easier to implement, and enable care providers to use information more effectively

6 Where does IHE fit in the HIT Standards ecosystem? Standards Development Organizations Standards, Content, Messages, Architectures (e.g., HL7 2.x messaging, 3.x transport, FHIR, C-CDA, DICOM) Framework/Profiling Organizations Building Blocks/Architectures Into Assemblies that Solve Specific Interoperability Needs (e.g., IHE PIX, PDQ, XDS, DEC) Projects All of the above combined into functional interoperability solutions constrained to meet the needs of a country or health system or other related need

7 The impact and goal of IHE since 1997! Develop, demonstrate, and disseminate trusted, workflow-driven, standardsbased interoperability solutions freely available in IHE Technical Frameworks and Integration Profiles IHE uses a globally trusted open ballot process for review IHE specifications are vetted through the international ISO process Download all specification documents free Removed barriers to creating seamless and secure access to and exchange of - health data Reduces costs by eliminating or reducing the need for proprietary interfaces between systems

8 IHE International is a 501(c)(3) independent non-profit organization IHE International Elected Co-Chairs: David Mendelson, MD Elliot Sloane, PhD IHE International Board is fairly large, with broad representation - One member from each Global Development Domain - One member from each National Deployment Committee - Two At-Large members from the above communities - Two Emeritus members from prior Board membership > 21 Societies Serving as Sponsors Over 650 Contributing Vendors & Organizations

9 Finland Israel Poland UNDER WAY Belgium India Switzerland Malaysia New Zealand Saudi Arabia Colombia Brazil South Africa

10 IHE USA Participation in the IHE International Cycle Putting the D in Deployment Proposal, Development, Validation, Certification, Deployment Implement/ Extension Testing and Certification Implement/ Roadmap Implement/ Ask IHE USA Education

11 Automated, secure data capture and exchange IHE Interoperability Domains 18 Years of Steady Evolution Worldwide! Pathology since 2006 Endoscopy since 2010 Pharmacy since 2009 Eye Care since 2006 Surgery since 2012 Dentistry since 2010 Quality Research & Public Health since 2006 Mobile devices Under way for 2015! Radiology since 1998 (Healthcare) IT Infrastructure since 2003 Patient Care Devices since 2005 Cardiology since 2004 User driven & vendor neutral; based on HL7, ICD, and similar global stds. Laboratory since 2004 Radiation Oncology since 2004 Patient Care Coordination since 2004 Now including home care devices, telehealth, and PHRs Look carefully: MOST Domains capture device AND workflow data; data 11 transfer is accurate and near-immediate.

12 Profiles of Interest- Consistent Time [CT] Enables system clocks and time stamps of computers in a network to be synchronized (median error less than 1 second). Example: Data from a patient s ventilator, monitor, and infusion pump all reach the EMR in a synchronized manner to allow a fuller picture of the patient s condition 2010 ECRI Institute

13 Profiles of Interest- Device Enterprise Communication [DEC] Transmits information from medical devices at the point of care to enterprise applications. Examples of information sent to EMR: A physiologic monitor sends a snippet of an ECG waveform An infusion pump server reports that a pump has gone to KVO because it has reached its volume too be infused 2010 ECRI Institute

14 Profiles of Interest- Point of Care Infusion Verification [PIV] Communicates medication orders to an infusion pump or pump server Example Nurse has come into the room and used the bedside barcode scanning system to scan and associate the patient, pumping channel, and medication bag. The enterprise system then sends the medication order to the pump server using PIV, which routes it to the appropriate pump channel ECRI Institute

15 Profiles of Interest- Alert Communication Management [ACM] Communicates alerts (alarms - physiological or technical, or advisories), ensuring the right alert with the right priority gets to the right individuals with the right content. Examples of information sent to secondary alarm notification systems or middleware: Physiologic monitor communicates an arrhythmia alarm Infusion pump server communicates an air-in-line alarm 2010 ECRI Institute

16 How can I tell if a system supports IHE profiles? Ask to see an Integration Statement for the profile you re interested in If an integration statement is unavailable, request conformance in an RFP Look for drop-in RFP language in the PCD User Guide 2010 ECRI Institute

17 Lessons from the Trenches What has ECRI heard? And what can we do? ECRI Institute

18 1. Access Point failure takes down Tele A call went in to Welch Allyn that a care area s guest-services wireless network was down. A switch in their Cisco network switch had failed and central monitoring wasn t being passed through either Remarkable that the problem was first discovered as an outage in guest network tail.cfm?mdrfoi ID= ECRI Institute

19 What can you do? Monitor AP function and create a notification and escalation scheme for outages Technical escalation within IT Clinical escalation within CE and Nursing 2010 ECRI Institute

20 2. Firewall turned on inappropriately Staff were setting up for a procedure and received an error message on their bronchoscopy navigation system, which had recently received antivirus software During installation of the anti-virus software, the IT staff turned on the Windows firewall, disrupting communication Once the firewall was turned off, the system once again operated normally FM?MDRFOI ID= ECRI Institute

21 What can you do? Make sure decisions for firewall and security settings are documented and available to staff responsible for software updates (IT of Clinical Engineering) Trial an update in a controlled environment like a test lab After updating any device, validate device function before releasing for clinical use 2010 ECRI Institute

22 3. Do you want Windows 10? Microsoft is offering Windows 10 upgrades freeof-charge for devices using Windows 7, 8 and 8.1. Computers using these OS may prompt users to upgrade, and some users have admin rights Installing new OS can cause the failure of medical devices or software running on the computers (awaiting publication in Health Devices Alerts) 2010 ECRI Institute

23 What can you do? Strictly control admin privileges Do Not upgrade computer OS without written assurance from suppliers that medical devices or software will still work If an unapproved upgrade happens, follow Microsoft instructions to restore the system ECRI Institute

24 4. Third-Party Vulnerability Scanning During an unannounced black box test, telemetry kept rebooting and was down for 2 hours Facility had forgotten to provide an exclusion list to the security firm No tech support in the middle of the night Security firm forgot to exclude medical systems in the next test and the problem recurred ertdisplay.aspx?aid= ECRI Institute

25 What can you do? Institute an approval plan for vulnerability scans Try out the scan in a test environment Work with vendors Initial implementation Keeping device security settings current Incident reporting and support 2010 ECRI Institute

26 Thank you! ECRI Institute

27 The time is ripe to stop admiring the problem Suzanne Schwartz, MD, MBA EMCM / FDA CDRH Medical Device Cybersafety a Pragmatic Approach Axel Wirth, CPHIMS, CISSP, HCISPP National Healthcare Architect Distinguished Systems Engineer December 16, 2015

28 What do these two gentlemen have in common? Both made medical decisions based out of concern that their implanted medical device could be hacked! Copyright 2015 Symantec Corporation 28

29 Medical Device Cybersecurity Introduction to the Problem Space Risks: Patient safety (lives) Operational / Downtime Data Breaches / Fines Revenue / Financial Patient trust & Staff morale National security Threats: Targeted attacks Collateral damage Malware remediation Theft / Loss Compliance violation Lateral attack / weakest link exploitation Hacktivism, terrorism Vulnerability: Tightly regulated turn-key systems Long useful life Poorly protected & patched No detection & alerting Ecosystem Complexity Vulnerability of device, hospital, & health system Copyright 2015 Symantec Corporation 29

30 Medical Device Security - Separating Hype from Reality Reality Hype Hypothetical What we know Headline Material Futures Malware outbreaks Operational impact: care delivery downtime Devices are attacked Research & security testing Vulnerabilities are: common broad easy to exploit Dick Cheney s pacemaker Predictions of murder & assassination TV shows (CSI Cyber, Homeland) National security & critical infrastructure: Cyber-Hacktivism Cyber-Terrorism Cyber-Warfare Risk of an actual patient safety incident: Patient harm Treatment decisions Reputation Unintended consequences In this discussion we need to focus on Reality, but be prepared for the Hypothetical. In Cybersecurity, any single event can change the Paradigm! (unlike traditional hazard analysis linear and predictable) 30 Copyright 2015 Symantec Corporation 30

31 Medical Device Security not just a Healthcare Topic 31

32 FDA Position evolving, yet often misunderstood FDA applies Regulatory Controls based on Patient Safety Risk Class I (low risk), Class II (medium risk), Class III (high risk or no precedent) Not all devices require formal FDA approval - filing or listing with FDA is sufficient for many device types Initially treated software just like any other component (1999) Include in Engineering Hazard Analysis, test, document residual risks, etc. Recognized Software unique needs (2005/2009) Security requires lifecycle management under Manufacturer Quality System Security patches and upgrades do not require FDA approval or notification, but need to be documented and undergo verification & validation testing This is why hospitals can t install security software w/o approval Evolving Security Understanding Software as a System (2014) Cybersecurity is a manufacturer responsibility Part of premarket documentation and filing / approval Demonstrate (and document) that you considered cybersecurity risks Expected Statement about Postmarket Responsibility (Jan. 2016) Changing view: intended use to intended use in a hostile (cyber) environment Cybersecurity in the context of a total product life-cycle approach, from design to obsolescence Copyright 2015 Symantec Corporation 32

33 ationandguidance/guidancedocuments/ucm pdf FDA Guidance (Oct. 2014): Identify & Protect Limit access to trusted users Ensure trusted content Detect, Recover, Respond Detect, recognize, log, and act upon security incidents Actions to be taken Protect critical functionality Recover device configuration Cybersecurity documentation Hazard analysis, mitigation, design considerations Traceability matrix (cybersecurity controls to risks) Update and patch management Manufacturing integrity Recommended security controls Copyright 2015 Symantec Corporation 33

34 What can Possibly Go Wrong? Device hack (research only, so far) Device loss/theft (PHI breach) Drug abuse Patch deployment failure Reports on device testing with disastrous results ICS-CERT and FDA warnings FDA, DHS, FBI regulatory action Copyright 2015 Symantec Corporation 34

35 Medical Devices Now Targeted and Exploited! MedJack: Medical Device Hijack APT exploit of medical devices 3 hospitals, 3 different medical devices (reported May 2015): Blood Gas, X-Ray, PACS) Undetected, difficult to remediate Near perfect target : Limited IT visibility Unprotected / unpatched Entry point to the network Common, widespread vulnerabilities This is not hypothetical anymore; devices are being exploited! Pivot point to enter network Invisible to IT security Malware detected: Zeus, Conficker Citadel (Ransomware!) Copyright 2015 Symantec Corporation 35

36 and as of September, reported at Derbycon Copyright 2015 Symantec Corporation Exposed 68,000 Medical Devices from a large, unnamed US health group. Discoverable via Shodan Search Engine. Thousands of misconfigurations and direct attack vectors, incl. Win XP. Allows for detailed mapping of network, including devices. MRI and Defibrillator honeypots. 55,416 login attempts over 6 months. 299 attempts to install malware. 24 exploits of Conficker vulnerability Conclusion: Medical Devices are a recognized target! Most likely because they are vulnerable, not because of what they are. We have to assume that there are many owned devices out there. 36

37 Solutions Approach Key Elements Manufacturer Provider (procedural) Provider (technical) Organizational: Define responsibilities Security training Establish best practices Design into your device (based on risk and use): Cybersecurity (update-less) PHI Encryption Authentication, esp. for remote access Platform hardening Critical file and function protection Document: Device security properties Risks assessed Maintain: Security posture Documentation Stop stupid, cooperate! Organizational: Security responsibility Security training Procurement: Specify security req s in RFP and contracts Request MDS 2 Establish security obligations and contacts Asset Management: Complete inventory Including security & privacy properties Risk Management: Include medical devices Supply chain risks HIPAA (PHI Risk Analysis), Joint Commission (Med. Equipment Safety) ISO/IEC series Risk Mitigation Defense in Depth Device Security: Manufacturer guidance Patching Security software (as appropriate) Device Handling: Configuration & Change Management New device onboarding EOL (esp. PHI handling) Loaners/leased devices USB device usage Network Architecture: Understand dependencies (device to network gear) Wireless best practices Biomed VLAN Security Gateway Note: References for MDS 2, IEC 80001, VLAN Architecture, etc. are provided in the Appendix Copyright 2015 Symantec Corporation 37

38 Embedded Systems Security the right approach On-device security: HIDS / HIPS Ease Lifecycle Management and Patch pressures Provide EOL OS lifeline App & Process Whitelisting Common Use Scenarios: Process/Port control System administration FDA-regulated Medical Device: Example: Imaging, Diagnostics Manufacturer approval / implementation Supporting IT System: Workstation, Server Software-only Medical Device: Example: PACS workstation Protect platform (install on workstation) Non-Medical Device: Example: pharmacy robots, building systems, nurse call, etc. Install on Device as permitted by Contract/Warranty Note: check with manufacturer on device FDA status Copyright 2015 Symantec Corporation Company Confidential! 38

39 Access & Authentication Encryption & Data Privacy Device Certificates, Code Signing Platform and Critical System Protection Security Capabilities (detection, logging) Cybersecurity Documentation & Updates Procurement & Contract Management Processes & Workflows Asset Management Risk Analysis & Management Network Security & Architecture Cybersafety It s a shared Responsibility Increasing and Sophisticated Cyber Threats Growing Regulatory Pressure & Compliance Risks Shared Problem Complex and Highly Integrated Ecosystem of Vulnerable Devices Coordinated Solutions Approach Device Manufacturers Healthcare Providers Copyright 2015 Symantec Corporation 39

40 Good security advise: Don t rely on the kindness of strangers; think as if they are out to get you because they are! Thank you! Axel Wirth axel_wirth@symantec.com (617) Copyright 2014 Symantec Corporation. All rights reserved. Symantec and the Symantec Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners. This document is provided for informational purposes only and is not intended as advertising. All warranties relating to the information in this document, either express or implied, are disclaimed to the maximum extent allowed by law. The information in this document is subject to change without notice.

41 FDA References Information for Healthcare Organizations about FDA's "Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-The-Shelf (OTS) Software (updated July 2015) Cybersecurity for Networked Medical Devices is a Shared Responsibility: FDA Safety Reminder (updated Oct. 2014) Guidance for Industry - Cybersecurity for Networked Medical Devices Containing Offthe-Shelf (OTS) Software (Jan. 2005) nts/ucm htm Off-The-Shelf Software Use in Medical Devices (Sept. 1999)

42 IEEE: Building Code for Medical Device Software Security Nov Workshop Released May 2015 Addressing device manufacturers secure SW design needs. Key Elements: Avoid vulnerabilities Cryptography SW integrity Impede attackers Enable detection Safe degradation Restoration Maintain operations Support privacy 42

43 IHE International - PCD MEM Patient Care Device Domain, Medical Equipment Management MEM Whitepapers: Cybersecurity (2011: Education & Problem Baseline) Cybersecurity Best Practices (2015) Medical Device Patching (2015) co-authored by MDISS and IHE Copyright 2015 Symantec Corporation 43

44 Asset & Supply Chain Management Manufacturer Disclosure Statement for Medical Devices Security (MDS 2 ) Medical Device Security should be part of the Procurement Process: - RFP Language - Request NEMA MDS 2 Developed in cooperation by HIMSS and NEMA New version Oct More detailed (2 -> 6 pages) Now harmonized with IEC technical controls Copyright 2015 Symantec Corporation 44

45 IEC Series Application of Risk Management for IT-Networks Incorporating Medical Devices IEC : Part 1: Roles, responsibilities and activities IEC : Part 2-1: Step by Step Risk Management of Medical IT-Networks; Practical Applications and Examples IEC : Part 2-2: Guidance for the communication of medical device security needs, risks and controls IEC : Part 2-3: Guidance for wireless networks IEC : Part 2-4: General implementation guidance for Healthcare Delivery Organizations IEC : Part 2-5: Application guidance -- Guidance for distributed alarm systems IEC : Part 2-6: Application guidance -- Guidance for responsibility agreements IEC : Part 2-7: Application guidance for healthcare delivery organizations (HDOs) on how to self-assess their conformance with IEC IEC Part 2-8: Application guidance -- Guidance on standards for establishing the security capabilities identified in IEC IEC Part 2-9: Application guidance -- Guidance for use of security assurance cases to demonstrate confidence in IEC/TR security capabilities 45

46 Segregation (VLAN Network, Access Control) From: VA Medical Device Protection Program (MDPP), presented at the NIST Health Security Conference, May 11,

47 Symantec Internet Security Threat Report, Vol Copyright 2015 Symantec Corporation 47