White Paper

Medical Device Cybersecurity Secure Design - From Concept to Commercialization

Medical Device Cybersecurity Secure Design

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:

  • Requirements Development
  • Architecture Development
  • Cybersecurity Risk Management
  • Verification andValidation
  • Post-Market/Sustaining Engineering

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.

Requirements Development

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:

  • Connectivity: How will the device communicate with users, other devices or the hospital network? Will the device use Wi-Fi, Bluetooth or Ethernetconnections?
  • Encryption: Does data need to be encrypted? If so, what type of encryption should be used? What protocols should the device use if it needs to communicate with another device with a less secure encryptionstandard?
  • Authorization method: How will the device limit access to authorized users? Will it use passwords, badges, dongles, biometrics or some other form ofauthorization?
  • Updates: How is the code updated? Will updatesrequire connection to the internet or hospital network? What will users need to do to start the updateprocess?
  • Data sharing: How is data input or extracted from the device? Does the device allow manual user input? Can data be exported to the hospital network or to another device? Does it import data from medical sensors or other devices?
  • Physical design characteristics: What types of peripheral interfaces (e.g., USB port, Ethernet connections) does the device have? How easy is the device to break into physically?

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.

Architecture Development

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.

  • Define the potential threats: Each device has its own unique threat profile based on its physicalcharacteristics and software architecture. How does data get into and out of the device (e.g., Wi-Fi, Bluetooth, USB, keyboard entry)? How is the data stored? Who or what other devices can access the data? How is the data used to drive device operation or make healthcare decisions? How is the code updated? These and other questions are used to define the kinds of threats to thedevice.
  • Define the threat characteristics: Cybersecurity analysis looks not only at the severity of the risk but also the probability. Would the device have to be specifically targeted, or could the harm result from commodity malware? For directed attacks, what levelof sophistication would be needed to carry out theattack? Would they need to have physical access to the device, or could the attack be carried out remotely?
  • Define the severity of the threat: What is the worst-case scenario if the vulnerability is exploited? As in safety evaluation, the first propriety is to evaluate the potential for patient harm if the device’s data or its code are compromised. For some types of devices, such as ventilators or drug delivery devices, malfunctioning has the potential to result in serious patient harm. Companies also need to consider other types of harm, including risks to patient data privacy and compliance. business risks must be considered, including the potential for the device to be used as a pivot intohospital networks to steal data or conduct data ransom attacks.
  • Develop a risk profile of the device: The threat characteristics and severity can be used together to develop a cybersecurity risk ranking for each threat. This risk profile can be used to make effectivemitigation decisions. Companies should determine their risk threshold and prioritize mitigation for threats that are above this threshold.
  • Define new security controls: At this stage, developers determine what changes must be made in physical design or software architecture to mitigate unacceptable risks. Again, this must be an iterative process that happens in parallel with safety evaluation and mitigation. Introducing new security controls may introduce new risks to patient

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 control evaluation: This process evaluates the security protocols implemented in the device toensure that they work as expected and follow best practices to mitigate known security threats. Ifcybersecurity was implemented correctly at the requirements and architecture development phases, there should not be many surprises. However, if new threats have emerged since the device requirements were developed, this process may uncover new security recommendations.
  • Fuzz testing: “Fuzzing” is a brute force method used to uncover coding errors and security loopholes in theinput handling portion of software. This involves throwing large volumes of malformed data at the device to see whether the device crashes or behaves in unexpected ways.
  • Penetration testing: This is the most sophisticated form of cybersecurity testing. Penetration testing is conducted by cybersecurity experts (sometimes called“white hat” hackers) familiar with hacking methods used by malicious actors. It requires hands-on access to the device or a prototype. Testers attempt to get through different layers of defense, starting with the exterior of the device and working inward through different levels of interior security measures. This process is used not only to test defined security protocols but also to look for unexpected loopholes that were not considered during the requirements and architecture development phases.

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:

  • Post-market monitoring: Companies must have processes in place to keep track of new vulnerabilities and respond to them as they emerge. The cybersecurity landscape is always changing; no matter how secure your device is a year from now new threats are likely to emerge. Companies must have policies in place to determine the threat level posed by the new threat and decide when and how to respond. Some threats may require an emergency patch to be pushed out immediately, while less critical threats can be addressed in the next regular software update.
  • Device updates: The device must have a secure method for pushing security updates. If the method of connecting to the device to update software or push patches is not itself encrypted and secure, the device can be opened up to significant new vulnerabilities.
  • Responsible disclosure policies: Risks uncovered by outside agents, accidentally or through deliberate probing, can expose manufacturers if they do not have a publicly accessible reporting mechanism and clear internal procedures for investigating and mitigating reported risks. Responsible disclosure is a model for vulnerability disclosure that provides channels whereby security researchers or users can tell the company about a vulnerability they have discovered without fear of legal reprisal. In addition to having reporting protocols, companies must have internal policies for evaluating, responding to, and communicating identified threats.
  • Knowledge sharing: The FDA recommends thatmedical device manufacturers participate in an industry-specific Information Sharing and Analysis Organization (ISAO)in order to share updated information about identified security risks. Because many medical devices use the same operating systems and software libraries and exist in the same digital ecosystem of networked and connected devices, ISAOs can help to identify common vulnerabilities and accelerate the development and dissemination of mitigation strategies.

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.

DeviceSecure® Services

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.

  • Secure Design: We offer a full spectrum of cybersecurity solutions, including cybersecurity risk management and threat modeling (AAMI TIR-57 & NIST 800-30), security requirements development, RMF and FIPS architecting and consulting, human factors analysis of security controls, and third-party security review of design, architecture and code.
  • Let us help you characterize, assess, model, predict and measure the broad spectrum of threats and vulnerabilities posed by your medical device. We offer Whitebox and Blackbox penetration testing, application and protocol fuzz testing, reverse engineering of software and firmware, security systems testing and system hardening.
  • Protect your IP and your users from risks caused by tampering, hacking and counterfeiting of medical devices. We can help you develop tamper- and counterfeit-resistant designs and assure the quality of your sourced components.

 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