Biomedical Device Security: New Challenges and Opportunities. Florence D. Hudson Senior Vice President and Chief Innovation Officer Internet2

Transcription

1 Biomedical Device Security: New Challenges and Opportunities Florence D. Hudson Senior Vice President and Chief Innovation Officer Internet2

2 The evolution to today s reality in biomedical devices Number of connected devices is increasing with the goal to improve patient care and create efficiencies in the healthcare system Growing Bring Your Own Device paradigm for providers and patients Proprietary / closed devices and systems are assumed secure Inadequate teamwork between medical providers, device vendors, technology innovators, cybersecurity experts, insurance companies, regulators, patients, to assess & address vulnerabilities ROI not agreed for improved security needs across ecosystem Rate of innovation is slow, and will continue to be unless we work as a Collaborative Innovation Community 2

3 Biomedical devices have inadequate security controls There is no such thing as a threat-proof medical device Suzanne Schwartz, M.D., MBA, Director of emergency preparedness/ operations and medical countermeasures at the FDA Center for Devices and Radiological Health, October 2014 FDA areas of concern about cybersecurity vulnerabilities Malware infections on network-connected medical devices or computers Smartphones and tablets used to access patient data BYOD Unsecured or uncontrolled distribution of passwords Failure to provide timely security software updates and updates to medical devices and networks 3 :

4 FDA recommendations for Management of Cybersecurity in Medical Devices Cybersecurity - is the process of preventing unauthorized access, modification, misuse or denial of use, or the unauthorized use of information that is stored, accessed, or transferred from a medical device to an external recipient. Manufacturers should develop a set of cybersecurity controls to assure medical device cybersecurity and maintain medical device functionality and safety. Failure to maintain cybersecurity can result in compromised device functionality, loss of data (medical or personal) availability or integrity, or exposure of other connected devices or networks to security threats. This in turn may have the potential to result in patient illness, injury, or death. FDA recognizes that medical device security is a shared responsibility between stakeholders, including Health care facilities Patients Providers Manufacturers of medical devices. 4

5 FDA recommendations for manufacturers to protect networked biomedical devices and patients Manufacturers should address cybersecurity during the design and development of the medical device This can result in more robust and efficient mitigation of patient risks Establish a cybersecurity vulnerability and management approach as part of the software and hardware validation and risk assessment Address the following elements Identification of assets, threats, and vulnerabilities Assessment of the impact of threats and vulnerabilities on device functionality and end users/patients Assessment of the likelihood of a threat or vulnerability being exploited Determination of risk levels and suitable mitigation strategies 5

6 FDA provides considerations regarding Cybersecurity for biomedical devices Connected Medical devices are more vulnerable to cybersecurity threats than devices not connected (wireless or hard-wired) to networks, internet, other devices The extent to which security controls are needed depends on a number of factors Device s intended use and environment of use Presence and intent of electronic data interfaces Type of cybersecurity vulnerabilities present Likelihood the vulnerability will be exploited (intentionally or unintentionally) Potential risk of patient harm due to a cybersecurity breach. Need to balance between cybersecurity safeguards and the usability of the device in its intended environment of use Ensure that the security controls are appropriate for the intended use case Home use vs. closely monitored health care facility use Patient use vs. health care provider use For example, security controls should not unreasonably hinder access to a device intended to be used during an emergency situation. 6

7 FDA and NIST recommend 5 step Cybersecurity Framework: Identify, Protect, Detect, Respond, Recover Identify and Protect Limit Access to Identified, Trusted Users Only Multi-factor authentication (e.g., user ID and password, smartcard, biometric) Layered authorization model by differentiating privileges based on the user role Avoid hardcoded password or common words Limit public access to passwords used for privileged device access Automatic timed methods to terminate session and/or update password Require user authentication before permitting software or firmware updates Ensure Trusted Content Restrict software or firmware updates to only authenticated code Use systematic procedures for authorized users to download versionidentifiable software and firmware from the manufacturer Ensure capability of secure data transfer to and from the device, when appropriate use encryption 7 National Institute of Standards and Technology. Framework for Improving Critical Infrastructure Cybersecurity. Available at: final.pdf.

8 FDA and NIST recommend 5 step Cybersecurity Framework: Identify, Protect, Detect, Respond, Recover Detect, Respond, Recover Implement features that allow for security compromises to be detected, recognized, logged, timed, and acted upon during normal use Develop and provide information to the end user concerning appropriate actions to take upon detection of a cybersecurity event Implement device features that protect critical functionality, even when the device s cybersecurity has been compromised Provide methods for retention and recovery of device configuration by an authenticated privileged user 8 National Institute of Standards and Technology. Framework for Improving Critical Infrastructure Cybersecurity. Available at: final.pdf.

9 Start today to identify and address risks and challenges to overcome to provide improved connected healthcare Considerations Potential Actions Security / Privacy Design in security and privacy from the beginning for devices and applications Use federated identify and multi-factor authentication Cultural transformation Engage patients & providers in development of the devices and solutions Focus on user experience Data quality Systematic data analysis and cleansing Integrating data from various systems to get a complete picture Ownership, collection, use and sharing of data Incorporating new types of sensors / devices Use connectors & translators to integrate multiple data formats and protocols Develop and deploy enterprise data policy, comply with regulatory policy Develop an extensible architecture to incorporate future data / sensor types 9 Source:

10 We must work together across the healthcare and technology ecosystem to improve device security Assess and understand the risks Threat vectors Malicious and inadvertent security/safety issues Singular and extended risks Work as Collaborative Innovation Community (CIC) to improve security Collaborative Innovation Community to include medical providers, device vendors, technology innovators, insurance companies, regulators, patients Start with assessment of device security, privacy, safety risks Agree ROI for improved security needs based on device / use case 10

11 Medical Devices could be classified for Trust, Identity, Privacy and Security (TIPS) requirements Classify TIPS requirement level by use case / device type Low TIPS requirements e.g., FitBit, wearable IOT connected clothing High TIPS requirements e.g., insulin pump, heart device Work with biomedical device vendors to develop optimized security based on use case and cost to reduce risk Security can be addressed at various levels in a biomedical device. Based on the low or high TIPS requirements, one or multiple levels of security and privacy can be developed. Service level Software level Firmware level Hardware level Service level security is fastest to deploy, followed by software Firmware and hardware level security take more time to bake into the device 11

12 Medical Device Security in a Connected World Debra Bruemmer Manager of Clinical Information Security 2014 MFMER slide-12

13 Topics Mayo Clinic Overview Organization & Service Lines What 2 Years of Medical Device Security Research Gets You Fixing the Device Eco-system Final Thoughts 2014 MFMER slide-13

14 Mayo Clinic Overview Provides Patient Care, Education and Research 65,000 Employees 4,100 Employed physicians & scientist 3,500 Residents & students Large group practices in MN, AZ, FL, WI with 70 smaller sites Over 1 million patients per year Technology dependent Paperless patient care Interconnected systems and devices ~230,000 active IP addresses Unique in that we have: High profile patients (In the press: Middle East Leaders, United States Presidents, Foreign Dignitaries, Sports Figures, etc.) Significant intellectual property assets Classified research 2014 MFMER slide-14

15 Mayo Clinic Overview Mayo Clinic decided to dramatically increase it s security posture Brought in external CISO & formed Information Security Department Reviewed surface area of environment ~10,000 Windows servers ~2,000 Linux servers ~80,000 workstations ~20,000 networked medical devices Found that a significant number of devices on the network were not IT managed Formed a new team focused on medical device security 2014 MFMER slide-15

16 Clinical Information Security Division Director of CIS Organization & Service Lines Manager Medical Devices Principal Security Analyst Environmental, Facilities & Clinical Support Systems Principal Security Analyst Operational & Pre- Purchase Principal Security Analyst Principal Security Engineer Senior Security Analyst Security Analyst Security Analyst 2014 MFMER slide-16

17 Mayo Clinic Philosophy Incorporate security into the procurement process RFP questions and standard security contract language Practice drives purchase decision, security enables secure execution Test medical devices, do not wait for the vendors to identify and address issues Document/Share test findings with the vendor Outline actions and timeline to address findings Prefer collaboration vs. public disclosure Goal: Partner with our vendors to have a safe outcome for our patients; this includes assisting vendors in providing us with a secure product Benefit society by using Mayo Clinic s influence Require changes made put into standard product Drive changes for long term vendor process improvements 2014 MFMER slide-17

18 What You Learn from 2 Years of Medical Device Security Research and Management 2014 MFMER slide-18

19 Vendor Situations Most are engaged and trying to catch up Struggling to change internal culture and build security awareness Think of themselves as device manufactures, not software developers No one has a full understanding of how everything works together Engineers & product designers really love their software and are proud of it The don t take well to calling their baby ugly Interactions with sales and product managers tend to be unproductive Executives understand the company/brand impacts (thanks to Target) 2014 MFMER slide-19

20 Vendor Situations Poor processes for development, testing, and support Lack coding standards with security tollgates Lack hardened configuration standards Lack testing process and tools (vulnerability scanning, fuzz testing, & penetration testing) Lack mature processes to apply updates & patches across install base Vendor Responses Initial reaction is guarded Follow up meetings have been more productive Remediation timelines are prolonged (~ 88% of issues are vendor owned) Significant support process implications 2014 MFMER slide-20

21 Incorporate Security Language Into Procurement Contracts Product development & specifications Security standards/processes are adhered to during development Testing processes and tools meet industry standards Written security program Consistent with industry standards Reflects business size, product, and data stored or accessed Provide audit logs in electronic format Test security program key controls, systems & procedures (yearly) Produce system and security logs in a standard exportable format Secure user authentication protocols and access control measures Education and training of employees Periodic reviews 2014 MFMER slide-21

22 Incorporate Security Language Into Procurement Contracts Perform vulnerability assessment on all products Meets "SANS WE Top 25" and / or "OWASP Top 10" Performed by vendor, Mayo or agreed upon 3 rd party AV and Patching Support use of commercial AV and receipt of regular signature updates All software or firmware updates are restricted to authenticated code Validated updates and patches for all products (i.e. commercial applications, operating systems) will be provided within 30-days of release Post installation Document required ports & services Remove software and installation media not required for the product Disable ports, services and drives not required for use Financial responsibilities (future findings or breaches) 2014 MFMER slide-22

23 Incorporate Security Language Into Procurement Contracts Passwords All vendor used PW are made unique to Mayo Clinic and changed every 90-days Complex (> 14 characters, alphanumeric, upper/lower case, and symbols) No hardcoded passwords User credentials or passwords will not be stored or transmitted in clear text Encryption Communication is encrypted between devices (i.e. servers, monitors, computers) Wireless communication will use meet current industry standard Administrative Privileges Limit accounts requiring administrative privileges No application / service / communication process requires admin privilege Incident Response Process Reported to Mayo within 30-days of identification Identify supplier s mitigation/response plan, including timeframe 2014 MFMER slide-23

24 Focus Security Testing on Risks Current production devices and systems Upgrades and new versions Pre-purchases Remediated devices Medical Devices AND Clinical Support Systems (applications) Infant Protection System Nurse Call Temperature Monitoring Etc MFMER slide-24

25 Standard Security Testing Process Focus on high priority devices Greatest potential to cause patient harm Greatest potential to widely disrupt patient care processes Clinical Application Engage all stakeholders Mayo (Clinical Users, Biomed, IT, Facilities) Vendor Equipment Function Assess the whole device family Follow the data flow to include points of testing Workstations, servers, & endpoint Document demographic information, establish rules of engagement Conduct assessment via scanning, penetration testing, fuzz testing Testing outcomes drive remediation efforts Network mitigations Endpoint & system mitigations Partnering with the vendor 2014 MFMER slide-25

26 Standard Security Testing Process Timeline: 3 weeks for test preparation 3 weeks of testing 3 weeks to document findings & write report Establish remediation timeline (Mayo/vendor) Data Collection Follow the data flow Workstations, servers, & endpoint Document demographic information Vendor or internal Mayo area supply a non-production representative system to be used for testing Clinical & support areas (biomed, facilities) are engaged to determine: rules of engagement that need to be followed Identification of the device family components 2014 MFMER slide-26

27 Standard Security Testing Process Testing includes: Operational security review Vulnerability scanning using commercial and public scanners Fuzz testing Penetration testing simulating multiple attack scenarios Reverse engineering and code review (subset of code) Testers are provided network access to the system, the name of the product, and IP address Testing Outcomes and Process Generate detailed vulnerability assessment report Review report with internal proponents Review report with vendor Outline and document actions (vendor and Mayo) Track actions for closure 2014 MFMER slide-27

28 Standard Security Testing Process Testing comprehensive report List issues by high / medium / low severity Complete details enable vendor to reproduce the vulnerability Include screen prints, video, scripts, etc. Initial week of testing good to have a vendor rep on-site to provide feedback on severity and to understand the process & vulnerabilities found Testing Axiom Visibility, Transparency, Moral High Ground 2014 MFMER slide-28

29 Security Testing System Thinking No device lives in isolation Need to review the ecosystem a device lives in Many devices have control software that is vulnerable External access methods and process require testing Map communication patterns to determine all possible threat vectors, test the whole chain End user processes can thwart security measures 2014 MFMER slide-29

30 Device Family Concept is Important Includes everything needed to support the device and provide patient care: Devices Software Hardware Communication components 2014 MFMER slide-30

31 Security Testing - Statistics Tested or Reviewed ~ 30 Device / System Families Infusion pumps and formulary systems (multiple brands) CT MRI Infant Abduction Protection Etc Engaged 9 vendors in addressing findings Tested $100 million dollars of pre-purchased equipment Finalized contracts with 3 vendors to include security language (Mayo Minimum Security Requirements) 2014 MFMER slide-31

32 Security Testing & Reviews 2015 Plan Timeline = 3 x 3 x 3 (based on history) Seeking vendor engagement Staff participation Equipment Target = 15 + devices and Systems Discussion in-process with multiple vendors Retesting Meaningful Pre-purchase Security Reviews Integrate into clinical purchase decision making processes Clinical Equipment Integration Team CPC Equipment Sub-committee Radiology Equipment Committee Etc MFMER slide-32

33 Common Medical Device Issues Operational security gaps Application vulnerabilities Configuration vulnerabilities Unpatched OS, middleware and commercial applications Lack of encryption 2014 MFMER slide-33

34 Operational Security Gaps Customer support web sites Minimal or no user validation Helpful documentation & software Technical service & User manuals Software / firmware downloads Internal technical documentation Documents on intranets, servers & hard drives Publicly available information Hardcoded and default passwords Source code Manuals, source code, diagrams, etc. Devices publically available for purchase Allows for reverse engineering Testing platform for exploits Customer service social engineering Up for auction is this used Hospira Abbott PLUM A+ IV Infusion Pump. This powers up and initiates. It passed the self test MFMER slide-34

35 Application Vulnerabilities Generally fragile applications Susceptible to denial of service attacks (small & large scale) No passwords or passwords easily guessed or cracked Required to run with elevated privileges Use hardcoded passwords Available publically, user content and source code Unable to run simple anti-virus Vulnerable to a large number of known exploits 2014 MFMER slide-35

36 Configuration Vulnerabilities Unneeded functionality left operational Unneeded files and applications left on systems Default users and passwords not removed or changed Security software disabled Default settings on software & hardware Old communication and transfer protocols 2014 MFMER slide-36

37 Unpatched Software Running on older operating systems with no upgrade paths Various versions of Windows (and DOS) Multiple versions of Linux Old proprietary systems Unpatched software and commercial applications with published exploits No or resource intensive process for updates and patching Sneaker-net upgrade processes 2014 MFMER slide-37

38 Lack of Encryption PHI & PII stored unencrypted or weak encryption Ability to read and change patient data DES, MD5, Base 64 Communication is unencrypted Man-In-The-Middle attacks Emulation of monitoring devices Able to capture traffic and emulate devices Weak wireless encryption WEP 2014 MFMER slide-38

39 Fixing the Medical Device System Vendors Design in security for living in a dangerous environment Make devices easily and efficiently upgradable Include security in testing Follow security best practices Review operational security Think like they are out to get you! Providers Implement defense in depth Monitor for issues and compromises Develop business continuity and incident response plans Perform timely upgrades Test equipment before patient care Include contract language that requires security, testing and liability Think like they are out to get you! 2014 MFMER slide-39

40 Fixing the Medical Device System Regulators Have a prescriptive baseline for security Provide a framework for best practice Make cyber-security issues a mandatory reportable event Revise issue submission and reporting to facilitate the entry and reporting of security issues Regulatory actions for cyber-security issues Exclusions in DMCA for cyber-security testing Government Security Agencies Implement a database of reported vulnerabilities Provide intelligence for medical device issues and attacks Investigations of issues and events Security research 2014 MFMER slide-40

41 Lessons Learned - Decentralization & Variety Risk increases with The number of groups purchasing devices The number of groups supporting and maintaining devices The diversity of operating systems, vendors, and software The ability to maintain a good inventory diminishes as the number of groups purchasing devices increases Business areas & departments like shiny new technology 2014 MFMER slide-41

42 Final Thoughts The full medical device eco-system is currently broken We will be living with this problem for at least a decade While vendors have a responsibility to fix their equipment, healthcare providers have a responsibility to protect patients The technology and knowledge exist to fix the problem, but it s not always a technology problem All healthcare organizations can and must take action, start small and mature your efforts Educate yourself Inventory and prioritize devices (engage Clinical, Biomed, and IT staff) Talk with vendors Incorporate contract language into procurement processes Engage in industry efforts Etc. Be prepared, it s only a matter of time 2014 MFMER slide-42