Collaboration among healthcare technology stakeholders—from device manufacturers and healthcare delivery organizations to healthcare security intelligence organizations—is needed to integrate medical and IT security requirements and develop a standard security framework for medical device technologies.
The Medical Device Innovation, Safety and Security Consortium (MDISS), the International Society of Automation (ISA), Health Information Trust Alliance (HITRUST), National Institute of Standards and Technology (NIST), and others are developing and improving standards to address various aspects of IT security for medical devices, from product design and risk management to IT networks and supply chain risks.
At the Healthcare Information and Management Systems Society (HIMSS) conference in April 2015 there was a tremendous display of both clinical and personal health care devices. All of these devices are intended to collect and share information with services such as health record integration and analysis tools in the cloud.
Devices are created from a set of sub-components that are integrated together into a working product and end up in a home or clinical network. Once on a clinical network, there’s ongoing maintenance that the health care delivery organization (HDO) or a third party performs on an ongoing basis. For security and IT management reasons, the devices should be closely inventoried for asset, vulnerability, and configuration management.
The device manufacturer (and maintenance personnel) will grow in awareness of devices threats and vulnerabilities as the U.S. Food and Drug Administration (FDA) message around device concerns continues to trickle through the industry. There’s a layered defense paradigm in play between security design of the device and the security design of the environment between. Are the conversations harmonizing information between these two camps? The answer: Not frequently enough, but it’s getting better.
Practically speaking, there is an economic challenge to improving medical device security. Medical device manufacturers are concerned over the cost increase of building in security and question if the buyers (clinical department more so than IT) will be tolerant of that increase. Government can help establish the message that not investing in security is an unfair trade practice because patients will suffer the consequences of increased risk.
Risk assessments are being performed, but not in a collaborative manner. Common symptoms that illustrate that medical device security is not yet receiving enough attention in the medical device industry are hard coded passwords, open ports, and debug code left in devices. Manufacturers could be sharing information, especially when there may be many shared common components under the covers. A framework is needed to effectively support the economics of risk management.
MDISS is a collaborative and inclusive nonprofit professional organization committed to “advancing quality health care with a focus on the safety and security of medical devices”. Its mission is stated to “protect public health and wellbeing by advancing computer risk management practices to ensure wide availability of innovative and safe medical devices.” The organization serves providers, payers, manufacturers, universities, government agencies, technology companies, individuals, patients, patient advocates, and associations.
MDISS members include medical device manufacturers, health care delivery organizations, standards organizations, medical device testing companies, service organizations, and device designers. The organization has evolved into a highly collaborative and trusted group capable of addressing complex policy, practice, and technical challenges for medical device security and safety.
MDISS also works closely with key government agencies and non-profit organizations such as the FDA, NIST/NCCOE, HHS, DOD, NHISAC, Center for Internet Security, AAMI (Association for Advancement of Medical Instrumentation), ACCE (American College of Clinical Engineering), SANS, and others.
The Current Conversation Around Regulating Medical Device Security
The conversation is robust and involved…and it is just the beginning. In the US, the FDA is leading the charge and has shared general principles including structured risk management reports outlining identification, inherent risk, control application, and resultant residual risk. Rather than being prescriptive, references to best practices are shared. An informative conference was held in October of 2014. Information from this conference can be viewed at www.fda.gov/downloads/medicaldevices/newsevents/workshopsconferences/ucm419427.pdf .
At the conference, it was clear that the basics are still important: Strong Authentication, Authorization, Privileged User, Code signing, Configuration Management, Encryption of data, Event logging and Incident Analysis & Response. In addition, the FDA’s guidance recommends assuming the device can be compromised and still safe-guard its critical clinical functions.
Regulations can both address risk and create risk. When regulations are large, overly prescriptive, or difficult to adopt, organizations shift resources from design and testing to audit response. Regulatory frameworks are also slow to change relative to rapid changes in threat tactics and targets. Are we even testing the most relevant controls in light of these threats? Quality control implementations should prevail over their quantity. Finally, consider that risk assessments in many industries, including other portions of health care, tend to focus on confidentiality and availability. With medical devices, availability and integrity are the key tenets to patient safety.
Accountability and good faith intent must be in place between manufacturers and buyers to move forward. Risk management must be “built in” to product development lifecycles including product planning, manufacturing, testing, and release management. Security reviews of the architecture, as well as the finished product, must be introduced. This practice includes threat modeling and safety impact analysis. There is an opportunity to develop new certification trust marks denoting the security safety of the product. In time, this will be part of brand appeal and competitive advantage for manufacturers. Again, the conversation is robust and involved and there is plenty of work remaining for thought leaders. (See Figure 1)
What Will IEC 62443 Do for Medical Devices?
Originating from ANSI/ISA, the International Electrotechnical Commission (IEC) 62443 is a framework of security standards specifically developed for Industrial Automation and Control Systems (IACS). The FDA has recognized the IEC 62443 series as foundational standards for medical device security. Included are procedures aimed at manufacturers, asset owners, integrators, and security practitioners who are responsible for the complete product lifecycle.
Foundational information in IEC 62443 includes concepts, models and terminology. Also included are work products that describe security metrics and security life cycles for devices, targeted at the asset owner. These address various aspects of creating and maintaining an effective IACS security program. Central to this program is the zone and conduit design model. Many hospitals have flat networks with minimal segregation between vulnerable devices and malware targeted humans. IEC 62243 3-2 addresses this challenge. Three parts of the IEC 62443 series are FDA reference standards: Network and System Security - Part 1-1: Terminology Concepts and Models, Part 2-1: Establishing an Industrial Automation and Control System Security Program, and Part 3-1: Security Technologies for Industrial Automation and Control Systems.
What Other Organizations and Frameworks Are Relevant?
Plenty—and that can add to the confusion of where to get started.
The FDA had not historically dealt with malicious cyber actors. However, they are currently leading the cybersecurity charge by coordinating with other agencies, building a cybersecurity testing lab, and identifying crucial aspects of product development and enterprise management such as code analysis and fuzz testing. They have released guidance for manufacturers and held several conferences. The FDA offers procurement guidance and insight into government procurement practices. Small hospitals can adopt the FDA language to more easily and efficiently manage their device acquisition practices.
HIMSS promotes transparency by providing a template for medical device security risks called “Manufacturer Disclosure Statement for Medical Device Security” (MDS2). This can be requested by health delivery organizations in their procurement process. Per HIMMS, this was originally developed with the American College of Clinical Engineering (ACCE), and then “standardized through a joint effort between HIMSS and the National Electrical Manufacturers Association (NEMA).” MDS2 establishes a means by which medical device manufacturers can disclose device security attributes to healthcare providers. The goal is to clearly document the security related features of the medical devices they manufacture.
The Department of Homeland Security Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) has joined in to assist with alerts and best practices. The industrial control sector is about a decade ahead of healthcare in cyber-resilience experience. Transparency is a key aspect from manufacturers. Documentation of top risks, given intended use of a device, can and should be shared with implementers. Search engines on the internet are mapping out devices and functions; this information can be cross-referenced with vulnerability data on those same components putting valuable attack information in the wrong hands. In time this may be picked up by other organizations such as the US NH-ISAC (Healthcare and Public Health Information Sharing & Analysis Center).
The Multi-State ISAC is seeking to provide guidance to smaller health delivery organizations needing digestible steps towards basic cyber-hygiene. They are collaborating with state government agencies using a lightweight “top controls” approach.
The International Organization for Standardization (ISO) has developed the 80001 standard, including guidance on designing environments with medical devices. This standard is early in adoption at some health delivery organizations.
Archimedes is an organization that focuses on research and education to improve medical device security. They have done research on implantables, mitigation of EMI signal injection, security, and privacy qualities of medical devices. Their website is located at www.secure-medicine.org .
The National Cybersecurity Center of Excellence (NCCoE) has launched a new project to address the security of medical infusion pumps in particular and is collecting feedback.
MITRE is working with DHS on standards for sharing threat information in general (STIX). This will eventually serve medical device findings. The Department of Defense has also established stringent medical device testing requirements.
The Center for Internet Security (CIS) does configuration benchmarks which can adapted to Healthcare environments especially regarding configuration lockdowns for unpatchable legacy systems.
HiTrust has formed a workgroup focused on medical device risks and has also established Cyber Threat Exercises for healthcare organizations.
Industry-Wide Efforts Being Made
As you can see, there is a lot of industry-wide concern and effort going into addressing threats against medical devices and health delivery organization networks. While there is an opportunity for additional central coordination, there are plenty of references to draw on in order to test devices.
There is concern about the iterative impact of security testing for product upgrades. The FDA has stated that device manufacturers do not need to inform the FDA if they add or update security features – as long as they don’t change the nature of the clinical function. Naturally the manufacturer incurs costs to test the device. The hospitals don’t want to pay more, and the manufacturers are essentially transferring risk to them if they can’t test potential threats. (See Figure 2)
Let’s focus on the product development cycle. First, manufacturers should address cybersecurity during the architectural review phase and create a set of cybersecurity controls to address medical device risk management and maintain functionality and safety. Second, manufacturers should establish a cybersecurity vulnerability and management approach as part of the software validation and risk analysis that is required by the Code of Federal Regulations Title 21 Part 820.30(g). These areas will provide information on the threats considered and risks analyzed. Consider, as reference, MITRE’s Common Vulnerabilities and Exploits (CVEs). (See Figure 3)
Finally, in order to evaluate both intentional and unintentional cybersecurity risks, manufacturers should establish design inputs addressing the following cybersecurity areas:
- Identification of assets, threats, and vulnerabilities
- Assessment of the impact of threats and vulnerabilities on device functionality and end users/patients
- Assessment of the likelihood of a threat and of a vulnerability being exploited
- Determination of risk levels and suitable mitigation strategies
- Assessment of residual risk and risk acceptance criteria
Installation instructions should include recommended cybersecurity controls appropriate for the intended use environment. The hospital network should be viewed as a potentially hostile environment. Lack of technology is not the issue; we need smart people, sound policies, and high quality, shared information to create a robust and secure Healthcare ecosystem.
At the same time, care must be taken in assumptions regarding security of the surrounding network. Home treatment and monitoring devices may end up in very public networks.
We also have to be pragmatic, allowing organizations to respond using risk formulas and practicing remediation prioritization management. It’s key to allocate constrained resources to what’s truly important, not what “appears” urgent. Security Management Decision Support systems can be built to tie transparency reports like MDS2 into an HDO’s risk register. Governance Risk and Compliance (GRC) Technology is an excellent way to handle the numerous shifting variables in managing medical device and enterprise risks in one system.
Key controls are important. Less is more. Some frameworks have upwards of 300 controls relevant to medical devices. Understand the architecture, assets, threats, and boil it down to the top 25 to 30 controls that manage 80 percent of your risk. Then excel at these through high assurance means (measurable and self-improving control procedures).
Threat modeling is a valuable way of looking at a system design at any level and seeing attack surfaces. This can be done at a device level as well as at a network level. The security risk analysis for devices should be performed once the “intended use” of the device is established.
Also factor the ongoing challenges of vulnerability management when the asset needs to function for decades and you knowingly incorporate third party software requiring monthly patches. Integrators need to consider the whole system including supply chain components and assumptions of the Health Delivery Organization networks. As an integrator you are accepting residual risk of third party components.
Risks to medical devices restrict the tremendous potential of health technology and real-time monitoring to deliver optimal patient care.
The FDA is starting the conversation in a helpful manner. Most hospitals are just beginning to push security forward with medical device manufacturers. They have been trying to require some basic security principles in contracts as part of the purchases process, but must coordinate with their clinical engineering staff and the doctors in the organization that set cost expectations.
This article was written by Mark Coderre, National Practice Director for Security Services, and David Surber, Senior Regional Sales for Cybersecurity, Medical Test, and Audit, OpenSky Corporation, part of a TÜV Rheinland company, Tolland, CT. For more information, Click Here .