CHAPTER 31
Cybersecurity Considerations for Medical Devices
Axel Wirth
In this chapter, you will learn how to
• Understand the fundamental security problems of the medical device ecosystem and its vulnerabilities
• Describe how these vulnerabilities translate to a variety of risks, including risks to patient safety and care delivery
• Explain how regulators and security specialists are starting to address these problems
• Describe what device manufacturers and healthcare organizations can do to minimize the risk of harm or impact to their business
Medical Device Cybersecurity and Cybersafety: An Introduction
Many IT professionals regard implementing good cybersecurity in healthcare to be more challenging than in other industries because of the complexity of healthcare workflows and supporting IT systems as well as the potential of security measures conflicting with care delivery, which often requires immediate and easy access to information. Further, healthcare is a highly regulated industry, so healthcare organizations tend to be very conservative and careful about implementing change. Although this approach is understandable, it also, unfortunately, has the potential of conflicting with the nimble approach required to maintain an up-to-date security posture and adapt to today’s ever-evolving cyberthreats and attack strategies.1
Ever since clinicians, physicists, and engineers began to apply technology to improve diagnosis and treatment of patients,2 medical devices have become an integral part of our healthcare delivery system, improving diagnoses and extending lives. They form a complex and sensitive ecosystem of networked devices and integrated workflows, supporting all aspects of care delivery. However, in the twenty-first century, cybersecurity of networked medical devices and the resulting risks to patient safety have become a serious concern.
This unique security challenge has developed for a number of reasons:
• Increasingly, medical devices are interconnected via standard IT networks and supported by common IT components like servers and workstations. This interconnectivity provides cost savings through staff efficiency and improves the reliability of data capture, but it also introduces cybersecurity risks that devices were previously not exposed to.
• Medical devices are strictly regulated (for example, through the Food and Drug Administration [FDA] in the United States), traditionally prioritizing a controlled engineering processes, formal testing, and well-documented market release and approval for the benefit of device safety over flexibility to address cybersecurity.
• As a result of regulation, manufacturers are often slow to release security patches or updates, and hospitals cannot deploy them or other security measures (e.g., after-market security software) without approval by the manufacturer.
• Because medical devices have a long useful product life, many systems still in operation were not designed with today’s sophisticated and rapidly developing threats in mind.
• The number of devices, suppliers, and platforms is typically larger than in the traditional IT environment, making complexity part of the challenge.
• Security responsibility for devices, from purchasing to maintenance to end-of-life (EOL) disposal, is often unclear or may be separated between Clinical Engineering (CE) and IT Security departments.
All of these factors have resulted in a typically low security maturity of the individual device and a poor security posture of the integrated device networks in hospitals.
To compound the problem further, the potential damage that could result from a medical device cybersecurity incident is much higher than that of a traditional IT security incident. Although both can impact hospital operations and care delivery, a medical device event has the potential of directly harming a patient. Although not all devices are life critical or life sustaining, even the shutdown of devices in a cardiac catheterization lab (cath lab) through a computer worm,3 for example, will delay diagnosis and be a risk to cardiac emergency patients.
As we review the challenges that exist around securing medical devices, we need to be aware of three main aspects:
• The easily exploitable vulnerability and low security posture of today’s medical device ecosystem
• The resulting high risk to patient safety and care delivery
• Due to practical, economic, and regulatory limitations, the fact that the complete replacement of existing devices with modern, more secure ones will take time
The risks are real, and although there is no need to panic, we should proceed with a sense of urgency—and there are things that we can and should do now.
Medical Device Vulnerabilities and Risks: A Review
At the time of this writing, there have been no reported incidents of patient harm caused by a medical device cybersecurity incident. However, many critical device vulnerabilities have been documented by security researchers and many incidents of operational and care delivery impact have been reported by healthcare providers. Some examples include the following:
• Security researchers demonstrated that they can crack the proprietary communication of implantable medical devices and reprogram them; e.g., vulnerabilities have been found in pacemakers and implantable cardiac defibrillators4 and insulin pumps.5
• In 2013, ICS-CERT (Industrial Control System Cyber Emergency Response Team within the Department of Homeland Security) issued a security alert reported to them by security researchers Billy Rios and Terry McCorkle about design vulnerabilities in 300 medical devices across approximately 40 vendors; e.g., prevalent design vulnerabilities like the use of default or even hardcoded passwords.6 Many other ICS-CERT medical device–specific warnings have followed since.
• The ability of healthcare facilities to deliver care and clinical services is impacted due to devices being compromised by malware and computer worms (like Conficker), exploiting vulnerabilities of commercial operating systems in medical devices. Reported cases include the shutdown of a VA hospital’s catheterization laboratory in New Jersey in 2010, requiring rerouting of cardiac emergency patients3 and a malware infection of medication cabinets across multiple locations, requiring shutdown of devices and manual medication management (personally reported to the author in 2009).
• Several organizations—for example, the Mayo Clinic—have performed targeted testing on networked medical devices, all with very concerning results, showing a prevalence of vulnerabilities across a variety of devices.7
• Patients have been able to obtain the password of a patient-controlled analgesia (PCA) pump and increase the dosage of pain medication above the pump’s safety limit, resulting in respiratory arrest of one of the patients.8
• Security researchers at TrapX9, 10 and Protiviti11 demonstrated that medical devices are actively being targeted and exploited. It is believed that they are not the primary targets but are being targeted because they are an easy entry point for a network attack and an excellent hiding point for attack-supporting malware.
There is plenty of other evidence that medical devices have significant vulnerabilities that could be maliciously exploited. To add to the concerns, in general cyberattacks have become increasingly targeted and sophisticated and are being performed by financially motivated criminal gangs and by well-funded and politically motivated cyberarmies and cyberterrorists. This leads to a broad spectrum of possible risks and resulting impacts ranging from harmless nuisances to catastrophic events. On the most serious end of the spectrum, devices could be targeted in nation-state conflicts and cyberwarfare attacks on our critical infrastructure. On the other, more benign end of the spectrum, attackers could hide malware in medical devices to make remediation more difficult. Figure 31-1 depicts the broad spectrum of possible scenarios and underlying implications.
Figure 31-1 Medical device risk spectrum and implications
We also need to differentiate between two types of attack: a targeted attack (e.g., the intent to do harm) or an opportunistic attack or coincidental malware outbreak (e.g., compromising a medical device not because of what it is but because it fits an attack profile and is an easy entry point).
Although to date there has not been a report of a targeted attack on medical devices with the intent to do harm, should this occur, the consequences could be severe and far reaching, including, for example, patients rejecting device-based treatment options based on news headlines. As discussed above, today’s problems are of a coincidental or indirect nature leading to IT and care delivery interruptions. As we develop our defensive strategies, we need to do so in consideration of both scenarios.
The main risk scenarios can be summarized as follows:
• Patient harm as a direct result of a targeted attack
• Patient harm as an indirect result of compromised device performance or functionality directly resulting from a coincidental attack or malware outbreak
• Care delivery and operational impact due to device or network compromise, requiring reduction in or shutdown of certain clinical services
• Privacy breach and exposure of data due to device hack or compromise, loss or theft of device, or improperly disposed device
The following are secondary consequences of patient harm, privacy breach, or operational impact:
• Damage to reputation of healthcare provider or device manufacturer
• Revenue loss and financial impact due to service shutdown, lawsuits, and fines
• Remediation costs due to overtime, IT services, notifications, etc.
• Security compromise and exploitation of the device as an entry or hiding point for an attack on other systems, such as the EHR system (patient record theft) or business systems (financial theft)
Medical device security is, as stated initially, a highly complex problem with many moving pieces and interdependencies.
Medical Device Regulation: Impact on Cybersecurity
As mentioned before, one specific issue impacting medical devices is their regulated nature. This section will examine in more detail how regulations impact device security, but also how regulators are responding to this challenge with changing guidance.
Regulatory Background
All developed countries have some framework for regulating medical devices to assure their safety and effectiveness. Most countries take a somewhat similar approach to how pharmaceuticals are regulated. In the United States, for example, the FDA provides the regulatory framework for device manufacturers and importers through its Center for Devices and Radiological Health (CDRH), which “is responsible for regulating firms who manufacture, repackage, relabel, and/or import medical devices sold in the United States.” CDRH also regulates radiation-emitting electronic products such as lasers, X-ray systems, and ultrasound equipment.12
The overall approach is to impose formal regulatory controls to govern engineering, manufacturing, and marketing processes, either in general (e.g., for manufacturing facilities and processes) or for each individual device (e.g., formal validation and verification testing to assure the device’s “safety and effectiveness” relative to its “intended use”). This approach is intended to assure that all aspects of the device are safe: everything from handling and sterilization to mechanical, radiation, or electrical safety—including the safety of device software.
The degree of regulatory controls applied varies depending on the risk to the patient in case of device failure. For example, the risk of an electronic thermometer harming a patient is much lower than that of a proton therapy system harming a patient. Therefore, devices are classified into low, medium, and high risk categories (Class I, II, and III, respectively, in FDA terminology), with increasing level of regulatory controls for devices in the higher classes. For example, the FDA requires device manufacturers to file a so-called 510(k) Premarket Notification for Class I and II devices (unless the device type is considered low risk and is explicitly exempt) or to file for a more extensive Premarket Approval (PMA) for Class III devices.
Because this classification process applies to the entire device, it has had significant impact on management of a device’s software, including any commercial off-the-shelf (COTS) software (e.g., the operating system) or open source software. Although the FDA has repeatedly stated that software updates or patches for the sole purpose of addressing cybersecurity do not require filing notice with or approval by the agency,13 the manufacturer still needs to undertake formal testing and release of a device update or patch to assure that device safety is not compromised.14 This is, in general, governed by the FDA’s Quality System Regulation, also called Good Manufacturing Practices as defined under 21 CFR part 820.
Although this test-and-release approach is advisable from a general product safety perspective, unfortunately it has hindered the execution of nimble and good cybersecurity practices in the following respects:
• The formal testing performed by the manufacturer defines an approved configuration (including software version) of the device. As a consequence, the operator (i.e., the hospital) typically cannot install aftermarket security solutions (e.g., antimalware), nor apply patches (e.g., to the operating system) that are not approved by the manufacturer. In the FDA’s view, “it is rare for healthcare organizations to have enough technical resources and information on the design of medical devices to independently maintain medical device software.” However, organizations could issue simple patches or updates if they are willing to assume the risk.15 It is, in the end, a tradeoff decision between the risk of the patch and the risk of the unpatched vulnerability.
• There are practical and economic limitations on how often a manufacturer can release updates and patches. Although this depends on device complexity, the quality of the manufacturer’s engineering and release processes, and the overall device architecture, most manufacturers release only a few security updates per year—leaving significant security gaps between patches.
One common concern voiced by healthcare providers is that manufacturers may not release any patches at all, citing a misinterpretation of the FDA requirements, and using it as an excuse (intentionally or not) to defend poor patch release and lifecycle management practices. However, the FDA has repeatedly clarified that timely patching of device software is not only permitted, but is desired to minimize safety risks due to security vulnerabilities.
But the issue of delayed patching is not limited to the manufacturer alone. Once a patch has been released, it still needs to be deployed in the hospital environment, which typically requires careful analysis and change management beforehand so that the deployment does not interfere with care delivery and is properly synchronized between dependent devices or devices and, for example, backend servers. This adds additional time to the deployment of a security upgrade, and it is not uncommon to see a delay of months, or in extreme cases even a few years, between the release of a patch by the software manufacturer, through approval by the device vendor, to actual implementation by the hospital.
It must be understood that although timely patching is a critical security strategy, it is not the only one and should always be applied in conjunction with other security technologies and measures, as will be discussed later. For more information, medical device patching has been discussed in more detail elsewhere.16
Of specific concern are legacy medical devices with operating systems (or other software components) that are no longer supported by the original manufacturer, and for which security patches are no longer produced. Short of replacing the device, which may be cost-prohibitive, a hospital needs to rely on security measures outside of the device, such as network isolation.
In a sense and unintentionally, regulations have contributed to the fact that today’s medical devices are insecure and cannot be as easily protected through common security measures like customer-installed security software or timely patching.
Changes in the Regulatory Landscape
The previously discussed challenges regarding medical device vulnerabilities are well understood by all stakeholders, including regulators. This understanding includes the realization that the historic focus on strict regulatory controls on one hand and the growing cyber risks on the other have created a new type of safety risk due to exploitable software flaws.
In the United States, the FDA has taken the lead in addressing this problem. For now, the FDA’s approach is one of providing guidance to the industry and encouraging a collaborative approach between stakeholders. The FDA recognizes that trying to force the issue with a strong regulatory arm at this juncture would be difficult because it could lead to lack of cooperation and coordination around cyber risks, and could potentially even have an impact on device availability and, consequently, treatment options, as some manufacturers could decide to exit a certain business rather than spend the effort of upgrading or redesigning insecure legacy devices.
Similarly, on the healthcare provider side, there are practical and economic limitations on how fast existing devices can be upgraded or replaced with more secure devices.
The FDA’s approach is, of course, based on today’s knowledge about and view of device security risks. Should there be an actual patient safety incident, or should progress of improving device security be too slow, it is entirely possible that we will see faster action and stricter regulatory enforcement.
To date, the FDA has issued two guidance documents specific to cybersecurity and intended for the medical device industry. The first is “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices” (Oct. 2, 2014),17 which addresses the key cybersecurity functions to consider during device design and release:
• Identify and protect:
• Limit access to trusted users (e.g., no common or hardcoded passwords)
• Ensure trusted content (providing and securely updating software)
• Detect, respond, recover:
• Implement features that enable users to detect, recognize, log, and act upon cybersecurity incidents
• Recommend actions to be taken by the user upon detection of a cybersecurity incident
• Implement features that protect critical functionality
• Provide methods for recovery of device configuration
The 2014 guidance recommends manufacturers include the following types of information in the cybersecurity documentation that they provide as part of their premarket submission to the FDA:
• Hazard analysis, mitigation, and design considerations pertaining to intentional and unintentional cybersecurity risks associated with a device
• Traceability matrix (mapping cybersecurity controls to risks)
• Update and patch management plans
• Summary of software integrity assurance controls
• Recommended security controls appropriate for the intended use
The second guidance issued by the FDA is “Postmarket Management of Cybersecurity in Medical Devices” (Dec. 28, 2016),18 which addresses the key aspects of device security maintenance once a device is in the market. Some of the important points include the following:
• Emphasizes that cybersecurity risk management is a shared responsibility among all the stakeholders
• Strongly recommends participation in an Information Sharing Analysis Organization (ISAO):
• Multistakeholder model
• Voluntary, but actionable, transparent, and trusted
• Information shielded from release, exempt from regulatory use and civil litigation
• Critical component of a comprehensive approach to cybersecurity
• Introduces the concept of “essential performance”:
• Assure freedom from unacceptable risk
• Provides recommendations on cybersecurity routine patches and updates:
• Generally not required to be reported to the FDA
• Reporting required for rare actions that pose serious adverse health consequences or unacceptable residual risk
• Provides other key manufacturer guidance on topics such as the following:
• Threat and incident monitoring
• Vulnerability disclosure policy
• Receipt and processing of vulnerability reports
• Good cyber hygiene practice
The preceding information is only a summary of the two guidance documents. For actual regulatory and legal decision making, you should refer to the latest release of the actual documents.
Obviously, both guidance documents are targeted at the medical device manufacturer, but both, and especially the postmarket guidance document, contain significant recommendations that can help healthcare providers articulate their security requirements and establish formal engagement with the device manufacturer on security topics.
Concerns around medical device cybersecurity are not limited to just the device manufacturer and healthcare provider. In fact, many aspects of this problem are of larger, socio-economic and even political concern. Therefore, the FDA’s efforts are being supported by other government entities looking at the problem from their respective perspectives, including (among others):
• The White House (critical infrastructure security under the Cybersecurity National Action Plan)
• Homeland Security (national security)
• The FBI (crime prevention)
• Federal Trade Commission (consumer protection)
• Federal Communications Commission (wireless reliability)
At the time of this writing, little has been published on activities by other, non-U.S. regulators. Regulators in other countries are closely watching the development in the United States and the FDA’s approach.
Implementing Medical Device Cybersecurity
Although there are multiple dimensions of complexity to the medical device security problem, there is a path forward that can be taken by the respective stakeholders as will be discussed in this section.
A Shared Responsibility
Solving the challenge of securing the medical device ecosystem is not a simple task, and will require a multiyear effort of implementing complex change and targeted improvement. This effort must be carried forward by all stakeholders together, primarily by regulators, manufacturers, healthcare providers, and security specialists, but also with the support of IT system integrators, healthcare IT developers, and IT vendors.
Further, as illustrated in Figure 31-2, the applicable solutions vary depending on which aspect of the problem is being addressed, which in turn defines the responsibilities of the manufacturer (solutions that need to be designed into the device) and the healthcare organization (solutions that help manage and minimize the security risks of the integrated system of devices).
Figure 31-2 Key aspects of securing the medical device ecosystem
Although all stakeholders share the underlying problem of securing the medical device ecosystem, they contribute different aspects of the solution. It will take time to upgrade the inventory of relatively insecure devices, and even then it would not be advisable to rely just on the device for defense. Modern attacks are so sophisticated that they require what in security is commonly referred to as “defense in depth,” which means defending all aspects of the infrastructure.
Essentially, stakeholders need to address the four tenants of cybersecurity:
• Protect the device (and its data)
• Protect the ecosystem
• Manage the device
• Respond to and manage incidents
A variety of cybersecurity measures can be applied by medical device manufacturers and healthcare providers to achieve these tenants. Manufacturers can improve device security through the process-based measures presented in Table 31-1 and the technical measures presented in Table 31-2, and healthcare providers can improve the security posture of their device networks and operations through the process-based measures presented in Table 31-3 and the technical measures presented in Table 31-4. More detailed information on security best practices specific to medical devices has been provided elsewhere.19
Table 31-1 Manufacturer Approach: Process-Based Cybersecurity Measures
Table 31-2 Manufacturer Approach: Technical Cybersecurity Measures
Table 31-3 Healthcare Provider Approach: Process-Based Cybersecurity Measures
Table 31-4 Healthcare Provider Approach: Technical Cybersecurity Measures
A detailed approach and guidance for healthcare providers on how to implement risk management for networked medical devices is provided through the ISO/IEC 80001 series of standards.21 An example on how to approach medical device network segregation is provided by the U.S. Department of Veterans Affairs’ “Medical Device Isolation Architecture Guide.”22
Risk Analysis, Assessment, and Management: Laying the Foundation
Risk analysis (analyzing threats relative to an organization’s or system’s vulnerabilities) and risk assessment (assigning values to risks based on impact and likelihood, providing a metric of potential consequences for the purpose of informed decision making and prioritization of countermeasures) are the foundations for a successful risk management program (the continual application of policies, procedures, and practices to identify, analyze, assess, and communicate risk) and enable risk mitigation (reduction of potential adverse effects) based on business objectives.
A good risk management program should look at all possible risks, and should reduce the potential impact based on likelihood (probability of occurrence) and potential impact (harm). The practice of risk management is not unique to IT, and is used for anything from managing business risks to the risk of natural disasters to risks to human health (e.g., through an adverse event of a medical device, be it cybersecurity related or another form of device failure).
Healthcare providers typically use the risk management processes not only to address regulatory and legal requirements, but also to reduce security risks to their sensitive data housed in their IT infrastructure. Similarly, medical device manufacturers use a risk analysis approach (usually referred to as hazard analysis) to minimize the potential harm to patients. The difference between the two is that a healthcare provider performs a risk analysis based on their actual implementation and larger ecosystem, whereas a device manufacturer tries to mitigate risks to their individual devices for all use cases and through design, testing, documentation, and communication.
Although risk management is a well-established methodology to help organizations reduce risk, numerous problems often occur in the process. Too many risk analyses remain abstract exercises that take a checklist approach and fail to address real-life uses and risks. This results in shortcomings such as
• The risk assessment is performed against incomplete inventory.
• It is incomplete and does not cover all use cases and workflows.
• It may address regulatory compliance requirements (e.g., HIPAA), but not actual security risks.
• It is performed based on a fixed schedule (e.g., annually) rather than actual need.
• An organization performs multiple analyses addressing different areas of focus or meeting different needs, yet fails to align them, resulting in gaps, overlap, and conflict.
• It is not updated as business, technology, processes, or cyberthreats change.
• Periodic analyses are inconsistent and do not allow tracking relative to previous assessments.
• It fails to keep up with technological advances like cloud-based data storage, mobile devices, or social media.
Especially in the medical device space, these types of problems are commonplace. Many organizations perform a risk assessment for their IT environment but fail to include medical devices, even though HIPAA requires that any device containing ePHI is to be included. Alternatively, an organization may assess medical equipment safety as required by the Joint Commission but fail to include cybersecurity risks.
Often, these gaps start with the regulations. To take a simple example, a digital X-ray system may store patient data (orders, images, etc.) that would be regulated under HIPAA, but it also contains critical system data (e.g., calibration) that would be a radiation safety concern from the FDA perspective. This simple example shows how healthcare providers are challenged to meet multiple requirements and may choose to perform multiple risk analyses—or, a single but more complex process that encompasses all. The latter is obviously preferred but also more complex and challenging.
The complexity in the medical device space is significant. Commonly, hospitals have more medical devices to manage than they have regular IT components. Furthermore, the device ecosystem is more diverse and includes different types of systems from many different vendors and, consequently, of very differing levels of security maturity. A medical device risk management process must account for this complexity as well as for the challenges of managing and maintaining life-critical devices in a 24/7 operating environment.
Although healthcare providers should not install security measures without manufacturer approval, they can improve their device integration and management processes to minimize their security risks. As illustrated in Figure 31-3, a medical device–specific risk management process has to be
Figure 31-3 Medical device risk management framework overview
• Comprehensive Starting with procurement and specification of security requirements and ending with device EOL (removal of sensitive data and network credentials).
• Vendor-inclusive Define security requirements and vendor obligations; include the vendor in incident response and other relevant analysis and findings.
• Complete Include all devices, use scenarios, and dependencies between devices and IT components.
• Manageable In light of the previously mentioned complexity, automation and tools are likely required to make a medical device risk management program manageable and maintainable. Although some tasks may still require manual execution (e.g., patching, as previously discussed), the processes and management of these tasks can be automated, leading to more efficient and reliable execution of the overall processes.
This approach is very much in line with the previously described four tenants of cybersecurity: protect the device (and its data), protect the ecosystem, manage the device, and respond to and manage incidents.
Chapter Review
Unlike in the traditional healthcare IT security environment where the focus is on information protection (as stipulated by the HIPAA Security Rule), in the medical device environment the focus is on safety, functionality, reliability, and operational availability. Although there are data concerns in the device space as well (e.g., a change in dosage at an infusion pump), the situation is really much more complex and sensitive, requiring a comprehensive view and understanding of the medical device security problem and related risks. A path forward has been established through regulatory guidance and by thought-leading device manufacturers and healthcare providers.
It is now up to the larger healthcare community to articulate and fine-tune an approach to collectively move forward and solve this problem as fast as possible—but without compromising the critical function that medical devices perform.
This chapter has mainly focused on discussing cybersecurity in the context of traditional, hospital-based equipment. As our care-delivery models change and as new technologies enable remote and mobile monitoring of patients’ conditions, care providers can now manage chronic diseases in patients’ homes, and we need to be equally concerned about cybersecurity in an even more complex ecosystem that includes personal devices, like smartphones, and public networks.
It is clear that in either case, traditional care delivery or home care equipment, we need to recognize the cybersecurity and privacy challenges and move forward with determination and a sense of urgency. Our healthcare delivery system, including the medical device ecosystem, is part of our national critical infrastructure and is exposed to the same cyber risks. However, it is woefully behind in security and implementing change.
Developing a more security-resilient approach will require overcoming systemic latency, but we have to do our best and do it soon because bad actors are creative and persistent in their approach and attacks are growing in volume and sophistication.23 In addition, we need to be prepared in the event that a potential patient safety incident results in complex consequences.
Questions
To test your comprehension of the chapter, answer the following questions and then check your answers against the list of correct answers that follows the questions.
1. Which U.S. government agency regulates the release of medical devices and assures their safety and effectiveness?
A. FTC
B. FDA
C. DHS
D. FCC
2. What is the purpose of the FDA premarket and postmarket cybersecurity guidance documents pertaining to medical devices?
A. They inform medical device manufacturers about expected future regulations.
B. They define what hospitals should consider when they buy a new device as well as when they discard a device at the end of its useful life.
C. They define what security requirements manufacturers need to meet for a device in clinical trials.
D. They provide guidance on device manufacturers’ cybersecurity responsibilities prior to market release and after market release of a medical device.
3. Why are medical devices’ software patch levels difficult to keep up to date?
A. Because of the devices’ critical patient care role.
B. Because the impact of a patch on cybersecurity is difficult to predict.
C. Because a new patch requires a new regulatory filing.
D. Because a new patch requires manufacturer testing and approval.
4. Are medical devices at risk of a malicious cyberattack?
A. No, because they typically are not connected to an open network.
B. Yes, because of their many software vulnerabilities.
C. No, because even hackers would not stoop that low.
D. Yes, but such an attack is highly unlikely.
5. What are the typical parts of a comprehensive security risk management program?
A. Risk definition, assessment, and mitigation
B. Vulnerability, threat, and impact analysis
C. Replacement cost versus remaining life expectancy
D. Risk analysis, assessment, and mitigation
6. What is incident response planning?
A. Good business management practice.
B. A process approach to prepare for an incident (e.g., a cybersecurity event) that defines responsibilities and the appropriate action to be taken.
C. A best practice to make sure patients do not become aware if something goes wrong.
D. A replacement strategy for medical devices as they may fail and need to be replaced.
7. What can hospitals do to protect their medical devices from cybersecurity risks?
A. Buy only secure devices.
B. Make sure that devices are always password protected.
C. Nothing, because regulations prevent them from doing anything.
D. Network segregation architecture, network-based security, security event monitoring, and device patching.
8. Is the long useful life of medical devices a security concern?
A. Yes, because older devices were not designed with today’s threats in mind.
B. No, because devices get updated on a regular basis.
C. Yes, because software tends to become unreliable over time.
D. No, because they are designed for robustness and safety.
Answers
1. B. The U.S. Food and Drug Administration (FDA) regulates firms who manufacture, repackage, relabel, and/or import medical devices sold in the United States through its Center for Devices and Radiological Health (CDRH).
2. D. The FDA’s premarket (October 2014) and postmarket (December 2016) guidance documents lay out the agency’s interpretation of existing regulation with regard to medical device manufacturers’ cybersecurity responsibilities as they release a new product to the market (premarket) and maintain its security posture once it is released and in use (postmarket).
3. D. Under FDA guidance, as long as a patch or update does not change a device’s functionality or intended use, in most cases the device manufacturer is not required to update its regulatory filing. However, under the Quality Systems Regulation, the patch or update still needs to be approved by the manufacturer and undergo formal testing to assure system safety has not been compromised. This adds cost and overhead to each release, which makes it difficult to provide timely and frequent security patches.
4. B. Security researchers, healthcare providers, and government agencies have conducted medical device security testing and demonstrated vast vulnerability due to poor security design practices.
5. D. A complete and comprehensive risk management program should include the steps of risk analysis (threats, vulnerabilities), risk assessment (likelihood, impact), and risk mitigation (reducing risk through technical or administrative controls or financial protection such as insurance). Note that acceptance of risk is also a possible outcome, but should always be supported by a conscious decision process and an understanding of the possible impact.
6. B. A good incident response plan should define responsibilities as well as a standardized process to guide through incident recovery and restoration, forensics, and postmortem. It should not just be internal-focused but also define external activities.
7. D. Although hospitals are typically prevented from making changes to the actual devices without manufacturer approval, they can improve their devices’ security posture through network segregation architecture, network-based security and event monitoring, secure handling, and configuration maintenance (including patching).
8. A. Medical devices often have a useful life of ten years or even longer. As a consequence, older devices were not designed with knowledge of today’s cybersecurity threat vectors. Another concern is that older devices may include software components that are no longer supported with security patches.
References
1. Independent Security Evaluators. (2016, Feb. 23). Securing hospitals: A research study and blueprint. Accessed on August 23, 2016, from https://securityevaluators.com/hospitalhack/securing_hospitals.pdf.
2. Röntgen, W. C. (1895, December). Über eine neue Art von Strahlen [On a new kind of rays]. In Sitzungsberichte der Würzburger Physik.-medic Gesellschaft (pp. 137–147). Braunschweig: Friedrich Vieweg und Sohn. Translated by Arthur Stanton in Nature, 53, 274–276 (1896), available at www.nature.com/physics/looking-back/roentgen/index.html.
3. Weaver, C. (2013, June 13). Patients put at risk by computer viruses. Wall Street Journal. Accessed on August 23, 2016, from www.wsj.com/articles/SB10001424127887324188604578543162744943762.
4. Halperin, D., Heydt-Benjamin, T. S., Ransford, B., Clark, S. S., Defend, B., Morgan, W., … and Maisel, W. H. (2008, May). Pacemakers and implantable cardiac defibrillators: Software radio attacks and zero-power defenses. Proceedings of the 29th Annual IEEE Symposium on Security and Privacy. Accessed on March 10, 2017, from www.secure-medicine.org/public/publications/icd-study.pdf.
5. Radcliffe, J. (2011, Aug. 4). Hacking medical devices for fun and insulin: Breaking the human SCADA system. Black Hat 2011 Conference. Accessed on March 10, 2017, from media.blackhat.com/bh-us-11/Radcliffe/BH_US_11_Radcliffe_Hacking_Medical_Devices_Slides.pdf.
6. ICS-CERT. (2013, June 13; revised 2013, Oct. 29). Alert (ICS-ALERT-13-164-01) medical devices hard-coded passwords. Accessed on March 10, 2017, from ics-cert.us-cert.gov/alerts/ICS-ALERT-13-164-01.
7. Bruemmer, D. (2015, June 22). Medical device security in a connected world. NCHICA Annual Conference. Accessed on March 10, 2017, from nchica.org/wp-content/uploads/2015/06/Bruemmer-Hudson-Wirth.pdf.
8. Sarvestani, A. (2014, Aug. 15). Hospital patient hacks his own morphine pump. MassDevice Today. Accessed on March 10, 2017, from www.massdevice.com/hospital-patient-hacks-his-own-morphine-pump-massdevicecom-call/.
9. TrapX. (2015, June 4). Anatomy of an attack: MEDJACK (Medical Device Hijack). Accessed on March 10, 2017, from deceive.trapx.com/rs/929-JEW-675/images/AOA_Report_TrapX_AnatomyOfAttack-MEDJACK.pdf.
10. TrapX. (2016, June 27). MEDJACK.2 hospitals under siege. Accessed on March 10, 2017, from deceive.trapx.com/rs/929-JEW-675/images/AOA_Report_TrapX_MEDJACK.2.pdf.
11. Pauli, D. (2015, Sept. 29). Thousands of “directly hackable” hospital devices exposed online. The Register. Accessed on March 10, 2017, from www.theregister.co.uk/2015/09/29/thousands_of_directly_hackable_hospital_devices_found_exposed/.
12. U.S. Food and Drug Administration (FDA). (2015, Aug. 14). Overview of device regulation. Accessed on August 23, 2016, from www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/Overview/.
13. FDA. (2016, Aug. 8). Deciding when to submit a 510(k) for a change to an existing device. Accessed on August 23, 2016, from www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM514771.pdf.
14. FDA. (2015, July 28). Information for healthcare organizations about FDA’s “Guidance for industry: Cybersecurity for networked medical devices containing off-the-shelf (OTS) software.” Accessed on August 23, 2016, from www.fda.gov/RegulatoryInformation/Guidances/ucm070634.htm.
15. Association for the Advancement of Medical Instrumentation (AAMI). (2017, Feb. 28). Seven cybersecurity myths put to the test. Accessed on March 10, 2017, from www.aami.org/newsviews/newsdetail.aspx?ItemNumber=4191.
16. Integrating the Healthcare Enterprise (IHE). (2015, Oct. 14). Medical device software patching. IHE PCD Technical Committee in cooperation with MDISS. Accessed on August 23, 2016, from http://ihe.net/uploadedFiles/Documents/PCD/IHE_PCD_WP_Patching_Rev1.1_2015-10-14.pdf.
17. FDA. (2014, Oct. 2). Content of premarket submissions for management of cybersecurity in medical devices: Guidance for industry and Food and Drug Administration staff. Accessed on August 23, 2016, from www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM356190.pdf.
18. FDA. (2016, Dec. 28). Postmarket management of cybersecurity in medical devices: Guidance for industry and Food and Drug Administration staff. Accessed on March 10, 2017, from www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm482022.pdf.
19. IHE. (2015, Oct. 14). Medical equipment management (MEM): Medical device cybersecurity—Best practice guide. IHE PCD Technical Committee. Accessed on August 23, 2016, from http://ihe.net/uploadedFiles/Documents/PCD/IHE_PCD_WP_Cyber-Security_Rev1.1_2015-10-14.pdf.
20. HIMSS, ACCE, NEMA. (2013, Oct. 7). Manufacturer disclosure statement for medical device security (MDS2). Accessed on August 23, 2016, from www.himss.org/resourcelibrary/MDS2.
21. AAMI. (2011, March). Getting started with IEC 80001: Essential information for healthcare providers managing medical IT networks. Accessed on August 23, 2016, from www.aami.org/productspublications/ProductDetail.aspx?ItemNumber=918.
22. U.S. Department of Veterans Affairs. (2009, August). Medical device isolation architecture guide, version 2.0. Accessed on August 23, 2016, from www.himss.org/ResourceLibrary/ResourceDetail.aspx?ItemNumber=7236.
23. Symantec. (2016, April). 2016 Internet security threat report. Accessed on August 23, 2016, from www.symantec.com/threatreport.