US Food and Drug Administration releases Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions Draft Guidance for Industry and Food and Drug Administration Staff

June 11, 2022 |

Privacy and cyber security in the health industry is both critical and critically inadequate in the main.  Health organisations are notoriously vulnerable to cyber attack and poor privacy privacy practices on a day to day in person basis.

The US Food and Drug Administration (“FDA”) is in the process of revising its guidance to deal with cyber threats. To that end it is released the draft Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions and will be reviewing it in June and July.

The abstract provides:

The need for effective cybersecurity to ensure medical device functionality and safety has become more important with the increasing use of wireless, Internet- and network- connected devices, portable media (e.g. USB or CD), and the frequent electronic exchange of medical device-related health information. In addition, cybersecurity threats to the healthcare sector have become more frequent, more severe, and more clinically impactful. Cybersecurity incidents have rendered medical devices and hospital networks inoperable, disrupting the delivery of patient care across healthcare facilities in the US and globally. Such cyberattacks and exploits can delay diagnoses and/or treatment and may lead to patient harm.

This guidance is intended to provide recommendations to industry regarding cybersecurity device design, labeling, and the documentation that FDA recommends be included in premarket submissions for devices with cybersecurity risk. These recommendations can facilitate an efficient premarket review process and help ensure that marketed medical devices are sufficiently resilient to cybersecurity threats.

It is a very useful detailed and dense 49 page resource.  Impossible to summarise in a post.  For those interested in privacy law it is a great resource.

Some useful comments and insights include:

  • medical device security is a shared responsibility among stakeholders throughout the use environment of the medical device system, including health care facilities, patients, health care providers, and manufacturers of medical For the purposes of this guidance, the term “medical device system” includes the device and systems such as health care facility networks, other devices, and software update servers to which it is connected.
  • WannaCry ransomware affects hospital systems and medical devices  and there are vulnerabilities identified in commonly used third-party components, like URGENT/11 and SweynTooth, have led to potential safety concerns across a broad range of devices a
  • the implementation and adoption of a Secure Product Development Framework (SPDF) is a set of processes that reduce the number and severity of vulnerabilities in products throughout the device
  • With the increasing integration of wireless, Internet- and network- connected capabilities, portable media (e.g., USB or CD), and the frequent electronic exchange of medical device- related health information, the need for robust cybersecurity controls to ensure medical device safety and effectiveness has become more important.
  • cybersecurity threats to the healthcare sector have become more frequent and more severe, carrying increased potential for clinical impact, Cybersecurity incidents have rendered medical devices and hospital networks inoperable, disrupting the delivery of patient care across healthcare facilities.
  • increased connectivity has resulted in individual devices operating as single elements of larger medical device These systems can include health care facility networks, other devices, and software update servers, among other interconnected devices
  • software validation and risk analyses are key elements of cybersecurity analyses and demonstrating whether a connected device has a reasonable assurance of safety.
  • FDA requires manufacturers to implement development processes that account for and address cybersecurity risks as part of design controls
  • Cybersecurity threats have the potential to exploit one or more vulnerabilities. The greater the number of vulnerabilities that exist and/or are identified over time in a system in which a device operates, the easier a threat can compromise safety and effectiveness of the medical device.
  • A Secure Product Development Framework (SPDF) is a set of processes that help reduce the number and severity of vulnerabilities in products. An SPDF encompasses all aspects of a product’s lifecycle, including development, release and support. Using SPDF processes during device design may prevent the need to re-engineer the device when connectivity-based features are added after marketing and distribution, or when vulnerabilities resulting in uncontrolled risks are
  • an SPDF can be integrated with existing processes for product and software development, risk management, and the quality system.
  • SPDF processes aim to reduce the number and severity of vulnerabilities and thereby reduce the exploitability of a device. Because exploitation of known vulnerabilities or weak cybersecurity controls should be considered reasonably foreseeable failure modes for systems, these factors should be addressed in the device design. The benefit of following an SPDF is that a device is more likely to be secure by design, such that the device is designed from the outset to be secure within its system and/or network of
  • insufficient information pertaining to whether a device has undisclosed cybersecurity vulnerabilities or risks may be relevant to determining whether a device’s safety or effectiveness could be degraded;
  • user manuals may ot include sufficient information to explain how to securely configure or update the device may limit the ability of end users to appropriately manage and protect the device. To fully account for cybersecurity risks in devices, the safety and security risks of each device should be assessed within the context of the larger system in which the device In the context of cybersecurity, security risk management processes are critical because, given the evolving nature of cybersecurity threats and risks, no device is, or can be, completely secure.
  • Security risk management should be part of a manufacturer’s quality.  The QSR requires, among other things, that manufacturers’ processes address design , validation of the production processes, and corrective or preventive actions . These processes entail the technical, personnel, and management practices, among others, that manufacturers use to manage potential risks to their devices and ensure that their devices remain safe and effective, which includes security.
  •  The process for performing security risk management is a distinct process from performing safety risk management.  Effective security risk management also addresses that cybersecurity-related failures do not occur in a probabilistic manner where an assessment for the likelihood of occurrence for a particular risk could be estimated based on historical data.
  • security risk assessment processes focus on exploitability, or the ability to exploit vulnerabilities present within a device
  • manufacturers should establish a security risk management process that encompasses design controls , validation of production processes, and corrective and preventive actions to ensure both safety and security risks are adequate.
  • in performing risk analyses the device manufacturers should conduct both a safety risk assessment 9 and a separate, accompanying security risk assessment to ensure a more comprehensive identification and management of patient safety.
  • the scope and objective of a security risk management process, in conjunction with other SPDF processes  is to expose how threats, through vulnerabilities, can manifest patient harm and other potential harms
  • Known vulnerabilities should be mitigated in the design of the For marketed devices, if comprehensive design mitigations are not possible, compensating controls should be installed.
  • devices with any known vulnerabilities which are only partially mitigated or unmitigated by the device design,  should be assessed as reasonably foreseeable risks in the risk assessment and be assessed for additional control measures or risk transfer to the user/operator
  • risk transfer, if appropriate, should only occur when all relevant risk information is known, assessed, and appropriately communicated to users and includes risks inherited from the supply chain as well as how risk transfer will be handled when the device/system reaches end of support and end of life and whether or how the user is able to take on that role .
  • threat modeling includes a process for identifying security objectives, risks, and vulnerabilities across the system, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system throughout its It is foundational for optimizing system, product, network, application, and connection security when applied appropriately.
  • threat modeling should be performed to inform and support the risk analysis As part of the risk assessment, FDA recommends threat modeling be performed throughout the design process and be inclusive of all the systems.
  • the threat model should:
    • identify system risks and mitigations as well as inform the pre- and post-mitigation risks considered as part of the security risk assessment;
    • state any assumptions about the system or environment of use (e.g. hospital networks are inherently hostile, therefore manufacturers are recommended to assume that an adversary controls the network with the ability to alter, drop, and replay packets); and
  • capture cybersecurity risks introduced through the supply chain, manufacturing, deployment, interoperation with other devices, maintenance/update activities, and decommission activities that might otherwise be overlooked in a traditional safety risk assessment
  • security risks of the software components become factors of the overall medical device system risk management processes and documentation.
  • all software, including that developed by the device manufacturer (“proprietary software”) and obtained from third parties should be assessed for cybersecurity risk.
  • device manufacturers are expected to document all software components of a device and to mitigate risks
  • the manufacturer should include in premarket submissions a plan of how the third- party software component could be updated or replaced should support for the software.
  • The device manufacturer is also expected to provide to users whatever information is necessary to allow users to manage risks.
  • testing is used to demonstrate the effectiveness of design controls. Cybersecurity controls require testing beyond standard software verification and validation activities to demonstrate the effectiveness of the controls in a proper security context.
  • a manufacturer should establish and maintain procedures for verifying the device design which would confirm that the design output meets the design input requirements. A manufacturer must establish and maintain procedures for validating its device design which should include software validation and risk      analysis, where appropriate. Verification and validation should include sufficienttesting performed by the manufacturer on the cybersecurity of the system
  • Security testing documentation and any associated reports or assessments should be submitted in premarket submission.
  • manufacturers should provide :
    • evidence that each design input requirement was implemented successfully.
    • evidence of their boundary analysis and rationale for their boundary assumptions.
    • details and evidence of testing that demonstrates effective risk control measures according to the threat models
    • evidence of the adequacy of each cybersecurity risk control
    • details and evidence of testing pertaining to these known vulnerabilities:
      • Abuse case, malformed, and unexpected inputs,                                ·
      • Fuzz testing
      • Attack surface analysis,
      • Vulnerability chaining,
      • Closed box testing of known vulnerability scanning,
      • Software composition analysis of binary executable files, and
    • Penetration testing which should identify and characterize security-related issues via tests that focus on discovering and exploiting security vulnerabilities in the product.

Leave a Reply





Verified by MonsterInsights