May 2, 2018 - cybersecurity frameworks which include NIST and ISO/IEC, and general .... The standards defined in the ISO 14971 are associated with ...
CYBERSECURITY FOR HEALTHCARE MEDICAL DEVICES
by Brian J Greer
A Capstone Project Submitted to the Faculty of Utica College
May 2018
in Partial Fulfillment of the Requirements for the Degree of Master of Science in Cybersecurity
ProQuest Number: 10807905
All rights reserved
INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion.
PR EV
IE
W
ProQuest 10807905
Published by ProQuest LLC (2018 ). Copyright of the Dissertation is held by the Author. All rights reserved. This work is protected against unauthorized copying under Title 17, United States Code Microform Edition © ProQuest LLC.
ProQuest LLC. 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, MI 48106 - 1346
© Copyright 2018 by Brian J Greer All Rights Reserved
ii
Abstract A wireless syringe infusion pump manufactured by Smiths Medical was discovered to be vulnerable due to the device’s firmware (Kim, 2018). According to ICS-CERT (2017) the vulnerability would allow an attacker to exploit the functionality of the device which in turn may jeopardize the patient(s) safety. Medical devices are susceptible to compromise due to recommended guidance issued by regulatory agencies of the government. The gaps in current legislation provide challenges for the healthcare industry to secure and protect electronic patient information. This is further compounded with an absence of security being designed into the hardware and software of these devices that have evolved from embedded stand-alone devices to networked devices and IoT. The research will examine government legislation, security controls, and security design. Keywords: Cybersecurity, Professor Jaclyn Giordano, HIPAA, NIST, SDLC, USFDA, approval pathways.
iii
Acknowledgements Most of the greatest milestones in life are never tackled alone. This journey has been no different, and I would like to thank the following individuals for helping me along the way. Firstly, I would like to thank my parents for always making me strive for the highest in education, and my family and friends for the encouragement and support over these past few years. I would also like to thank Professor Stephen Pearson for being a second reader for this thesis and for challenging me in previous courses in order to become a better writer. I would like to thank my Director, Sue Pellecchia, CISSP, HCISPP, GCCC and colleague and mentor Michael Walsh, CISSP for their feedback, experience and guidance. I would like to thank my friend Meriwyn Travisano for being my listener as my thesis continued to develop. Finally, I would like to thank fellow classmate William Hongach, who has been a huge part of this entire program experience from the beginning.
iv
Table of Contents List of Illustrative Materials.......................................................................................................... vii Cybersecurity for Healthcare Medical Devices .............................................................................. 1 Statement of the Problem ............................................................................................................ 1 Regulatory compliance. .......................................................................................................... 1 Cybersecurity framework........................................................................................................ 3 Software development life cycle. ............................................................................................ 4 Security controls. .................................................................................................................... 4 Gaps in Current Research ........................................................................................................... 5 Defining the Audience ................................................................................................................ 5 Literature Review............................................................................................................................ 6 Introduction to the Literature Review ......................................................................................... 6 Regulatory Compliance .............................................................................................................. 7 Congressional acts overview................................................................................................... 7 Cybersecurity information sharing act of 2015. ................................................................. 8 HIPAA. ................................................................................................................................... 9 Security rule. ..................................................................................................................... 10 Hitech and breach notification. ......................................................................................... 10 Omnibus rule..................................................................................................................... 12 Cybersecurity Frameworks ....................................................................................................... 12 NIST framework. .................................................................................................................. 12 ISO framework...................................................................................................................... 14 ISO 14971. ........................................................................................................................ 14 ISO 13485. ........................................................................................................................ 15 IEC 61010-1. ..................................................................................................................... 15 IEC 62304. ........................................................................................................................ 15 ISO/IEC 27032.................................................................................................................. 16 IEC 80001-1. ..................................................................................................................... 16 Oversight ................................................................................................................................... 17 Medical Devices ....................................................................................................................... 17 Security. ................................................................................................................................ 18 Premarket notification 510(k). .............................................................................................. 20 Premarket approval (PMA) ................................................................................................... 20 Quality system regulation (QSR) .......................................................................................... 20 Premarket submission (PMS) ............................................................................................... 21 Postmarket management (PMM). ......................................................................................... 21 Software development life cycle (SDLC). ............................................................................ 22 Off the shelf (OTS) software. ........................................................................................... 23 Encryption. .................................................................................................................... 23 Anti-virus. ..................................................................................................................... 24 Authentication ........................................................................................................................... 25 Role based access control (RBAC). ...................................................................................... 25 Implantable devices. ......................................................................................................... 26 Threats............................................................................................................................... 27 Challenges. ........................................................................................................................ 28 v
Discussion of the Findings ............................................................................................................ 29 Research Question: What government regulations are needed to improve the security and safety standards for the medical device industry? .................................................................... 30 Research Question: Will medical devices support encryption and anti-virus?......................... 32 Research Question: Are access controls like RBAC supported for authorization? .................. 34 Comparison of the Findings to Other Studies ........................................................................... 36 Limitations of the Study ........................................................................................................... 37 Recommendations and Conclusion ............................................................................................... 37 USFDA Medical Device Approval Process.............................................................................. 38 HIPAA ...................................................................................................................................... 39 SDLC ........................................................................................................................................ 41 Future Research Recommendations .............................................................................................. 43 New Research Question 1: How to Design Security into the Design Phase of SDLC? ........... 43 New Research Question 2: Why are Case Studies limited to Researchers? ............................. 44 New Research Question 3: How to Improve Testing of Security Controls? ............................ 45 References ..................................................................................................................................... 46
vi
List of Illustrative Materials Figure 1 – ECS Information Sharing Process ......................................................................9 Figure 2 – Bayer Medrad MRI device infected with WannaCry ransomware ..................12 Figure 3 – USFDA Medical Device Approval Pathways ..................................................22 Figure 4 – Medical device shared responsibility for cybersecurity ...................................28
vii
Cybersecurity for Healthcare Medical Devices Statement of the Problem The healthcare sector has faced numerous challenges as it has transitioned from paper to digital record keeping through the advancements of technology and the Internet. As the healthcare industry has adopted new technology like the Internet of Things (IoT), wireless and networked medical devices, in addition to mobile and web-based applications, the industry has fallen behind in the security of electronic protected health information (e-PHI). Clinical systems and medical devices have historically not been designed around the cyber security framework (Arney, Venkatasubramanian, Sokolsky, Lee, & Venkatasubramanian, 2011). Using systems the way they were designed often causes gaps in security. With the increased value of medical information, organizations need to find ways to properly assess vendors and devices before installing them. This paper examines the regulations and security features of medical devices by comparing the cyber security framework controls not designed with patient safety in mind. A patient’s privacy and safety may be jeopardized due to inadequate security that would enable malicious attacks using malware to compromise patient information or even worse cause physical harm (Arney et al., 2011). The research provided will address the following questions: What government regulations are needed to improve the security and safety standards for the medical device industry? Will medical devices support encryption and anti-virus? Are access controls like RBAC supported for authorization? Regulatory compliance. The 1938 Federal Food, Drug, and Cosmetic Act (FFDCA) added medical device protection which is regulated by the United States Food and Drug Administration (USFDA). The FFDCA has been amended over the decades to reform and address technological changes such as electronic products that emit radiation which may cause
1
harm to the public health. Manufacturers of medical devices are required to meet standards that are regulated by the Center for Devices and Radiological Health (CDRH) (USFDA, 2015a). The classification of the medical device, which takes patient risk into account, will determine additional regulations based on the specialty of the device. Additionally some medical devices require clinical or laboratory testing which provides data on operational safety of the device. Manufacturers’ investment of financial and design resources face delayed regulatory approval to bring a product to market. This is due in part to regulatory requirements like those of the International Organization for Standards (ISO) for quality and safety of devices (ISO, 2018). The Health Insurance Portability and Accountability Act of 1996 (HIPAA) enacted the concept of protected healthcare information (PHI). The Privacy Rule and Security Rule were later added, addressing the accessibility and safeguards of PHI. The rules can be very confusing; the Privacy Rule covers all patient information which includes oral, electronic, and paper; whereas the security rule relates to the safeguards implemented to protect electronic PHI (ePHI) stored on removable media devices or transmitted (West Virginia State Privacy Office, 2018). The security rule applies to medical devices in which removable media and/or storage is part of the design for standalone or networked use. The Health Information Technology for Economic and Clinical Health (HITECH) Act was passed to promote and incentivize the healthcare industry to adopt electronic health records (EHR) through meaningful use (U.S. Department of Health & Human Services, 2017). HITECH also imposed much larger financial penalties for violations of HIPAA. Security breaches of protected healthcare information require organizations to notify the affected individuals under the HIPAA Breach Notification Rule, 45 CFR §§ 164.400-414, and the Federal Trade Commission (FTC) (HHS, 2013a).
2
Cybersecurity framework. Healthcare regulations and laws continue to be implemented at a slower pace and therefore still fall behind due to the rapid advancements of technology and medicine. This poses more obstacles for healthcare where medical device standards need addressing. Ed Cabrera summarized how the environment for the healthcare sector involves more risk from cyber-attacks and threats due to the lack of medical device security (Newman, 2017). This is due in part to the bridging of biomedical engineering and information technology through connectivity of devices and computers systems on the same network. Networked medical devices have an increase in risk potential over standalone devices due to their interaction with other systems. Wi-Fi is a wireless technology that is susceptible to interference and tampering that allows a cyber attacker to eavesdrop or access the healthcare provider’s internal network from a medical device (Arney et al., 2011). The merging of these two allows legacy medical devices with no security controls, outdated operating systems, and unpatched vulnerabilities to expose an organization’s network to new attack vectors. If the vulnerability is exploited the impact of risk potential may cause harm to a patient (Doctorow, 2016). Cyber security frameworks differ from one another in various industries but focus on lowering potential risk due to vulnerabilities using policies and or procedures. Many of the outdated and some currently used medical devices were not designed around the frameworks that exist today. The healthcare sector uses several frameworks which include the National Institute of Standards and Technology (NIST) and HIPAA for best practices and standards surrounding cybersecurity gaps and managing security controls. The framework is not a replacement of an organization’s risk management process or strategy, but rather a complementary tool used to strengthen security. The framework could have provided benefits and exposed the security gaps
3
to the James A. Haley Veteran’s Hospital before it was compromised with the malware Conficker which ended up infecting over 100 medical devices (Fu & Blum, 2014). Software development life cycle. Many medical devices rely on software that allows the device to interface or communicate with different systems. This improves patient care by streamlining the interaction between systems for more efficient delivery of care. The challenge manufacturers face is the complexities of developing software that meets regulation and safety standards using traceability from the software development life cycle (SDLC) (Regan, McCaffery, Mc Daid, & Flood, 2013). Oversight by the USFDA ensures the software in medical devices is validated through numerous testing measures for safety. Karl West, Intermountain Healthcare CISO pointed out that the USFDA does provide cybersecurity guidance for medical devices but it is not a binding regulation that medical device manufacturers must follow. The implementation of new regulations that allow a connection between the USFDA and HIPAA would force manufacturers to improve medical device cybersecurity (Snell, 2017). Security controls. Some devices store PHI permanently on the device while newer devices only store a few temporary records due to safety (Swim, 2012). Security controls enhance confidentiality, integrity, and availability (CIA) of information. ISO 27002 uses technical controls like cryptography to provide confidentiality of data at rest or in motion (Anderson & Williams, 2018). Integrity of data or patient information prevents unauthorized access or changes to the information through the use of mechanisms. These may include roles or access rights such as role based access control, which allows access through authorization and authentication based on the individual’s position within the organization (Colarik & Janczewski, 2009). The deployment of anti-virus and encryption technology ensures the integrity of sensitive
4
patient information by applying proper integration and confidentiality on the data (Abdur, Habib, Ali, & Ullah, 2017). Gaps in Current Research Medical devices were primarily used as stand-alone devices, which did not require the use of wired or wireless connections, or were connected on separate subnets (Wirth, 2011). Additionally a device’s proprietary software denied access for the organization to add security measures to the device. As medical devices incorporate more information technologies for added features, the complexity of critical devices may affect the safety of the patient and or the device. Healthcare organizations receive a Manufacturer Disclosure Statement for Medical Device Security (MDS2) which provides security related information regarding security features that are supported (Keller, 2017). The device may not support encryption, anti-virus, or account credentials. Another issue is that the typical life cycle of the device is longer than the life cycle of the operating system. Due to the regulatory compliance and validations that manufacturers must follow, these operating systems can no longer be patched (Wirth, 2011). While regulatory compliance standards are already being met by the manufacturers, there may still be gaps between the medical device security and the policies and or procedures of the healthcare facility. So how then does the healthcare sector go about assessing the risk or lack of security to protect the patient information that may or may not be stored on the physical device? Defining the Audience By exploring the cybersecurity of medical devices in the healthcare sector it becomes evident that there are challenges that need to be overcome regarding protection of patient information. Regulatory compliance without sufficient preventive or compensating security controls may result in vulnerabilities that cyber attackers can exploit. An individual’s personal
5
information is valued by cyber criminals, who can profit by acquiring and selling sensitive information by unlawfully accessing it through compromised systems. This in turn allows the sensitive information to be sold on the dark web which may result in medical identity theft and false claims against an individual causing anguish or financial harm (Fuentes, 2017). Organizations that have been victims of breached and/or compromised PHI are subject to penalties and fines (Keller, 2017). These incidents of sensitive information not being secured may also result in an organization dealing with reputational damage (Blakley, McDermott, & Geer, 2001). This research will provide a better understanding to employees and staff in the medical field, security analysts, patients, and legislators. This research is specific to medical devices and the obstacles in the healthcare sector that affects providers, hospitals, clinics, and other patient care facilities. The information provided may be used in bringing awareness of patient safety and security of medical devices. Literature Review Introduction to the Literature Review The Literature Review is intended to not only provide a general overview but also detailed specifics for further understanding of the research problem: How do healthcare organizations assess vendors and medical device security? The material presented in this portion will address the research question: What government regulations are needed to improve the security and safety standards for the medical device industry? An overview of laws, acts, and regulations made over the past century, security and privacy issues under HIPAA and HITECH, cybersecurity frameworks which include NIST and ISO/IEC, and general challenges.
6
The presentation of material will address the research question: will medical devices support encryption and anti-virus? Then the Literature Review will discuss an overview of medical devices and the approval process, the importance of software development life cycle and off the shelf software, followed by security controls of medical devices which include encryption and anti-virus, which will address the research question. The Literature Review will close by addressing the research question: are access controls like RBAC supported for authorization? This will include authentication and role based controls, implantable devices and the threats and challenges they may pose. Through this Literature Review and answering of the research questions the reader will have a better understanding of cybersecurity risks and threats of medical devices in the healthcare sector. Regulatory Compliance Congressional acts overview. The 1906 Pure Food and Drug Act (PFDA) was amended in the 1930s. This authorized medical device classification to fall under the USFDA jurisdiction known as the FFDCA (Institute of Medicine, 2011). During the 60s and 70s, new medical devices were brought to market without any type of testing or quality control standards. As the USFDA had previously engaged Congress to add provisions to FFDCA for drug application and review of new drugs, medical device safety failures and public health issues were still being reported (USFDA, 2018f). This resulted in Congress enacting passage of the Medical Device Amendments of 1976 (MDA) legislation. The MDA established new regulatory compliance for the medical device industry which included premarket notification and medical device reporting (Institute of Medicine, 2011). The MDA passage by Congress authorized the USFDA to implement new protocols to address safety and efficacy of medical devices in order to prevent related deaths or physical injuries (Maisel & Kohno, 2010).
7
During the 90s new legislation was introduced and passed by Congress to restructure the MDA and the controls of medical devices. The Safe Medical Devices Act of 1990 (SMDA) provided new regulatory compliance and classification requirements between class I, II, and III devices (Institute of Medicine, 2011). Medical device classification is determined by the risks (low, moderate, and high) of the device and the controls that govern each classification. A class I device like a surgical instrument is considered low risk with general controls. Class II devices, include infusion pumps and wheelchairs, are moderate risk with both general and special controls. Class III devices like valves, stimulators, and implants are high risk that require premarket approval and general controls (Johnson, 2016). The USFDA Modernization Act of 1997 reformed regulation of medical device risk associated with post market analysis. This allowed for the reporting of devices that may present potential harm to patients, and introduced industry experts into a pilot program to review and analyze class I and II devices (USFDA, 2015a). During the 00s the medical device industry worked with Congress to solve the effects of the USFDA’s medical device program that was no longer performing adequately due to continued loss of resource. With cooperation from Congress, the USFDA, and the medical device industry, progress was made providing a solution to amending the FFDCA to improve the regulation of medical devices through the Medical Device User Fee and Modernization Act of 2002 (MDUFMA) (USFDA, 2017a). Congress passed the Food and Drug Administration Amendments Act of 2007 (FDAAA) which increased the USFDA’s responsibility and made new provisions for medical devices for pediatrics (USFDA, 2018a). Cybersecurity information sharing act of 2015. Congress passed the Cybersecurity Information Sharing Act (CISA) in 2015, which required coordination from the Department of
8
Defense (DOD), Department of Justice (DOJ), the Department of Homeland Security (DHS), and the National Intelligence Director to establish cybersecurity procedures to allow threat information to be shared with persons both publicly and privately (Library of Congress, n.d.). The U.S. Department of Human and Health Services (HHS) were working in collaboration with the National Institute of Standards and Technology (NIST), DHS, and industry leaders to devise a cybersecurity framework with standards and security best practices for securing software systems and networked medical devices accessing electronic protected health information from cyber-attacks (Library of Congress, n.d.). CISA introduced information sharing that provides beneficial information through notifications that allow organizations in critical infrastructure including health care the necessary time for preparation. Figure 1 below shows the DHS information sharing program, Enhanced Cybersecurity Services (ECS) that shares threat indicators with commercial service providers that participate in the program.
Figure 1- ECS Information Sharing Process. Reprinted from “The 2013 Cybersecurity Executive Order: Overview and Considerations for Congress,” E. Fischer, E. Liu, J. Rollins, and C. Theohary, 2013, Congressional Research Service, CRS Report No. 7-5700, p. 8. Copyright 2014 by the Department of Homeland Security.
HIPAA. In 1996, the passing of the Health Insurance Portability and Accountability Act (HIPAA) provided new regulatory requirements and standards for protecting privacy and security of PHI in the healthcare sector (Swim, 2012). These standards provided more controls of how patient information was electronically transmitted to and accessed by authorized entities 9
(Kesan, Majuca, & Yurcik, 2005). Health information under HIPAA guarantees that the information technology networked infrastructure must comply with privacy (Sametinger, Rozenblit, Lysecky, & Ott, 2015). HIPAA mandates the use of administrative, physical, and technical security controls by healthcare providers, known as “covered entities,” who transmit ePHI (Maisel & Kohno, 2010). HIPAA regulations are directed toward the security of patient information and not the functionality of medical devices produced by manufacturers (Maisel & Kohno, 2010). Security rule. The HIPAA Security Rule was implemented in 2005, which defined three safeguards around electronic PHI (ePHI) security. The administrative safeguard control employed policy procedures which defined how an organization or entity would comply under HIPAA. The second safeguard dealt with the physical access of where the information was stored and how to prevent unauthorized access to the information. The last safeguard was technical which allowed IT security to implement solutions to provide protection of information transmitted (HIPAA Journal, n.d.). The goal of the Security Rule is to ensure that all transmitted or received ePHI maintains confidentiality, integrity, and availability. Organizations and their staff must comply with the protection of ePHI against security threats and unauthorized disclosures (HHS, 2013b). Hitech and breach notification. The Health Information Technology for Economic and Clinical Health (HITECH), enacted as part of the American Recovery and Reinvestment Act of 2009, was to promote the adoption and meaningful use of health information technology. Subtitle D of the HITECH Act addresses the privacy and security concerns associated with the electronic transmission of health information, in part, through several provisions that strengthen the civil and criminal enforcement of the HIPAA rules (HHS, 2016).
10
Anthem made headlines in 2015 due to a breach that was carried out by exploiting vulnerabilities in the system in which credentials were obtained from multiple individuals with high level access through phishing (Sienko, 2016). Anthem Inc. had reported that the database of 80 million records were not encrypted, which allowed cybercriminals to breach the system and compromise the data (HealthCare Headlines, 2015). The Health Information Trust Alliance (HITRUST) is an organization that established the Common Security Framework (CSF) that allows organizations to utilize the CSF framework to safeguard sensitive information (HITRUST, 2018). HITRUST issued a statement, “Upon further investigation and analysis it is believed to be a targeted advanced persistent threat (APT) actor” regarding the targeted attack on Anthem (Snell, para. 9, 2015). Bayer’s radiology division manufactures diagnostic and imaging medical devices used in healthcare. In 2017 a Bayer Medrad device was infected with the ransomware, WannaCry at a U.S healthcare facility (Fox-Brewster, 2017). The events of healthcare organizations being compromised have become more frequent in recent years. Those threats not only risk health information but can impact patient safety and care when medical devices are susceptible due to minimal or no security (Anderson & Williams, 2018). Figure 2 below shows a radiology medical device infected with the WannaCry ransomware.
11
Figure 2 - Bayer Medrad MRI device infected with WannaCry ransomware. Reprinted from Medical Devices Hit By Ransomware For The First Time In US Hospitals, In Forbes, by T. Fox-Brewster, 2017. Retrieved from https://www.forbes.com/sites/thomasbrewster/2017/05/17/wannacry-ransomware-hit-real-medical-devices/#61c61d7f425c. Copyright 2017 by Forbes.
Omnibus rule. The Final Omnibus Rule of 2013 did not introduce new regulations but did address missing cybersecurity measures for ePHI protection. Encryption and business associate provisions improved unclear areas and concerns under the HIPAA and HITECH regulations. The Security Rule provision added encryption as a technical safeguard for mobile computing, messaging, and cloud storage (HIPAA Journal, n.d.). These provisions provided technical cybersecurity safeguards for the security and privacy of patient information. Cybersecurity Frameworks NIST framework. Dr. Samuel Wesley Stratton envisioned a science laboratory to provide national standards for products and services more than a century ago. NIST is part of the U.S. Department of Commerce (DOC) which strives for innovation through measurement, technology, and standards which have impacted computer integrated circuits to critical infrastructure. Some of these have even reached electronic health records used in the healthcare sector (NIST, 2017a). The laboratory areas consist of engineering, computer science, and mathematics to address a wide range of topics including cybersecurity. In 2013, Executive Order 12
13636 was signed by President Obama due to the increase in cyber threats and intrusions on critical infrastructure (Fischer, Liu, Rollins, & Theohary, 2013). NIST has been involved with cybersecurity since the 1970s, collaborating and engaging with federal agencies, academia, and industry leaders for security standards to protect information from cyber threats (NIST, 2013). The EO 13636 directed NIST to develop a cybersecurity framework in conjunction with stakeholders of both public and private sectors, in order to address challenges of critical infrastructure through best practices and standards (NIST, 2013). The process allowed the strengths of each sector and combining resources to address and develop a framework that outlined guidelines for industry in hope that the private sector would adopt and follow. The framework design focused on areas that could be leveraged and used across all 16 critical infrastructures. The request for information (RFI) provided a means for stakeholders to participate in the process of developing a new preliminary framework. The initial outcome addressed scalability across an organization, cybersecurity readiness and guidelines, awareness, standards, and the need to balance existing regulatory authorities (NIST, 2013). Although the fundamental groundwork took shape, there were other concerns that needed to be addressed in critical infrastructure for the different needs in each sector. A consensus was reached that adapted a three tiered level for implementation along with cybersecurity functions and literature to assist with the framework being implemented (NIST, 2013). As for information technology programs, response to computer security incidents has become a major, critical component. An organization’s ability to effectively respond to complex and threatening security incidents is crucial for identifying and resolving security vulnerabilities (Sametinger et al., 2015). NIST has issued a special publication 800-61 to address computer
13
security handling which provides guidelines on how to handle computer hardware, software, protocols and applications (Cichonski, et al., 2012). A solid incident response plan is a prerequisite to be able to detect security incidents in a timely manner, minimize the harm caused to the organization, mitigate any potential threats and successfully restore services in a timely manner (Williams & Woodward, 2015). The Center for Internet Security (CIS) developed the critical security controls (CSC) for cyber defense that provide organizations a starting point to define and implement defenses within network infrastructure. The controls align with other cybersecurity frameworks including NIST and HIPAA. Four important controls of the CSC include configurations of both hardware and software on computing devices, vulnerability and remediation assessments to exploits, and inventory of all hardware and software whether authorized or unauthorized (CIS, 2018). ISO framework. The International Standards Organization (ISO) is an independent organization providing specifications on products and services throughout the world. These standards are developed and drafted according to the market need of an industry sector, which in turn allows input from committees and experts to weigh in on all aspects of the standard. Standards can take up to three years to be developed from the initial development proposal to publication (ISO, n.d.). ISO also works closely with other standards organizations to form partnerships. An example of this is the World Standards Cooperation (WSC), formed in 2001, which brought the ISO, International Electrotechnical Commission (IEC), and International Telecommunication Union (ITU) together to reinforce standards (ISO, n.d.). ISO 14971. The standards defined in the ISO 14971 are associated with medical devices, in which manufacturers must address and adhere to the process of identifying and controlling any related risks while controls are monitored for effective use (ISO, 2007). The requirements of ISO
14
14971 standards incorporate the medical device life cycle from all phases but does not require the manufacturer to implement a quality management program or provide any specific guidance for levels of risk or clinical governing (ISO, 2007). Although the standard specifies a process in which manufacturers can identify risks of medical devices, the decisions that relate to the safety and acceptable use of the product for market are decided by the manufacturer. ISO 13485. Quality management is the standard for ISO 13485, which ensures an organization is following the requirements in the design and development of medical devices. This entails the production, installation, and servicing of the product. The standard provides a means for organizations to assess that regulatory requirements are met for customers, certification authorities, or other parties (ISO, 2002). This standard is to synchronize the quality management of a medical device with the regulatory compliance to form a process that manages quality but also ensures the device meets federal or regulatory statues (ISO, 2002). IEC 61010-1. Electrical equipment requires safety standards that meet the requirements for their intended use. The range of devices covered for use in different environments include equipment used for material processing or analyzing in a laboratory, electromagnetic components for measurement, and process control used for controlling output variables to specific values (IEC, 2018). Other requirements include hazards and radiation that cover the environments in which the device is used and ensure acceptable levels of X-ray emissions. This provides manufacturers of medical devices to have an independent licensed and authorized organization to conduct testing to certify the medical device meets product safety and compliance (Met Labs, 2018). IEC 62304. Another standard for medical devices is the IEC 62304 that defines the software used in medical devices. The standard contains three requirements that consist of
15
quality and risk management and software safety. These standards work in conjunction with other requirements to provide compliance and meets quality standards (ISO, 2006). Some of the standards that have relational value to IEC 62304 are as follows; ISO 14971 for managing risk, ISO 13485 for quality management, and IEC 61010-1 for safety of electrical equipment, (ISO, 2006). In 2016 the IEC proposed new revisions to include health software due to the increase use clinician workflow and network connectivity within healthcare. This will establish controls for which the software is reliable and safe while minimizing patient risk from delivery of care (AAMI, 2016). ISO/IEC 27032. This is a cybersecurity guideline that entails network and Internet security, critical infrastructure, and security best practices in the cyberspace realm. The standard addresses issues through the use of a framework which allows organizations to resolve cybersecurity related incidents. Risks identified and addressed include malware, cyber-attacks, and social engineering, which can all be shared through the framework similar to the information sharing provided by the NIST framework (ISO, 2012). IEC 80001-1. This is another standard for cybersecurity of medical devices used on IT networks and the associated risk management strategy that also incorporates IEC TR 80001-2-2 for security controls and risks for said devices. The framework incorporates both manufacturers and organizations that deliver healthcare solutions (ISO, 2016). Security controls presented encompass the NIST SP 800-54, revision 4 in accordance to the Federal Information Processing Standard (FIPS) 200. This allows an organization to assess risk, disaster recover, and incident response. Relational values of other standards are implemented into IEC 80001-1 which include; IEC 62443-3-3 entails network and system security, ISO/IEC 27002 security controls, and ISO 27799 management and security of health information (ISO, 2016).
16
Oversight The American Hospital Association provided the USFDA with an analysis of the financial costs associated with regulatory compliance. Results showed that a healthcare providers and systems spent nearly $39 billion dollars associated with administrative actions in regards to federal compliance (AHA, 2017). A typical hospital in the U.S would spend an estimated $1,200 on compliance per admitted patient, which hampers healthcare providers’ focus to deliver improved care due to the administrative duties (AHA, 2017). Medical device approval time has become expensive and complex due to the current procedures implemented by the USFDA which places cumbersome challenges on manufacturers in preparing submissions for approval (Lee et al., 2012). The WannaCry ransomware that infected over 150 countries highlighted the American Hospital Association (AHA) concerns of medical device security needing oversight from the USFDA in order to hold medical device manufacturers accountable for new and legacy device security (AHA, 2017). The USFDA responded with new guidance for both pre market submissions and feedback for medical devices but did not address security (USFDA, 2017b). Medical Devices Milestones over the last 100 plus years have been achieved through innovation and discovery that incorporated technology allowing advancements in medicine to transform how treatments were provided to patients. In 1895 a German physicist by the name of Wilhelm Conrad Rontgen discovered how to capture an image using electromagnetic radiation waves that could penetrate the human anatomy (AJR, 1995). The invention helped pave the way for medicine and treatment through new areas of diagnostic and therapeutic treatments like computed tomography (CT), fluoroscopy, and radiation therapy using X-rays (NIBIB, n.d.). Today, medical devices using the X-ray technology are portable radiography equipment being
17
used in medical practices and hospitals. Medical devices are no longer stand-alone systems but in fact are now part of the process for patient care with vulnerabilities demonstrated by Halperin, who reverse-engineered communication protocols to compromise medical devices (Williams & Woodward, 2015). Medical devices have made great strides due to biomedical and information technology during the past half century. Advancements have allowed large medical devices to shrink in size over time and become capable of battery operation (Sussman, n.d.). Medical devices continue to evolve from embedded software systems to adopting more information technology (IT) features for communication (Sametinger et al., 2015), while others have started to transition to operating systems used on desktop and laptop computers. Some medical devices provide removable media storage like universal serial bus (USB) or compact disc read-only memory (CD-ROM) to remove data and studies from the device (Swim, 2012). As technology continues to advance, medical devices will continue to evolve allowing for more interconnectivity among devices and systems (Sametinger et al., 2015). As this trend grows the need for security will undoubtedly be needed for the safety of patients. Security. Due to the critical nature that medical devices currently occupy, the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) has partnered with the USFDA and device vendors to identify and mitigate the security vulnerabilities. Devices affected include pumps, ventilators, defibrillators, and monitors that are susceptible to elevated privilege access and modification of firmware (ICS-CERT, 2013). Medical device fixes are slow from manufacturers, and both the USFDA and the DHS are putting more pressure on companies to address these vulnerabilities. But for now, the pressure is on facilities, which are still responsible for most of the consequences if their systems are breached through medical devices. A solution is
18
to only work with companies and vendors that offer strong security features on their medical devices, including data encryption (White, 2015). In 2013 the USFDA issued new security guidance concerning medical devices and recommendations from ICS-CERT directed at healthcare organizations to consider restricting unauthorized access, anti-virus software, and security patching (ICS-CERT, 2013). New security guidance was issued in 2014 by the USFDA for device manufacturers to start looking at cybersecurity before the design phase that include controls, patching, risks, anti-virus, and life cycle (Fu & Blum, 2014). A USFDA senior official stated, “We are aware of hundreds of medical devices that have been infected by malware”, ( Sametinger et al., para. 2, 2015). Biomedical staff must assess if a medical device has the ability to store ePHI and if so how many and what types of records can be stored (Swim, 2012). The Manufacturer Disclosure Statements for Medical Device Security (MDS2) form supplied by the manufacturer allows biomedical staff a clear and concise list to review regarding the security of the device (Swim, 2012). The information provided on the form details how ePHI is stored and protected, if access control is supported, device hardening against malware, and recovery of the system (Stocker, 2016). Life critical systems create new challenges for manufacturers and organizations to maintain security without disrupting patient care. Critical functions of a device rely on software or software controls that regulate or adjust to a patient’s condition (Keller, 2017). Software defects are nearly impossible to counter but identifying the risks associated with the code can limit safety issues. Manufacturers develop proprietary medical device software for specific devices (Rakitin, 2006). The cybersecurity preparedness in medical devices is a concern among the medical communities due to vulnerabilities in software (Fu & Blum, 2014).
19
Medical device reporting of incidents currently does not exist at a national level although healthcare organizations like hospitals are routinely aware of ongoing security incidents of these devices (Fu & Blum, 2014). According to CFR - Code of Federal Regulations Title 21, the USFDA requires manufacturers, importers, and facilities using medical devices to report all serious injury or deaths due to safety issues but does not require reporting of cybersecurity incidents (USFDA, 2017c). However, patients and healthcare providers have the option of voluntarily reporting security incidents if inclined to do so (USFDA, 2018b). Premarket notification 510(k). Device manufacturers must notify the USFDA 90 days prior to marketing a medical device. This allows for the classification of the device into two categories of risk (Class II, or III) already established. Manufacturers are also required to submit a premarket approval for new and modified devices that may affect safety (USFDA, 2018c). Class I type devices usually do not require a premarket notification, but international and domestic manufacturers regardless of the class type must establish registration (USFDA, 2015b). Premarket approval (PMA). Class III devices are high risk due to providing patients with sustainable life and support and having the potential to cause serious injury. The approval process involves a review period of 180 days and recommendations from a committee (USFDA, 2018d). The premarket approval (PMA) is the most rigorous for approval due to the manufacturer must provide clinical evidence in regards to the device being safe. This requires clinical testing and verification for the USFDA to review and verify the findings (Johnson, 2016). The responsibility of testing and software validation of the device falls onto the manufacturers because the USFDA does not perform testing (AHA, 2018). Quality system regulation (QSR). Manufacturers must demonstrate that the quality of the device is sound and meets regulations. The requirements for a quality system regulation
20
(QSR) is applied under 21 CFR part 820, which covers different provisions such as the quality controls for the overall production of the device and meeting the compliance of the USFDA regulations (Cornell Law School, n.d.a). The ISO 9001 standards for quality and assurance were applied to being a universal international standard that would apply to both domestic and international vendors equally. The quality system regulation allows for some flexibility due to the wide range of devices (USFDA, 2018e). Premarket submission (PMS). A guide outlining cybersecurity principles for manufacturers to follow for medical devices, but also includes software, firmware, and logic. An outline for vendors to follow included identifying and assessing risks and vulnerabilities of the device such as removable media, network connectivity, authentication, detection of malware, and encryption methods. Implementation of cybersecurity measures not only ensures the device functionality but also reduces the risk of safety being compromised (USFDA, 2014). These cybersecurity controls provided guidance for vendors to follow, but were only recommendations to reduce patient risk. Postmarket management (PMM). The USFDA recognized that a manufacturer implementing cybersecurity controls could not account for the continuously evolving vulnerabilities exploited by cyber attackers. Although vulnerabilities and controls may have been addressed in the PMS, still new risks may emerge and require mitigation (USFDA, 2016b). A proposal by the Institute of Medicine to improve the PMM was met with disapproval from manufacturers who cited the changes would impact innovation and patient safety would be affected (Van Norman, 2016). Manufacturers are recommended to incorporate the NIST framework into their risk management strategy and to assess any vulnerability that does not pose the risk of harm to a patient (USFDA, 2016b).
21
Regulations are mandatory instruments imposed on organizations which provide assurance that medical devices meet or exceed safety and effectiveness when providing care to a patient (Regan et al, 2013). The USFDA process for manufacturers to bring a new device to market is quite involved and the additional cybersecurity complicates the process. Figure 3 below shows the USFDA process for medical device approval.
Figure 3: USFDA Medical Device Approval Pathways. Reprinted from “Drugs, Devices, and the FDA: Part 2,” by G. A. Van Norman, 2016, JACC: Basic to Translational Science, 1(4), p. 283. Copyright 2016 by G. A. Van Norman.
Software development life cycle (SDLC). The use of SDLC practices for designing medical device software allows for the elimination of vulnerabilities and exploits by improving software reliability with higher fault tolerances (Goertzel, 2008). An SLDC process allows critical safety measures to be implemented during development of software increasingly used in
22
medical devices. This provides assurance that the device is developed accordingly to standards of patient safety (Lindholm, Notander, & Höst, 2014). The software is verified and validated for compliance with regulations and standards in accordance with the US good manufacturing practices in Title 21 CFR Part 820 Quality System Regulation (Regan et al., 2013). As medical devices move from stand-alone to complex distributed systems for the treatment of patients, the development and validation techniques for safety-critical devices must address the safety and security of the software used in the device (Insup & Sokolsky, 2010). Off the shelf (OTS) software. The USFDA issued guidance in 1999 and again in 2005 concerning software used by manufacturers that is considered off the shelf (OTS) or an add-on that was not implemented during the SDLC (USFDA, 1999). The guidance addressed OTS software being implemented due to medical devices being vulnerable to malware. Manufacturers bear responsibility for OTS software performing safely in the device (USFDA, 2005). Regulations still apply to manufacturers which may require validation and approval for OTS software addressing a vulnerability of cyber security under 21 CFR 820.30 of QSR (USFDA, 2005). Encryption. The Federal Bureau of Investigation (FBI) and Apple made headlines due to the debate on encryption. Strong encryption provides advanced security that protects privacy but may also prevent access or retrieval by law enforcement of digital evidence needed to prosecute cybercriminals (IACP Summit Report, 2015). 45 CFR 164.312 of HIPAA technical safeguards states the use of encryption (addressable) is to be implemented for ePHI (Cornell Law School, n.d.b) in order to prevent unauthorized users from accessing confidential information. However, the Security Rule does not elaborate on the specifics of the technology to be implemented (HHS,
23
2007). The protection of PHI information serves two important purposes for a patient, including a right to privacy and safe care (Swim, 2012). The debate on encryption continues in the healthcare industry due to critical medical devices possibly impacting or compromising patient safety. Another aspect is the performance of the medical device with encryption and how clinician workflow may be altered due the usability of the electronic medical record (EMR) system (Schuman, 2014). However, encryption does provide another layer of protection by not allowing unauthorized access to the data (Swim, 2012). Although encryption enhances security of patient information, there needs to be a balance between privacy and safety. In the case of a patient emergency the risks may increase (Williams & Woodward, 2015). Tamper detection provides data authenticity that can be used to secure a physical device or software that will destroy or zero out all data upon tampering like incorrect decryption (Cappaert, Preneel, Anckaert, Madou, & De Bosschere, 2008). Anti-virus. Anti-virus software provides protection from malicious software (malware) that may potentially put the PHI information at risk or attempt to acquire authorized credentials (Swim, 2012). Anti-virus, if not implemented into the medical device design at an early phase, can impact clinician workflow. According to Fu and Blum (2014), an update to the anti-virus software caused disruption among the hospitals in Rhode Island. This impact in patient care was the result of a Windows file being misidentified as malicious as a result of the update. Anti-virus programs on average may take up to eleven days before detecting a threat, leaving an organization exposed during that time (Faronics, 2011). The size and power constraints of implantable medical devices limit the resources needed the ability for anti-virus software to function (Sametinger et al., 2015).
24
Authentication In 2017, ICS-CERT issued an advisory for an authentication vulnerability in which credentials could be used to exploit the application and gain access to unauthorized patient information from a cardiac imaging device (Kim, 2018). Medical device security is complicated due to a number of issues both technical and human. Incompatibility of legacy systems and lack of basic security features require updating software and patching vulnerabilities (Williams & Woodward, 2015). Research has shown the use of administrative hard coded default passwords to be a development issue for manufacturers during certification while the sharing of passwords between users violates security best practices (Williams & Woodward, 2015). The Security Rule under HIPAA safeguards the access of ePHI by authorized personnel based on their role (also known as role-based access) (HHS, 2013b). The use of wireless technology being implemented into medical devices found in hospitals, health clinics and doctor offices have become a major concern for DHS (Gonsalves, 2012). The USFDA document guidance states, "Because there are risks associated with radio frequency (RF) wireless systems, we recommend that you carefully consider which device functions should be made wireless and which device functions should employ wired connectivity" (Terry, para. 3, 2013). Role based access control (RBAC). The role based model allows for sets of different elements like roles and users to be associated with permissions to systems (Ferraiolo & Kuhn, 2004). An organization may assign a user a role based on their position, which provides access based on the privileges of the account. RBAC allows a user to login and authenticate based on the organization’s infrastructure, which then validates whether the role of the user is authorized (NIST, 2017b). The MDS2 form often supplied by the manufacturer also provides information if
25
RBAC is supported or can be implemented for security hardening of the device against unauthorized access (Stocker, 2016). Implantable devices. Implantable medical devices (IMD) can range from defibrillators to pacemakers, and can provide management of patient ailments due to varying health conditions. Traditional medical devices were either isolated or standalone systems not requiring connectivity for communication (Halperin, Kohno, Heydt-Benjamin, Fu, & Maisel, 2008). As the Internet of Things (IoT) continues to grow; increasing the need for tamper-detection technology for hardware, software, and firmware due to the vulnerability from cyberattacks (Aguayo Gonzalez, 2017). The technology has evolved to interconnected and wireless systems providing life savings devices to millions of patients in the United States (Halperin et al., 2008). The IMDs present new challenges in how to properly secure an embedded device within the human anatomy and how to access the device in case of an emergency. Heart to Heart (H2H) system is a physical device that must be in physical contact with the patient and provides authentication for updating or retrieving data from the device (Rostami, Juels, & Koushanfar, 2013). This new paradigm shift provides new challenges for privacy and security of IMDs that relate to the design of such devices and the authorization to access the device (Halperin et al., 2008) The United States Government Accountability Office (GAO) issued guidance in 2012 concerning the increasing use of wireless technology in medical devices. The guidance addressed software, access controls, and unauthorized access in accordance with the USFDA regulations for PMA and PMM (Kamesh & Sakthi Priya, 2014). Every year the USFDA collects information on medical device reports causing injury, death, or malfunction that continue to increase
26
(Sametinger et al., 2015). Research into medical reports about use of wireless IMDs is needed to establish any correlation. Threats. ICS-CERT issued an advisory regarding unauthorized access for wireless infusion pumps due to a remote vulnerability. The exploit allows for the device to be compromised and affect the operation of how the device normally functions (Kim, 2018). Other devices like heart pacemakers also suffer from cybersecurity concerns. In 2017, Abbott recalled nearly 500,000 devices before being implanted in patients due to vulnerability that would allow a hacker to access and control the speed of the device causing physical harm or even death to a patient (Armstrong, 2018). IMDs integration of IT within healthcare has provided security exposure and allowed cybercriminals to target these devices due to the maturity of cybersecurity (Symantec, 2016). The use of wireless and the Internet for the purpose of communicating information from medical devices to health systems has allowed for increased risk due to the open landscape. The responsibility of protecting patient information and functionality of the IMD now falls on the device manufacturers and well as health care providers (Williams & Woodward, 2015). Figure 4 below shows the sharing of responsibility for medical devices between manufacturers and health providers.
27
Figure 4 - Medical device shared responsibility for cybersecurity. Reprinted from Medical Device Security, In Symantec, 2016. Retrieved February 17, 2018, from https://www.symantec.com/content/dam/symantec/docs/data-sheets/symc-med-devicesecurity-en.pdf. Copyright 2016 by Symantec.
Challenges. The WannaCry ransomware attack introduced new cybersecurity challenges for device manufacturers by rendering devices inoperable and disrupting patient care (Nissim, Mahler, & Shalom, 2018). According to Perakslis (2014), a study found that over 90% of healthcare institutions have been a victim of cybersecurity attacks due in part to financial gain from theft of data or attacks on organization infrastructures and medical devices. Healthcare providers are encouraged to increase their involvement with the Office of the National Coordinator for Health Information Technology for regulatory framework risks due to current regulation being slow to act while financial costs are increasing (Perakslis, 2014). Research published by Protiviti and TrapX demonstrated how cyber attackers are exploiting medical devices to gain access to healthcare systems (Symantec, 2016). Other challenges include implementation of security without limiting performance of the device. The next generation of devices faces design challenges due to architecture and component limits such as batteries and processors (Kamesh & Sakthi Priya, 2014). This is further complicated due to the Spectre and Meltdown chip vulnerabilities from chipmakers Intel, AMD, and ARM (Graz University of Technology, 2018). Industry leaders continue testing performance based on 28
security patches released to address the vulnerabilities. The security patches affected performance while others created new problems for systems. On January 23 of this year, Intel advised original equipment manufacturers (OEMs) to not install or deploy the current patches relating to the Spectre and Meltdown vulnerabilities (Paganini, 2018). Microsoft released a security patch for operating systems Windows 7, 8.x, and 10. Discussion of the Findings The healthcare sector has faced numerous challenges as it has transitioned from paper to digital record keeping through the advancements of technology and the Internet. As the healthcare industry has adopted new technology like the Internet of Things (IoT), wireless and networked medical devices, in addition to mobile and web-based applications, the industry has fallen behind in the security of electronic protected health information (e-PHI). Clinical systems and medical devices have historically not been designed around the cyber security framework (Arney et al., 2011). Using systems the way they were designed often causes gaps in security. With the increased value of medical information, organizations need to find ways to properly assess vendors and devices before installing them. This paper examines the regulations and security features of medical devices by comparing the cyber security framework controls not designed with patient safety in mind. A patient’s privacy and safety may be jeopardized due to inadequate security that would enable malicious attacks using malware to compromise patient information or even worse cause physical harm (Arney et al., 2011). The research provided will address the following questions: What government regulations are needed to improve the security and safety standards for the medical device industry? Will medical devices support encryption and anti-virus? Are access controls like RBAC supported for authorization?
29
The presentation of material presented in the Literature Review was selected from scholarly journals, government agencies, organizations dealing with healthcare and standards, and news articles. The Discussion of the Findings will provide an overview of the Literature Review by addressing each of the three research questions, comparison of the findings to other studies, and limitations of the study. Through the Discussion of the Findings the reader will have a better understanding and the purpose of this research that will aid in future research. Research Question: What government regulations are needed to improve the security and safety standards for the medical device industry? The U.S. Congress has amended and passed legislation over the last century that dates back to the 1906 Pure Food and Drug Act (PFDA). Regulatory compliance evolved over the decades due to safety issues during the 60s and 70s for the prevention of physical injuries and deaths related to medical devices. The USFDA continued to revise regulations and also added new legislation which provided device reporting and a new classification system of medical devices. This introduced new controls to improve safety and efficacy of medical devices but failed to identify and address cybersecurity. The Executive Order 13636 signed by President Obama laid the foundation to address the cybersecurity threats of the U.S. critical infrastructure due in part to networks connecting to the Internet. The foundation continued to build as the NIST cybersecurity framework was developed which outlined industry guidelines for all 16 critical infrastructures. Both public and private industry stakeholders worked in conjunction to address standards and best practices (NIST, 2013). NIST published 800-61 that provided guidelines for handling computer systems involving hardware and software (Cichonski, et al., 2012). The NIST cybersecurity framework was a result of the passage of CISA due to federal organizations collaborating to establish cybersecurity
30
procedures. Threat information sharing between public and private entities provided beneficial information of threats between organizations of different critical infrastructure sectors. The passage of HIPAA in 1996, brought new legislation addressing how patient information could be accessed and transmitted electronically through new regulatory controls and standards (Kesan et al., 2005). The controls and standards addressed administrative, physical, and technical aspects of protecting electronic PHI (ePHI) addressed security and privacy concerns of patient information but not the safety of medical devices (Maisel & Kohno, 2010). HIPAA legislation focused on safeguarding patient information by implementing procedures, preventing unauthorized access, and securing received and transmitted information to maintain the confidentiality, integrity, availability of ePHI (HHS, 2013b). Medical devices transmit patient information but if the ePHI is not transmitted to a “covered entity” or business associate does it still fall under HIPAA legislation? Clearly in the HIPAA legislation medical devices are not mentioned which creates confusion among manufacturers and healthcare organizations. Another area of concern under HIPAA is if the wording used for technical security safeguards are addressable for ePHI (Cornell Law School, n.d.b). The specifics of the technology being implemented are not defined through standards under HIPAA which allows for varying interpretation of the security controls (HHS, 2007). HIPAA legislation provided necessary steps for cybersecurity of patient information and strengthened this enforcement through civil and criminal penalties under HITECH (HHS, 2016). Other standards like ISO/IEC address both safety and security standards for medical devices. These standards are implemented under the USFDA compliance to address patient safety, device safety, and recommended security. The ISO/IEC 27032 provides a cybersecurity guideline for Internet and network security and best practices in cyberspace (ISO, 2012).
31
Manufacturers face complicated compliance standards to bring a medical device to market that does not require cybersecurity controls. This issue along with the WannaCry ransomware brought new concerns for the AHA in regards to medical device security and manufacturers not being held accountable (AHA, 2017). The AHA also highlighted concerns that medical device security needed oversight to be effective. The USFDA compliance and HIPAA legislation have both taken steps in addressing cybersecurity of medical devices but have different implementations. Patient safety is the main focus for the USFDA with mandatory compliance but lacks required security controls due to safety concerns. Contrary to the USFDA, HIPAA legislation addresses cybersecurity in electronic transmissions of ePHI but does not define the technology. The disparity becomes clear that a medical device brought to market takes time to meet compliance standards and submissions for safety but may not implement security. Research Question: Will medical devices support encryption and anti-virus? As biomedical and IT advanced, medical devices became smaller in size and evolved from embedded stand-alone systems to adopting IT features (Sametinger et al., 2015). This allowed medical devices to interconnect with other systems and devices in the healthcare sector. As medical devices advanced with IT features for the treatment of patient care, so did the number of vulnerabilities and exploits to compromise them (Williams & Woodward, 2015). Due to the slow implementation of patches for medical devices, organizations must address security and best practices to prevent a breach (White, 2015). Guidance was issued by the USFDA with recommendations from ICS-CERT for healthcare institutions and organizations to implement cybersecurity controls such as patching, anti-virus, and unauthorized access. The USFDA also issued guidance for manufacturers to address cybersecurity controls in the design
32
phase (Fu & Blum, 2014). Manufacturers face challenges due to life critical systems that rely on software needed to maintain security without disrupting the care of the patient. Clinical testing and validation of medical devices are performed by the manufacturer but the USFDA allows a manufacturer to use add-ons like OTS. This creates another loophole where a medical device is required to be tested and validated but OTS is the responsibility of the manufacturer. The QSR which is applied under 21 CFR part 820, covering quality controls that the manufacturer must meet for compliance, is an example of this (Cornell Law School, n.d.a). The implementation of SDLC provides standards for implementing critical safety measures into medical devices (Lindholm et al., 2014). The USFDA requirements must be met by device manufacturers for safety compliance of the device but does not mandate required security controls. Patient safety and assurance during the design phase allows implementation of standards to follow for validation and verification of software against regulations (Regan et al., 2013). This allows software design for medical devices that revises the code to eliminate exploits and vulnerabilities. Encryption is another issue that arises due to the impact on clinician workflow from performance of an EHR or medical device (Schuman, 2014). Manufacturers may opt to use encryption as an OTS if not designed into the SDLC. The USFDA approval process does not require encryption in order to meet regulatory compliance. Federal organizations recognize and publish guidance of cybersecurity measures, but manufacturers are not required to implement cybersecurity during the design phase or testing and validation of their product (Miliard, 2016). Anti-virus provides protection from malware that may compromise PHI through ransomware or by acquiring authorized credentials to access the information. The limitation of resources for implantable medical devices may not provide functionality for anti-virus
33
(Sametinger et al., 2015). Although anti-virus can thwart potential risks, it can also impact patient care and disrupt clinician workflow. Another issue is that anti-virus can create the inability to identify a malicious threat due to definitions not being up to date that may expose the organization (Faronics, 2011). Encryption and anti-virus software are considered OTS if not implemented by the manufacturer during the SDLC. The manufacturer may need to provide validation testing under the USFDA regulatory compliance although OTS is a recommended cybersecurity measure. The manufacturer has the option (but is not required) to implement the security measures. Many manufacturers are not considered “covered entities” under HIPAA. The manufacturer may fall under HIPAA compliance requirements if they are considered a business associate or if a covered entity shares PHI with a medical device company. Alternatively a medical device manufacturer or vendor may not be required to be HIPAA compliant outside of any USFDA regulations. Research Question: Are access controls like RBAC supported for authorization? Authentication of an authorized person(s) accessing PHI requires credentials to be validated in order to access the information. Research has shown that legacy medical devices lack current security features that are vulnerable to exploits (Williams & Woodward, 2015). The HIPAA Security Rule implemented role-based access as a safeguard for the prevention of unauthorized entities from accessing ePHI (HHS, 2013b), but medical device manufacturers may not fall under HIPAA. RBAC allows for elements to be assigned to different roles based on the account privileges of the individual’s position. This provides authorized access to ePHI that is authenticated based on the credentials provided. Authentication vulnerabilities have been identified by ICS-CERT in medical devices allowing patient information to be accessed (Kim,
34
2018). The research examined by Terry (2013) highlights the acknowledgment from the USFDA that RF wireless risks do exist. The DHS also acknowledged the risks of wireless and authentication (Gonsalves, 2012). The DHS, ICS-CERT, and USFDA organizational concern over wireless technology and authentication vulnerability is a step forward in addressing cybersecurity. While the vulnerabilities are identified, the USFDA does not mandate required steps to address the concerns but only provides recommended guidance which may not be followed by manufacturers. Stand-alone and isolated medical device authentication changed due to communications requiring connectivity to other systems. As medical devices adopted IT features like wireless, new challenges emerged due to the privacy and security concerns of authorization to access the device (Halperin et al., 2008). Sametinger et al, (2015) recognized that under HIPAA network infrastructure must comply with privacy. This provides assurance that patient privacy is met for healthcare organizations. IMDs increasing use of wireless prompted the GAO to issue provided guidance under the USFDA approval pathway PMA and PMM for unauthorized access (Kamesh & Sakthi Priya, 2014). The USFDA guidance concerning privacy and security concerns in the approval process is not mandatory for compliance and only addresses the concerns in written statements of guidance. Authentication vulnerabilities demonstrated by Protiviti and TrapX showed how cyber attackers gain unauthorized access to healthcare provider systems (Symantec, 2016). The recall of nearly half a million pacemakers was also due to a vulnerability that allowed an attacker the ability to cause physical harm to a patient or compromise the device. While authentication vulnerabilities have been identified in various IMDs, manufacturers are slow in implementing fixes. White (2015) suggests only working with manufacturers or vendors that implement the
35
necessary security features into their devices. This may be an option for organizations to only purchase medical devices with security but what impact will this have on patient care if a specific device does not have security? Another concern is that specialized medical devices may only be provided by a few manufacturers which may not offer security features. Comparison of the Findings to Other Studies The research material presented throughout this study offers confirmation that healthcare organizations need to assess the risks of medical devices in which cybersecurity best practices are not implemented due to safety regulations and limitations on device manufacturers. This study only focused on a few cybersecurity controls for the protection of patient information, whether or not the controls were supported, and if not, what are the challenges? The findings suggest that patient safety is the top priority for medical devices although more research and testing is needed for implementing cybersecurity controls. The study also found a lack of cybersecurity controls for medical devices regarding encryption, anti-virus, and RBAC authentication, due to varying legislation and regulatory requirements. Individual researchers are currently conducting studies on medical device security. These studies focus on different aspects and interests from assessing vulnerabilities, to authorization, regulation and privacy challenges, wireless implantable medical devices, software and design, and security challenges. The researchers have identified sufficient circumstances of risk pertaining to patient safety, healthcare organizations, and medical devices being compromised. The existing research addresses the cybersecurity issues of medical devices and the impact it has on the healthcare sector including patients. The research material presented provides data that pertains to cybersecurity controls not being implemented due to the administrative, physical, and
36
technical limitations of medical device manufacturers and vendors, U.S. regulations and compliance, and lack of cybersecurity controls being designed into the device. Limitations of the Study The research conducted for this study presented limitations of the material presented. The U.S regulations and legislations research appeared to be limited to specific regulations like HIPAA or the USFDA medical device approval cycle. Other research only focused on regulation requirements for compliance and how patient information is transmitted and stored. Another limitation of the research was due to the interpretation of regulatory compliance and legislation from government organizations. The HIPAA and HITECH limitation was a result of medical devices not being addressed, only the aspects concerning the transmission and receiving of ePHI, PHI, and EHR. Medical device security presented other limitations due to the types of devices and security controls. Information and research about implantable medical devices was plentiful but was mostly focused on pacemakers, pumps, and defibrillators, concerning wireless communication challenges for authentication or software vulnerabilities. Studies from individual researchers on medical devices was also abundant but focused primarily on specific security limitations or specific devices. There also appeared to be very little research from government organizations on cybersecurity of medical devices. The lack of research and studies performed by medical device manufacturers appears to be non-existent. Recommendations and Conclusion Medical devices have continued to evolve from stand-alone systems to embedded systems to complex distributed network systems used in the healthcare sector for treatment and care of patients. Although the advancement of these systems through technology and medicine
37
have provided patients with improved care and treatment, cybersecurity measures have not kept pace due in part to federal regulatory compliance and the recommended guidance not addressing specific technical measures for the protection of patient information. The Recommendations section will offer suggestions in accordance with the research questions on how to address cybersecurity controls of medical devices. The material will address the USFDA medical device approval process, HIPAA, and SDLC. USFDA Medical Device Approval Process The USFDA provides regulatory oversight and guidance for the safety and security of medical devices. Guidance from the USFDA has addressed security patching, anti-virus software, restriction of unauthorized access, and security implementation into the design phase (Fu & Blum, 2014). Although the recommended guidance does address cybersecurity concerns, it does not fundamentally require a device manufacturer to adhere or follow these guidelines. A manufacturer currently has the option to adhere to or disregard the recommendations by the USFDA due to the guidance being voluntary and not mandated as part of the regulatory compliance for device approval. Another example of recommended guidance by the USFDA is for manufacturers to incorporate the NIST security framework into medical devices. The medical device approval process demonstrates the loopholes of implementing cybersecurity controls. The PMA requires device manufacturers to submit clinical testing as evidence that the device is safe for use in regards to patient care. The manufacturer may present findings that do not incorporate cybersecurity controls due to jeopardizing the overall safety of the device. This allows manufacturers the ability to decide whether or not to implement cybersecurity into their devices while still meeting quality and safety regulations. The PMS further complicates the cybersecurity issue by not requiring controls and measures to be
38
implemented but only provides manufacturers with recommendations that may provide additional safety and security of the device and patient. A manufacturer may not be able to address vulnerabilities and exploits that have yet to evolve, but the PMM allows them to be addressed in the future through the use of patching or add-ons like OTS for anti-virus. The PMM offers another loop hole in whether or not a manufacturer is required to recertify the medical testing of the device. The USFDA does not require any type of review for changes made to address or strengthen cybersecurity of the device. Software validation is required by manufacturers for any software or design changes for cybersecurity of medical devices. This presents a conflict for validation of the device which may introduce risks to the functionality of the device, or even worse, compromise patient safety. The USFDA medical device approval process needs to be updated and/or amended to address cybersecurity issues facing medical devices in the present and near future. An amendment could entail changing the recommendations of cybersecurity measures to “required”, which means manufacturers will be forced to address not only patient safety but security of the device as well. The amendment should also require best security practices and security controls being implemented into the device based on ICS and NIST publications being adopted by manufacturers and vendors. HIPAA The HIPAA legislation prioritizes security and privacy of patient information whereas the USFDA focuses on safety of the device with cybersecurity recommendations. Health information is protected under the HIPAA Security Rule using safeguards for electronic transmissions of ePHI for accessing, transmitting, and receiving. HIPAA does not address cybersecurity of medical devices but rather focuses on controls and standards for “covered entities” using patient
39
information (Maisel & Kohno, 2010). Networked medical devices process ePHI by transmitting or receiving the information to and from other systems within a healthcare’s network. The healthcare organization must adhere to the standards and controls under HIPAA due to being a “covered entity” for ePHI protection within the organization’s network. The organization is responsible for the security of patient information even if the medical devices lack cybersecurity controls and defensive measures. Under HIPAA the protection of patient information shifts the responsibility from device manufacturers to the healthcare systems due to the fact that many manufacturers do not transmit or receive ePHI. This presents a loophole in the HIPAA legislation that requires the healthcare industry to address cybersecurity of medical devices and the challenges of securing due to the USFDA regulations not requiring manufacturers to implement cybersecurity controls. Healthcare organizations must evaluate and design solutions to protect patient information in medical devices. Although HIPAA does not address cybersecurity of medical devices, healthcare organizations inherit this burden of protecting unsecure devices due to cyberattacks or breaches of the organization that may result in financial and reputational harm to the organization. The USFDA voluntary cybersecurity requirements and HIPAA’s lack of addressing medical devices puts healthcare organizations in a vulnerable position requiring additional resources to address legislation inadequacies. The healthcare sector may take additional steps by performing security assessments of medical device manufacturers and may only deal with those vendors implementing cybersecurity into their devices. The HIPAA legislation may also need to be updated and/or amended to include medical devices that transmit or receive ePHI. Although HIPAA already addresses devices under “covered entity” or “business associate,” the legislation is not clear concerning medical devices.
40
The amendment could invoke security requirements for medical device manufacturers to implement into their devices. Failure to comply could result in financial penalties for any patient information compromised from breaches of medical devices. This would redistribute responsibility to the healthcare organizations, device manufacturers, and vendors. The amendment would address device manufacturers not implementing security controls that other devices manufacturers already implement into laptops, computers, and smartphones that transmit ePHI. SDLC Security controls like anti-virus, encryption, and RBAC authentication have been identified through publications, guidelines, and best practices from NIST, HIPAA, CIS, USFDA and other institutions for addressing cybersecurity of medical devices. NIST and CIS address these security measures through frameworks and best practices although the USFDA and HIPAA do not require NIST and CIS to be implemented but rather only recommend their use. The lack of security controls is due in part to patient safety and efficacy of the medical device. These controls may be implemented using the SDLC process to incorporate security controls into the design phase, allowing assurances through validation and testing that patient safety meets compliance while eliminating security vulnerabilities of medical devices (Regan et al., 2013). Manufacturers would be able to comply with USFDA regulations and also provide healthcare organizations the ability to comply under HIPAA without additional resources needed to secure medical devices for patient care. This in turn would provide manufacturers the ability to update and maintain security on medical devices using validated testing measures that were designed into the device.
41
SDLC being a requirement for security controls would allow device manufactures the ability to test and validate the functionality of the device with regards to safety and security. This would ensure the protection of patient information by using encryption, anti-virus, RBAC, and other security controls are supported instead of using OTS, which may compromise the function of the medical device. Manufacturers would also be able to implement a means to safely update medical devices vulnerable to exploits in an efficient manner, using the SDLC process. The healthcare sector has faced numerous challenges as it has transitioned from paper to digital record keeping through the advancements of technology and the Internet. As the healthcare industry has adopted new technology like the Internet of Things (IoT), wireless and networked medical devices, in addition to mobile and web-based applications, the industry has fallen behind in the security of electronic protected health information (e-PHI). Clinical systems and medical devices have historically not been designed around the cyber security framework (Arney et al., 2011). Using systems the way they were designed often causes gaps in security. With the increased value of medical information, organizations need to find ways to properly assess vendors and devices before installing them. This paper examines the regulations and security features of medical devices by comparing the cyber security framework controls not designed with patient safety in mind. A patient’s privacy and safety may be jeopardized due to inadequate security that would enable malicious attacks using malware to compromise patient information or even worse cause physical harm (Arney et al., 2011). The research provided will address the following questions: What government regulations are needed to improve the security and safety standards for the medical device industry? Will medical devices support encryption and anti-virus? Are access controls like RBAC supported for authorization?
42
The research topics addressed different elements of medical device cybersecurity. The government regulations and legislations of the USFDA and HIPAA showed disparity between cybersecurity requirements and recommendations for medical devices. The USFDA and ISO/IEC do address cybersecurity standards and best practices through the issuance of guidelines (ISO, 2012). These guidelines are voluntary and do not require medical device manufacturers to follow them. Contrary to the USFDA, HIPAA does require cybersecurity for the transmission of ePHI but does not elaborate on the specific technical controls to be implemented nor address medical devices. The NIST cybersecurity framework is recommended by both the USFDA and HIPAA for all healthcare organizations to adopt. These discrepancies allow medical device security to be interpreted as voluntary rather than required which may risk a patient’s safety from a medical device. The demonstration by Protiviti and TrapX identified the need for cybersecurity to be implemented within medical devices (Symantec, 2016). Additional cybersecurity concerns were confirmed when the WannaCry ransomware compromised medical devices. While the IoT continue to grow and patient care continually relies on the benefits of these life saving devices, so do the security issues. Security measures and controls need to be addressed due to the rapid paradigm shift of wireless IMDs. The risk of cyber attackers exploiting medical device security to access healthcare providers is the path of least resistance. Future Research Recommendations New Research Question 1: How to Design Security into the Design Phase of SDLC? Implementation of security from a design phase is more logical than bolting on additional pieces of untested software and controls. The SDLC process would allow for the identification of security gaps in medical devices and allow for a model that minimizes vulnerabilities through
43
testing, patching, and retesting of the device with security controls. This would provide assurances that not only safety is addressed but security is as well. Further research and case studies are needed regarding implementing SDLC with and without security controls for medical devices. This would allow researchers to test medical devices with security for comparison of results and findings to devices without security. Researchers may also demonstrate testing of similar devices incorporating security by design between different device manufacturers in order to determine gaps and inefficiencies between design models. These findings could then be used by industry experts and stakeholders to refine and establish requirements into the design, implementation, verification and validation phases of the model that meet regulations and standards (Regan et al., 2013). Research is needed with regard to standardizing software design with security in mind that would allow for better testing and verification of similar devices so manufacturers could collaborate and share resources. New Research Question 2: Why are Case Studies limited to Researchers? The lack of research and studies performed by medical device manufacturers appears to be non-existent. Industry leaders and experts provide expertise and knowledge that government organizations could use for further studies and validation of security controls. A program incorporating manufacturers, researchers, and colleges would allow manufacturers to benefit from graduate students conducting tests and theories on medical devices. This would provide much needed information and studies on cybersecurity of medical devices. Graduate students would gain research experience into their field of study while industry experts provide oversight and publications of the findings. This in turn would allow manufacturers to address or mitigate issues overlooked or alter designs to address the findings. Government organizations would have
44
substantial evidence and findings from research and case studies in addition to the manufacturers clinical testing and validation, which would support the safety and security of medical devices. New Research Question 3: How to Improve Testing of Security Controls? Cybersecurity controls need to be tested and verified in order to not jeopardize the safety and security of the medical device and the patient. Validation testing is needed to ensure proper functionality of the device. Research is needed to establish proper testing techniques of medical devices to discover coding errors, flaws, bugs, or vulnerabilities from design. Third parties accredited as certified authorities may provide additional testing of medical devices to ensure safety and security assurances are met. Using certified labs this would allow for security controls like encryption, anti-virus, and RBAC to be fully tested using penetration testing and exploits to verify the device maintains functionality without being compromised. Testing of the individual security controls will provide specific testing and identification of which controls may need revision. This allows for specific controls to be individually tested and measured for safety issues allowing for an overall assessment of the device with breakdown of each specific control.
45
References Abdur, M., Habib, S., Ali, M., & Ullah, S. (2017). Security Issues in the Internet of Things (IoT): A Comprehensive Study. International Journal of Advanced Computer Science and Applications, 8(6), 383–388. https://doi.org/10.14569/IJACSA.2017.080650 Aguayo Gonzalez, C., R. (2017). A Trust Platform for IoT. Department of Homeland Security. Retrieved from https://www.dhs.gov/sites/default/files/publications/CSD_2017TechGuide_web_020317_ 508_Final.pdf American Hospital Association. (2017). RE: Docket Number FDA-2017-N-5093, Review of Existing General Regulatory and Information Collection Requirements of the Food and Drug Administration; Proposed Rule (Vol. 82, No. 42506). Retrieved from https://www.aha.org/system/files/advocacy-issues/letter/2017/171207-let-aha-fdaregulation-device-security.pdf American Hospital Association. (2018). Medical Devices and Cyber Issues. Retrieved from https://www.aha.org/sites/default/files/2018-01/20180123-cybesecurity-medical-deviceswebinar.pdf American Journal of Roentgenology. (1995). The first clinical X-ray made in America—100 years. Retrieved from https://doi.org/10.2214/ajr.164.1.7998549 Anderson, S., & Williams, T. (2018). Cybersecurity and medical devices: Are the ISO/IEC 80001-2-2 technical controls up to the challenge? Computer Standards and Interfaces, 56(56), 134–143. https://doi.org/10.1016/j.csi.2017.10.001 Anthony, S. (2011). Full disk encryption is too good, says US intelligence agency. Extreme Tech. Retrieved from https://www.extremetech.com/computing/105931-full-disk-
46
encryption-is-too-good-says-us-intelligence-agency Armstrong, R. (2018). Five big medical device recalls. Medical Plastic News. Retrieved fromhttps://www.medicalplasticsnews.com/news/five-big-medical-device-recalls/ Arney, D., Venkatasubramanian, K., Sokolsky, O., Lee, I., & Venkatasubramanian, K. K. (2011). Biomedical Devices and Systems Security. Engineering in Medicine and Biology Society, (11), 2376–2379. https://doi.org/10.1109/IEMBS.2011.6090663 Association for the Advancement of Medical Instrumentation. (2016). Proposal to add revision of IEC 62304, Health software – Software life cycle processes, to the work program of ISO/TC 215 and IEC/SC 62A with expanded scope. Retrieved from https://standards.aami.org/higherlogic/ws/public/download/9432 Blakley, B., McDermott, E., & Geer, D. (2001). Information security is information risk management. NSPW ’01 Proceedings of the 2001 Workshop on New Security Paradigms, 97–104. https://doi.org/10.1145/508185.508187 Cappaert, J., Preneel, B., Anckaert, B., Madou, M., & De Bosschere, K. (2008). Towards tamper resistant code encryption: Practice and experience. Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 4991 LNCS, 86–100. https://doi.org/10.1007/978-3-540-79104-1_7 Center for Internet Security. (2018). CIS Controls FAQ. Retrieved from https://www.cisecurity.org/controls/cis-controls-faq/ Cichonski, P., Millar, T., Grance, T., & Scarfone, K. (2012). Computer Security Incident Handling Guide. National Institute of Standards and Technology. Special Publication (NIST SP) - 800-61 Revision 2. Retrieved from https://www.nist.gov/publications/computersecurity-incident-handling-guide 47
Cloud Security Alliance. (2016). Future-proofing the Connected World: 13 Steps to Developing Secure IoT Products. IoT Working Group. Retrieved from https://downloads.cloudsecurityalliance.org/assets/research/internet-of-things/futureproofing-the-connected-world.pdf Colarik, A. M., & Janczewski, L. J. (2009). Introduction to Cyber Warfare and Cyber Terrorism. Database Technologies: Concepts, Methodologies, Tools, and Applications. https://doi.org/10.4018/978-1-59140-991-5.ch038 Cornell Law School. (n.d.a) 21 CFR Part 820 – Quality System Regulation. Retrieved from https://www.law.cornell.edu/cfr/text/21/part-820 Cornell Law School. (n.d.b) 45 CFR 164.312 – Technical safeguards. Retrieved fromhttps://www.law.cornell.edu/cfr/text/45/164.312 Department of Homeland Security. The 2013 Cybersecurity Executive Order: Overview and Considerations for Congress. Retrieved from https://fas.org/sgp/crs/misc/R42984.pdf Doctorow, C. (2016). Postmarket Management of Cybersecurity in Medical Devices. Guidance for Industry and Food and Drug Administration Staff. USFDA. Retrieved from https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedoc uments/ucm482022.pdf Faronics. (2011). Blacklist-based Software versus Whitelist-based Software. Retrieved from http://www.faronics.com/assets/blacklisting_whitelisting.pdf Ferraiolo, D. F., & Kuhn, D. R. (2004). Role Based Access Control. Review Literature And Arts Of The Americas, 14(ANSI INCITS 359-2004), 554–563. https://doi.org/10.1016/01674048(95)97115-Q Fischer, E. A., Liu, E. C., Rollins, J. W., & Theohary, C. A. (2013). The 2013 Cybersecurity
48
Executive Order: Overview and Considerations for Congress. Congressional Research Service, CRS Report No. 7-5700, 1–22. Retrieved from http://www.fas.org/sgp/crs/misc/R42984.pdf Fox-Brewster, T. (2017). Medical Devices Hit By Ransomware For The First Time In US Hospitals. Forbes. Retrieved from https://www.forbes.com/sites/thomasbrewster/2017/05/17/wannacry-ransomware-hit-realmedical-devices/#793419ea425c Fu, K., & Blum, J. (2014). Controlling for cybersecurity risks of medical device software. Biomedical Instrumentation and Technology, 48(HORIZONS SPRING), 38–41. https://doi.org/10.2345/0899-8205-48.s1.38 Fuentes, M. R. (2017). Cybercrime and Other Threats Faced by the Healthcare Industry. Trend Micro. Retrieved from https://documents.trendmicro.com/assets/wp/wp-cybercrime-andother-threats-faced-by-the-healthcare-industry.pdf Graz University of Technology. (2018). Meltdown and Spectre. Retrieved from https://meltdownattack.com/ Goertzel, K. M. (2008). Enhancing the Development Life Cycle To Produce Secure Software. Crosstalk, September(September), 24–25. https://doi.org/10.1007/978-1-4302-2615-4 Gonsalves, A., (2012). Wireless Tech Makes Health Care Security a 'Major Concern'. PC World Retrieved from https://www.pcworld.com/article/255841/wireless_tech_makes_health_care_security_a_maj or_concern.html Halperin, D., Kohno, T., Heydt-Benjamin, T. S., Fu, K., & Maisel, W. H. (2008). Security and privacy for implantable medical devices. Pervasive Computing, IEEE, 7(1), 30–39.
49
https://doi.org/10.1109/MPRV.2008.16 HealthCare Headlines. (2015). 80 million records breached in anthem hacker attack. Pt in Motion, 7(3), 51. Retrieved from http://web.b.ebscohost.com.ezproxy.utica.edu/ehost/pdfviewer/pdfviewer?vid=1&sid=5f44c 013-ce6f-4a07-8c39-d3a3abd37650%40sessionmgr103 HIPAA Journal. (n.d.) HIPAA History. Retrieved from https://www.hipaajournal.com/hipaahistory/ HITRUST. (2018). About Us. Retrieved from https://hitrustalliance.net/about-us/ IACP Summit Report. (2015). Data, Privacy and Public Safety: A Law Enforcement Perspective on the Challenges of Gathering Electronic Evidence. Retrieved from http://www.theiacp.org/portals/0/documents/pdfs/IACPSummitReportGoingDark.pdf Industrial Control Systems Cyber Emergency Response Team. (2013). Alert (ICS-ALERT-13164-01). Retrieved from https://ics-cert.us-cert.gov/alerts/ICS-ALERT-13-164-01 Institute of Medicine. (2011). Medical Devices and the Public's Health: The FDA 510(k) Clearance Process at 35 Years. Retrieved from https://www.nap.edu/read/13150/chapter/10 Insup, L., & Sokolsky, O. (2010). Medical Cyber Physical Systems. In Proceedings of the 47th Design Automation Conference (DAC), ACM/IEEE (pp. 743–748). https://doi.org/10.1145/1837274.1837463 International Electrotechnical Commission. (2018). IEC 61010-1:2010. Retrieved from https://www.iecee.org/dyn/www/f?p=106:49:0::::FSP_STD_ID:4279 International Standards Organization. (n.d.) How we develop standards. Retrieved from https://www.iso.org/developing-standards.html
50
International Standards Organization. (n.d.) Structure and governance. Retrieved from https://www.iso.org/structure.html International Standards Organization. (2002). ISO 13485:2003(en) Medical devices – Quality management systems – Requirements for regulatory purposes. Retrieved from https://www.iso.org/obp/ui/#iso:std:iso:13485:ed-2:v1:en International Standards Organization. (2006). IEC62304:2006(en) Medical device Software – Software life cycle processes. Retrieved from https://www.iso.org/obp/ui/#iso:std:iec:62304:ed-1:v1:en International Standards Organization. (2007). ISO 14971:2007(en) Medical devices – Application of risk management to medical devices. Retrieved from https://www.iso.org/obp/ui/#iso:std:iso:14971:ed-2:v2:en:sec:E International Standards Organization. (2012). ISO/IEC 27032:2012(en) Information technology – Security techniques – Guidelines for cybersecurity. Retrieved from https://www.iso.org/obp/ui/#iso:std:iso-iec:27032:ed-1:v1:en International Standards Organization. (2016). IEC80001-2-8:2016(en) Applicationof risk management for IT-networks incorporating medical devices – Part 2-8: Application guidance – Guidance on standards for establishing the security capabilities identified in IEC. Retrieved from https://www.iso.org/obp/ui/#iso:std:iec:tr:80001:-2-8:ed-1:v1:en Johnson, J. A. (2016). FDA regulation of medical devices. CRS Report for Members and Committes of Congress, 1–49. https://doi.org/10.1097/00004669-198107000-00005 Kamesh, & Sakthi Priya, N. (2014). Security enhancement of authenticated RFID generation. International Journal of Applied Engineering Research, 9(22), 5968–5974. https://doi.org/10.1002/sec
51
Keller, J. P. (2017). Patient safety implications with the rapid adoption of IT ‑ based health technologies. Digital Medicine, 3(3), 115–119. Kesan, J. P., Majuca, R., & Yurcik, W. (2005). Cyberinsurance As A Market-Based Solution to the Problem of Cybersecurity - A Case Study. Fourth Workshop on the Economics of Information Security, 2(November), 97–120. Kim, L. (2018). Healthcare and Cross-Sector Cybersecurity Report. Healthcare and CrossSector Cybersecurity Report, 19(January), 1–5. Retrieved from www.himss.org/cyberreport Lee, I., Sokolsky, O., Chen, S., Hatcliff, J., Jee, E., Kim, B., … Venkatasubramanian, K. K. (2012). Challenges and Research Directions in Medical Cyber-Physical Systems. Proceedings of the IEEE, 100(1), 75–90. https://doi.org/10.1109/JPROC.2011.2165270 Library of Congress. (n.d.). S.754-Cybersecurity Information Sharing Act of 2015. Retrievedfrom https://www.congress.gov/bill/114th-congress/senate-bill/754 Lindholm, C., Notander, J. P., & Höst, M. (2014). A case study on software risk analysis and planning in medical device development. Software Quality Journal, 22(3), 469–497. https://doi.org/10.1007/s11219-013-9222-2 Maisel, W. H., & Kohno, T. (2010). Improving the security and privacy of implantable medical devices. The New England Journal of Medicine, 362(13), 1164–6. https://doi.org/10.1056/NEJMp1000745 Miliard, M. (2016). Report calls out weak FDA syance on medical device cybersecurity, favors stronger regulation. Healthcare IT News. Retrieved from http://www.healthcareitnews.com/news/report-calls-out-weak-fda-stance-medical-devicecybersecurity-favors-stronger-regulation
52
Met Labs. (2018). Medical Testing. Medical Devices: Evidence and Research, 8, 305–316. https://doi.org/10.2147/MDER.S50048 National Institute of Biomedical Imaging and Bioengineering. (n.d.) X-rays. Retrieved from https://www.nibib.nih.gov/science-education/science-topics/x-rays National Institute of Standards and Technology. (2013). Oversight of Executive Order 13636 and Development of the Cybersecurity Framework. Retrieved fromhttps://www.nist.gov/speechtestimony/oversight-executive-order-13636-and-development-cybersecurity-framework National Institute of Standards and Technology. (2017). About NIST. Retrieved from https://www.nist.gov/about-nist National Institute of Standards and Technology. (2017b). Role Based Access Control. Retrieved from https://csrc.nist.gov/Projects/Role-Based-Access-Control Nissim, N., Mahler, T., & Shalom, E. (2018). Know Your Enemy : Characteristics of CyberAttacks on Medical Imaging Devices. arXiv preprint arXiv:1801.05583 Perakslis, E. D. (2014). When “Hacktivists” Target Your Hospital. New England Journal of Medicine, 371(5), 395–397. https://doi.org/10.1056/NEJMp1407326 Paganini, P. (2018). Meltdown and Spectre Patches: a story of delays, lies, and failures. Infosec Institute. Retrieved from http://resources.infosecinstitute.com/meltdown-spectre-patchesstory-delays-lies-failures/#gref Rakitin, S. R. (2006). Coping with Defective Software in Medical Devices. Computer, 39(4), 40– 45. Retrieved from https://pdfs.semanticscholar.org/85db/1b0144cc6fa24f86edcf30c70741c671ca63.pdf Regan, G., McCaffery, F., Mc Daid, K., & Flood, D. (2013). Medical device standards’ requirements for traceability during the software development lifecycle and implementation
53
of a traceability assessment model. Computer Standards and Interfaces, 36(1), 3–9. https://doi.org/10.1016/j.csi.2013.07.012 Rostami, M., Juels, A., & Koushanfar, F. (2013). Heart-to-Heart (H2H): Authentication for Implanted Medical Devices. In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security - CCS ’13 (pp. 1099–1112). https://doi.org/10.1145/2508859.2516658 Sametinger, J., Rozenblit, J., Lysecky, R., & Ott, P. (2015). Security challenges for medical devices. Communications of the ACM, 58(4), 74–82. https://doi.org/10.1145/2667218 Schuman, E. (2014). Why does healthcare resist encryption? Healthcare IT News. Retrieved from http://www.healthcareitnews.com/news/why-does-healthcare-resist-encryption Snell, E. (2015). Anthem Health Data Breach Could Compromise PII of 80M. HealthIT Security. Retrieved from https://healthitsecurity.com/news/anthem-health-data-breach-couldcompromise-pii-of-80m Snell, E. (2017). How FDA Medical Device Cybersecurity Guidance Affects Providers. HealthIT Security. Retrieved from https://healthitsecurity.com/features/how-fda-medical-devicecybersecurity-guidance-affects-providers Stocker, D. (2016). MEDICAL DEVICES : SAFE , BUT ARE THEY SECURE ? Coalfire. Retrieved from https://www.coalfire.com/Resources/White-Papers/Medical-Device-Safe,But-are-they-Secure Sussman, M. (n.d.) Medical Device Development and Evolution: A comparative Study. Hydrocephalus Association. Retrieved from https://www.hydroassoc.org/medical-devicedevelopment-and-evolution-a-comparative-study/ Swim, R. (2012). Protected Health Information And Medical Equipment. Biomedical
54
Instrumentation & Technology, 46(4), 278–280. Symantec. (2016). Medical Device Security. Retrieved from https://www.symantec.com/content/dam/symantec/docs/data-sheets/symc-med-devicesecurity-en.pdf Terry, K., (2013). FDA Issues Guidelines On Wireless Medical Devices. Information Week Retrieved from https://www.informationweek.com/mobile/fda-issues-guidelines-onwireless-medical-devices/d/d-id/1111203 U.S. Department of Health & Human Services. (2007). HIPAA Security Series, 4 Security Standards: Technical Safeguards. Retrieved from https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/techsaf eguards.pdf U.S. Department of Health & Human Services. (2013a). Breach Notification Rule. Retrieved from https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html U.S. Department of Health & Human Services. (2013b). Summary of the HIPAA Security Rule. Retrieved from https://www.hhs.gov/hipaa/for-professionals/security/lawsregulations/index.html U.S. Department of Health & Human Services. (2016). HITECH Act Enforcement Interim Final Rule. Retrieved from http://www.hhs.gov/hipaa/for-professionals/special-topics/HITECHact-enforcement-interim-final-rule/ U.S. Food and Drug Administration. (1999). Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices. Retrieved from https://www.fda.gov/downloads/MedicalDevices/.../ucm073779.pdf
55
U.S. Food and Drug Administration. (2005). Guidance for Industry, Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software. Retrieved from https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/Guidance Documents/ucm077823.pdf U.S. Food and Drug Administration. (2014). Content of Premarket Submissions for Management of Cybersecurity in Medical Devices. Retrieved from https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocu ments/ucm356190.pdf U.S. Food and Drug Administration. (2015a). The FDA Modernization Act of 1997. Retrieved from https://www.fda.gov/RegulatoryInformation/LawsEnforcedbyFDA/SignificantAmendmentst otheFDCAct/FDAMA/ucm089179.htm U.S. Food and Drug Administration. (2015b). Overview of Device Regulation. Retrieved from https://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/Overview/ U.S. Food and Drug Administration. (2016a). Cybersecurity. Retrieved from https://www.fda.gov/MedicalDevices/DigitalHealth/ucm373213.htm U.S. Food and Drug Administration. (2016b). Postmarket Management of Cybersecuirty in Medical Devices. Retrieved from https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocu ments/ucm482022.pdf U.S. Food and Drug Administration. (2017a). Background on MDUFMA. Retrieved from https://www.fda.gov/ForIndustry/UserFees/MedicalDeviceUserFee/ucm109149.htm
56
U.S. Food and Drug Administration. (2017b). Requests for Feedback on Medical Device Submissions: The Pre-Submission Program and Meetings with Food and Drug Administration Staff. Retrieved from https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/Guidance Documents/UCM311176.pdf U.S. Food and Drug Administration. (2017c). CFR – Code of Federal Regulations Title 21. Retrieved from https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfCFR/CFRSearch.cfm?CFRPart=803& showFR=1 U.S. Food and Drug Administration. (2018a). FDAAA Implementation – Highlights One Year After Enactment. Retrieved from https://www.fda.gov/RegulatoryInformation/LawsEnforcedbyFDA/SignificantAmendmentst otheFDCAct/FoodandDrugAdministrationAmendmentsActof2007/ucm083161.htm U.S. Food and Drug Administration. (2018b). Medical Device Reporting (MDR). Retrieved from https://www.fda.gov/MedicalDevices/Safety/ReportaProblem/default.htm U.S. Food and Drug Administration. (2018c). 510(k) Clearances. Retrieved from https://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/DeviceApprovalsand Clearances/510kClearances/ U.S. Food and Drug Administration. (2018d). Premarket Approval (PMA). Retrieved from https://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/HowtoMarketYourDe vice/PremarketSubmissions/PremarketApprovalPMA/default.htm U.S. Food and Drug Administration. (2018e). Quality System (QS) Regulation/Medical Device Good Manufacturing Practices. Retrieved from
57
https://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/PostmarketRequireme nts/QualitySystemsRegulations/default.htm U.S. Food and Drug Administration. (2018f). Milestones in U.S. Food and Drug Law History. Retrieved from https://www.fda.gov/AboutFDA/WhatWeDo/History/FOrgsHistory/EvolvingPowers/ucm20 07256.htm Van Norman, G. A. (2016). Drugs, Devices, and the FDA: Part 2. JACC: Basic to Translational Science, 1(4), 277–287. https://doi.org/10.1016/j.jacbts.2016.03.009 White, J., (2015). Why medical device security should be top priority. Healthcare Business & Technology. Retrieved from http://www.healthcarebusinesstech.com/medical-devicesecurity/ Williams, P. A. H., & Woodward, A. J. (2015). Cybersecurity vulnerabilities in medical devices: A complex environment and multifaceted problem. Medical Devices: Evidence and Research, 8, 305–316. https://doi.org/10.2147/MDER.S50048 Wirth, A. (2011). Cybercrimes pose growing threat to medical devices. Biomedical Instrumentation and Technology, 45(1), 26–34. https://doi.org/10.2345/0899-8205-45.1.26
58
