Smart, connected medical devices have launched a transformation in healthcare. From mHealth apps that monitor pacemakers via Bluetooth to smart drug delivery devices that send updates to healthcare providers, connected digital devices are making medicine more personalized, responsive and effective. However, these innovations come with a dark side. As devices become more sophisticated and connected, they also become more vulnerable to cybersecurity risks.
Every device that runs on any kind of code must have a cybersecurity strategy. In considering cybersecurity risk, most people imagine a nefarious hacker deliberately trying to break into a device in order to cause harm to a patient, steal data or pivot into hospital networks. While these risks cannot be minimized, devices do not have to be deliberately targeted to be vulnerable. For most devices, the biggest risks come from commodity malware, which can divulge confidential device data or disrupt performance even if the device was not a specific target. Even devices that are not connected to the internet or hospital networks during normal operation are vulnerable; malware can make its way onto these devices when the code is updated or when the device is connected to a thumb drive, the internet or another device to upload or download data.
When developing a cybersecurity plan, many manufacturers only think in terms of vulnerability testing. While testing is a critical part of the process, the most effective and efficient approach to mitigating cybersecurity risks starts with smart design. By building secure design principles into the device from the start, manufacturers can minimize their risks and avoid missteps that could lead to costly delays and expensive changes later in the development cycle.
There are several key points during development when you have an opportunity to impact cybersecurity. The earlier you start in the development process, the easier it will be to integrate secure design. Most cybersecurity vulnerabilities are actually introduced by poor device design choices, not by elite hacks. Small, inexpensive changes in design can have a big impact on future security.
Cybersecurity risk management is an iterative process across the design cycle, much like safety risk management. In fact, safety and cybersecurity mitigation should happen in parallel, as cybersecurity concerns can also become patient safety concerns. An effective cybersecurity strategy starts with good design principles and continues with testing and design iteration throughout development. This includes:
The U.S. Food and Drug Administration (FDA) has released both pre-market1 and post-market2 cybersecurity guidance for device manufacturers. Prior to submitting a device to the FDA for approval, manufacturers must conduct a threat assessment, including analysis of the potential for patient harm and mitigation of known security risks. While the FDA recognizes that no device will ever achieve 100% security, manufacturers are expected to have a cybersecurity strategy for the device that properly balances the likelihood and severity of patient harm against other design considerations. After market launch, the FDA expects manufacturers to have appropriate processes in place to make secure updates to the device code and respond to emerging cybersecurity risks. Meeting FDA requirements is much easier when cybersecurity is embedded throughout the design process.
The first defense against cybersecurity vulnerabilities starts up front, during requirements development. This is the stage of the process with the greatest impact for the lowest cost. The majority of cybersecurity weaknesses found during testing are a result of poor design choices made up front; building cybersecurity into design requirements from the start can help manufacturers avoid many of these missteps.
Manufacturers commonly make two kinds of mistakes. The first is overlooking security issues entirely when making design choices. The second is implementing design choices that actually result in lower security. For example, many manufacturers use a password system to prevent unauthorized use of the device. However, the detailed requirements of the password system can have a major impact on security. Implementing a hardcoded, unchangeable password is completely different from implementing a password with complexity requirements that idles out of the system after 10 minutes. These detailed requirements are often overlooked during the requirements development phase. If you have a requirement for a password, then what are the password complexity requirements? How long will the system idle before timing out? How many bad tries are allowed before the user is locked out? What is the process for resetting the password? There is no one “right” answer here; manufacturers will have to balance usability considerations, the severity of risk if the device is breached by an unauthorized user, and the risk of patient harm if authorized users are locked out when the device is needed. However, failing to properly consider the details of the password system during the design phase is likely to result in a poorly considered implementation that introduces unnecessary weaknesses in the system.
Manufacturers have many design choices to make during the requirements development phase. Depending on the device, these may include:
All of these considerations need to be part of the initial design requirements. If specific design choices are not built into the requirements, they will not make it into the device architecture. It costs very little to change requirements at this stage. Making changes later in development or after testing because requirements were not properly developed can be very expensive and lead to costly delays in FDA approval and market launch.
Manufacturers should rely on some established best practices when developing requirements for cybersecurity. The National Institute of Standards and Technology (NIST) has developed a cross-industry Cybersecurity Framework3,4 along with standards for cybersecurity controls (NIST SP800-53)5.Cybersecurity professionals with specific expertise in medical devices can help companies translate these and other industry best practices into device-specific recommendations during the requirements development phase.
While requirements tell you what kinds of security need to be built into the system, the architecture tells you how the security requirements will be implemented. The architecture builds off the device requirements development stage.
For example, there are many options in implementing cryptography. The requirement outlines the intention: ensuring data is protected with encryption. During architecture development, developers must decide what form of cryptography to use and exactly how and when communication will be encrypted. Each choice has its own profile of risk, cost and usability. Without understanding these tradeoffs, it is easy to choose the wrong tool. The security solution needs to align with the goals of the requirement: is the ultimate concern about protecting data privacy, data integrity, or both? If data integrity is the only concern, cyclic redundancy checks (CRC)—simple error-detecting codes that can be used to verify that data received is the same as the data sent—may provide enough security. However, an even stronger version of integrity could leverage keyed-hash message authentication codes (HMAC).
Architecture review by a third-party security consultant familiar with medical device development can help to uncover places where the architecture does not meet the requirements or where there may be more secure or more cost-efficient ways to meet the requirement. Reviewers can help manufacturers ensure that all requirements are met in the most secure and usable manner and catch mistakes before proceeding to software development and physical prototyping.
Cybersecurity Risk Management
The cybersecurity risk analysis process is similar to safety risk analysis and should be conducted in parallel. This is an iterative process that begins at the requirements development phase and should be revisited each time significant changes are made in device design or architecture.
Risk analysis includes several steps and should be conducted by a cybersecurity professional.
Verification And Validation
Cybersecurity testing should be included in the submission process just like safety and human factors testing. The FDA does not have specific cybersecurity requirements, recognizing that cybersecurity solutions must be tailored to the device. However, they expect to see a cybersecurity risk analysis, along with mitigation actions taken, in the submission package for FDA approval. They have outlined specific expectations for cybersecurity testing in their premarket guidelines6.
There are different types of cybersecurity testing and evaluation that provide different kinds of information for manufacturers. Three of the most common include:
Security testing should be considered like insurance: you can buy a little or a lot, depending on your appetite for risk. Devices that have a high potential for harm or that may be particularly attractive to hackers justify a more thorough approach to validation and testing.Post-Market/Sustaining Engineering
Cybersecurity work isn’t done once the device goes to market. The FDA has released post-market guidance7 for medical device manufacturers. Manufacturers must have a strategy for updating the device as new security threats emerge and operating systems change, as well as processes for tracking and responding to newly identified threats. Some considerations include:
Future-Proofing Medical Devices For Cybersecurity
No device will ever be 100% secure; cybersecurity always involves tradeoffs with other design priorities such as accessibility, interoperability, usability and cost. An integrated approach to cybersecurity risk management throughout design will help companies make more effective and strategic decisions.Cybersecurity should be a priority for all medical device manufacturers with devices that run on any kind of software, even if the device is not currently connected to the internet, hospital networks or other devices. The future of medical device development is moving inexorably toward more connection and greater complexity in the digital ecosystems of the medical devices. Even if the current iteration of the device is not connected, chances are good that a future iteration will be. Manufacturers can “future proof” their devices and avoid the need for major overhauls in the next version by starting with secure design now.
Smart, connected devices bring tremendous value to patients and healthcare providers. With careful attention to cybersecurity, we can ensure that they deliver that value safely and securely.
Reduce your risks and meet emerging cybersecurity standards with DeviceSecure® Services from Battelle. We offer a comprehensive approach to security risk management, including software, hardware and embedded systems solutions in addition to identifying potential security threats and vulnerabilities.
Every day, the people of Battelle apply science and technology to solving what matters most. At major technology centers and national laboratories around the world, Battelle conducts research and development, designs and manufactures products, and delivers critical services for government and commercial customers. Headquartered in Columbus, Ohio since its founding in 1929, Battelle serves the national security, health and life sciences, and energy and environmental industries. For more information, visit www.battelle.org.
1 U.S. Food and Drug Administration, Office of Device Evaluation. (2014, October 2). Content of Premarket Submissions for Management of Cybersecurity Risk in Medical Devices. Retrieved February 5, 2017, from http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM356190.pdf
2 U.S. Food and Drug Administration, Office of Device Evaluation. (2016, January 22) Postmarket Management of Cybersecurity in Medical Devices: Draft Guidance for Industry and Food and Drug Administration Staff. Retrieved February 5, 2017, from http://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm482022.pdf
3 National Institute of Standards and Technology (2014, February 12) Framework for Improving Critical Infrastructure Cybersecurity. Retrieved February 26, 2017 from https://www.nist.gov/sites/default/files/documents/cyberframework/cybersecurity-framework-021214.pdf
4 Note: NIST released a draft update to the Cybersecurity Framework on January 10, 2017, which can be viewed from https://www.nist.gov/cyberframework/draft-version-11. A final version of the updates framework is expected later in 2017. The updated framework includes “new details on managing cyber supply chain risks, clarifying key terms, and introducing measurement methods for cybersecurity” (NIST).
5 National Institute of Standards and Technology (N.D.) “NIST Special Publication 800-53.” Retrieved February 26, 2017 from https://web.nvd.nist.gov/view/800-53/home
6 U.S. Food and Drug Administration, Office of Device Evaluation. (2014, October 2). Content of Premarket Submissions for Management of Cybersecurity Risk in Medical Devices. Retrieved February 5, 2017, from http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM356190.pdf
7 U.S. Food and Drug Administration, Office of Device Evaluation. (2016, January 22) Postmarket Management of Cybersecurity in Medical Devices: Draft Guidance for Industry and Food and Drug Administration Staff. Retrieved February 5, 2017, from http://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm482022.pdf