Verify efficacy and effectiveness of Risk Control Measures

Security risk control measures shall be verified. Their testing shall be part of the software verification plan of the product according to IEC 62304. While some dedicated tests shall be developed for the security risk control measures specific to your product, others are more standard:

Common Vulnerability testing

Check that all identified common vulnerabilities associated to the use third party components are handled either through the integration of a patch or through the provision of a clear rationales explaining their non-applicability.

Malware testing

Ensure that no malware is embedded in your software, in the third-party components or in the used operating system using malware screening software.

Malformed Input Testing

Every check developed to validate external data must be verified. This includes, but is not limited to:

• Verify proper behavior of input files authentication using cryptographic signatures,
• Verify that the product is not impacted by malformed inputs (reject data making no sense) which could result in an attempt of hacking,
• Verify proper behavior of peer authentication before data exchange,
• Verify proper behavior of code impacted by external input(s). Fuzzing tools like American Fuzzy Lop (AFL) may help in this process.

Figure 1. AFL Screenshot

Penetration testing

The best way to verify that all vulnerabilities are correctly fixed is to request a penetration testing lab to confirm that none of them can be exploited.

Structured penetration testing is required by UL 2900-1, section 16. Penetration testing should be run by an independent lab. Such test should be first performed as “Black-box testing”, which means that testers will try to find and exploit vulnerabilities with no (or very little) knowledge of the device. Then, “White-box” testing should be run, where all valuable information (even source code or schematics if necessary) is provided. Also, providing the list of identified CVEs will help the lab confirm that the device does not contain weaknesses.

Security risk management report

A security risk management report shall be generated to summarize the plan followed, the activities performed, and the list of documents generated including a list of the identified threats (from your own device and from third-party components), the associated risk control measures or rationales for their absence, the results of the verification campaign and the instructions for use related to security.

The security risk management plan mentioned in the report must define what are the next expected actions regarding security (improvements and periodic reviews).

It may happen that some of your threats or vulnerabilities verification is not fully successful: this shall be documented within a list of known anomalies. For those remaining anomalies, clear and convincing rationales shall be provided to argue why those anomalies are acceptable for the ongoing software release. If they are not acceptable, those anomalies shall be fixed before releasing the software.

Release & Distribute Update

Once your system is fully verified and validated, the software version can be released and made available for design transfer and manufacturing. If your system is a standalone software, this means that you can generate your installation files based on this software release. However, the efficacy and effectiveness of the installation files must be validated through the verification of the proper behavior of the software installed using these installation files. This can be done using a sub-set of your verification tests: the installation, operational and performance qualification tests.

Once the proper behavior of the installation files verified, you can finalize your technical documentation for submission to authorities and/or inform your users about the availability of security updates for their installed software. The procedure and tools for such software security update shall be already available to your customers.

Debiotech recommends:

• Integrating within your system a way to inform your users that a security update is available.
• Integrating within your system a way to easily update their product version with the new one.

Market withdrawal and decommissioning

The security risk management plan shall also include actions required when decommissioning a device. Those actions shall ensure that no sensitive data remain accessible to possible technical or customer services after decommissioning of the device.

Regulatory landscape

From a regulatory standpoint, data protection and data privacy are usually treated in the same texts. Data security on its side has its own legislations. The applicable regulations usually depend on the type of data: health-related data are usually associated with stronger requirements in term of privacy and security.

Data protection & privacy:

• Europe: GDPR (Europe),
• Switzerland: Federal Act on Data Protection,
• US: HIPAA and numerous data protection laws enacted on both the federal and state levels.

Data security:

• US: HIPAA
• International:
  • UL-2900
  • ISO 27000 Series
  • NIST Cybersecurity Framework

Authors

	Rémi Charrier Business Development Director r.charrier@debiotech.com
		João Budzinski R&D Director j.budzinski@debiotech.com
	Laurent Colloud Software Project Manager l.colloud@debiotech.com
		Gilles Forconi Software Quality Manager g.forconi@debiotech.com

Next steps

Debiotech is glad to have the opportunity to share its knowledge with innovative companies from the MedTech industry. Your feedbacks on this publication are welcome and will be used to update it or to create new publications on topics you care about.

Continue your education on medical device development by:

• Accessing Debiotech historic publications: https://www.debiotech.com/news-grid/
• Following Debiotech on LinkedIn to be notified on new publications: https://www.linkedin.com/company/debiotech-sa
• Contacting us to ask a question or request personalized support: contact@debiotech.com

Debiotech would be proud to be your partner and support you with:

• Medical device design & development services:
  • Software: Digital Health, Firmware, Embedded, SaMD
  • Electronics: Design, Verification and Validation
  • Mechanics: Design for micro-fabrication & fluidics systems
  • Supply chain development and optimization

• Support in medical innovation management:
  • Market analysis and segmentation
  • IP management
  • Business plan consolidation
  • Partnership development