22 May
MDCG 2019-16 – Guidance on cybersecurity for medical devices
MD101 comments in their recent blog the new guidance on cybersecurity for medical devices: the MDCG 2019-16: “This guidance covers a broad range of topics applicable to all stakeholders in the medical device supply chains, and to end-users. It explains a bit why it is 46 pages long.
Section 1 – Introduction
The first section of the guidance draws the link between regulatory requirements and cybersecurity processes / artifacts. The figures 1 & 2 are quite a good synthesis of the MDR requirements covering cybersecurity. Note that these figures could be duplicated with several other topics, like electrical security, biocompatibility (and so on), and state-of-the-art applicable standards.
The topics listed in section 1.4 cover all topics where cybersecurity is involved. This list is very useful to assess where cybersecurity requirements shall be implemented in your QMS processes. E.g: design controls, post-market surveillance.
Section 2 – Basic cyber concepts
If you’ve already read documents like AAMI TIR 57 or the 2 FDA guidances on cybersecurity, you will retrieve in this section some information common to these documents. The novelty in this MDCG guidance is the link between these concepts and the MDR General Safety and Performance Requirements (GSPR).
We also retrieve in this section concepts of defense in depth, good security hygiene (basic security hygiene in FDA guidance), and the relationship between security risks and safety risks.
Another concept is introduced, not so easily found in other guidance: the link between usability engineering and cybersecurity:
[a vulnerability] should be regarded as an enabler of reasonably foreseeable misuse .
If an exploit exists, an user will use it with a probability to assess, linked to the user’s education level and the ease of exploitation based on use scenarios.
The concept of joint responsibility is also introduced. All stakeholders in the supply chain shall take their part of the job: medical device integrators operators, and users. Manufacturers, don’t be fooled by this joint responsibility: as usual, your responsibility will be engaged in case of adverse event. You shall have established processes to ensure the proper installation, deployment, configuration, and exploitation of your devices in a secure manner. Simply said, this joint responsibility doesn’t exonerate manufacturers. Quite the opposite, it engages the responsibility of other stakeholders.
Section 3 – Secure design and manufacture
Section 3 delves into technical details (as far as a guidance can do, it’s not a standard), with a list of good practices to ensure that the device is secure by design. These 6 best practices can be seen as the steps of processes found in IEC 62304 design and maintenance processes:
Security management:
4.1 of ISO 13485, for the security risk management process
5.1 of IEC 62304: Software development plan
6.1 of IEC 62304: Software maintenance
Specification of Security Requirements:
5.2 of IEC 62304: software requirements analysis
Secure by design, including defense in depth:
5.3 of IEC 62304: software architecture
Secure implementation:
5.4 of IEC 62304: software detailed design
5.5 of IEC 62304: software implementation and unit verification
and a precision on SOUP management
Secure Verification and Validation
5.6 of IEC 62304: software integration testing
5.7 of IEC 62304: software system verification
Management of security-related issues
6.2 of IEC 62304: Problem and modification analysis
9 of IEC 62304: Problem resolution
Security update management
6.3 of IEC 62304: Modification implementation
8.2 of IEC 62304: Change control
Security guidelines:
5.8 Software release
and also software documentation, see IEC 82304-1 section 7.
Security Risk management
Section 3.2 continues with recommendations on the security risk management process, especially the link between security risks and their impact on safety. A very important remark is present in this section, for the sake of clarity of safety risk management reports: safety risk assessment might list generic security related hazards (…). This is to avoid detailing every possible attack vector.
This section also insists on the fact that compliance to GSPR 1 to 4 requires to assess security risks. Thus, cybersecurity isn’t nested only in GSPR 17.2 on software, but is promoted to the first main GSPR’s.
Security capabilities
Section 3.3 lists some possible security capabilities for software. This list is absolutely not exhaustive. This is a good starting point, though.
Interestingly, this section also contains an analogy between the precedence of safety mitigation actions (section 6.2 of ISO 14971) and their security risk equivalent. Worth reading!
This section ends with a remark on the need to maintain safety and effectiveness but also performance requirements and efficiency of mitigation actions, with security capabilities. New columns to your risk assessment matrices?”
Please find the complete article here.
Please get in touch with us:
+49-176-57694801
