Secure Design Transfer for Medical Devices

In the context of developing a new medical device, “design transfer” refers to the process of moving a product’s design from the development and engineering phase to the manufacturing and production phase. It involves transferring all the relevant information, specifications, documentation, and knowledge gained during the design and development stages to the manufacturing team so they can accurately produce the device according to the intended design and quality standards.

The phrase “design transfer” is often defined and discussed in standards related to quality management systems for medical devices. And of course, it is mandated by law in the Code of Federal Regulations 21 CFR 820.30(h): “Design transfer. Each manufacturer shall establish and maintain procedures to ensure the device design is correctly translated into production specifications.”

ISO 13485:2016 (7.3.8) is a little more descriptive with the following paragraph: “The organization shall document procedures for transfer of design and development outputs to manufacturing.

These procedures shall ensure that design and development outputs are verified as suitable for manufacturing before becoming final production specifications and that production capability can meet product requirements.”

The design transfer process is crucial to ensure the medical device is manufactured consistently, reliably, and in compliance with regulatory requirements, and there has been much written about all of the aspects of maintaining quality through this phase. However, these standards and regulations are old, and as such, do not explicitly address the topic of cybersecurity during design transfer.

Manufacturers do need to enforce cybersecurity, however; the regulatory mandate to enforce this comes in a non-obvious manner. In the latest FDA premarket cybersecurity guidance (April 2022—by the time you are reading this article, there should be a new and finalized version of this guidance,1 which we assume will be quite similar to the April 2022 version), there is a requirement for manufacturers to base their cybersecurity processes during development on existing standards. There are two very good standards just for this:

• NIST SP 800-218 Secure Software Development Framework (SSDF)
• IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle

The NIST standard is very well written, but it is not specifically written for medical devices, whereas the ISO/IEC standard is written for medical device software and has been formally recognized by the FDA.

From the NIST SSDF:

• PS.1.1: Store all forms of code – including source code, executable code, and configuration-as-code based on the principle of least privilege so that only authorized personnel, tools, services, etc., have access. With the two following examples:

• Example 5: Use code signing to help protect the integrity of executables.
• Example 6: Use cryptography (e.g., cryptographic hashes) to help protect file integrity.

• PS.2.1: Make software integrity verification information available to software acquirers. With the following examples:

• Example 1: Post cryptographic hashes for release files on a well-secured website.
• Example 2: Use an established certificate authority for code signing so that consumers’ operating systems or other tools and services can confirm the validity of signatures before use.
• Example 3: Periodically review the code signing processes, including certificate renewal, rotation, revocation, and protection.

• PS.3.1: Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release. With the following example:

• Example 2: Store and protect release integrity verification information and provenance data, such as by keeping it in a separate location from the release files or by signing the data.

While none of the NIST recommendations directly address the transfer to manufacturing, they do imply that such a relationship exists.

IEC 81001-5-1:2021 directly addresses this as follows:

• 5.8.3 File INTEGRITY

• The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to provide an INTEGRITY VERIFICATION mechanism for all scripts, executables and other SECURITY-relevant files used with a HEALTH SOFTWARE.
• This ACTIVITY (or ACTIVITIES) is required to ensure that PRODUCT users can verify that executables, scripts, and other important files received from the MANUFACTURER have not been altered. Common methods of meeting this requirement include cryptographic hashes and digital signatures (which also provide proof of origin).

In addition to all the other quality-related activities and deliverables required to support design transfer, we can also add integrity-related artifacts to this list.

There are various methods and techniques that can be employed to ensure the integrity of the data being transferred. Following is a list of some common methods for ensuring integrity in digital artifacts.

• Hash Functions: Cryptographic hash functions generate fixed-length hash values (digests) based on the content of a digital artifact. Any change in the content will result in a different hash value. By comparing hash values before and after transmission or storage, integrity can be vetted.
• Secure Hash Algorithms (SHA): SHA algorithms are cryptographic hash functions used to generate hash values. SHA-256 and SHA-3 are examples of widely used secure hash algorithms.
• Digital Signatures: Digital signatures use asymmetric cryptography to sign a digital artifact with the private key of the sender. Recipients can verify the signature using the sender’s public key, ensuring both the origin (attestation) and integrity of the artifact at the same time.
• Message Authentication Codes (MACs): MACs are cryptographic hashes that use a shared secret key between sender and receiver. They provide a way to verify the integrity and origin of a digital artifact. These include functions such as HMAC and CMAC.
• Public Key Infrastructure (PKI): PKI is a system that uses digital certificates and key pairs to ensure the authenticity and integrity of digital artifacts. It establishes a trusted hierarchy for verifying the identity of users and systems.
• Blockchain Technology: Blockchain is a decentralized and distributed ledger that records transactions in a secure and tamper-resistant manner. It’s commonly used to ensure the integrity of data and transactions, especially in highly dynamic environments where changes to the digital artifacts occur frequently.
• Audit Trails: Maintain logs of actions and changes made to digital artifacts. These audit trails help track changes and identify any unauthorized modifications. While this method will not prevent the possible corruption of a digital artifact, it can be used both forensically and to prove compliance, which is especially important when dealing with contract manufacturers.
• SLSA: (pronounced “salsa”) is a methodology for ensuring integrity and attestation in digital artifacts as they are created and moved through the development process. At least a level of Build L2 should be utilized and extended into the manufacturing facility. SLSA has been implemented in several tools, such as GitLab and GitHub Actions.
• File Integrity Monitoring (FIM): FIM systems continuously monitor digital artifacts for changes and alert administrators if unauthorized modifications are detected. There are both commercial and open-source tools for achieving this, such as OSSEC and Open Source Tripwire.

These methods can be combined and customized, depending on the specific requirements of the environment and the nature of the digital artifacts being protected. For example, a company with a low level of cybersecurity maturity may have developers create hash digests for released digital artifacts and transfer both to the manufacturing facility. Once vetted by the manufacturing facility, the digital artifacts are stored in manufacturing and the continued integrity of these artifacts is ensured by the use of a FIM.

However, a more mature company may implement SLSA across the entire development lifecycle, the design transfer process, and storage in the manufacturing facility, providing details of attestation, movement of artifacts, and artifact integrity.

By implementing these and similar measures, companies can secure the design transfer process and ensure their medical devices are manufactured consistently, in compliance with regulations, and with a focus on patient safety and product efficacy. 

Reference

1. bit.ly/mpo230531

---

Christopher Gates is the director of Product Security at Velentium. He has more than 50 years of experience developing and securing medical devices and works with numerous industry-leading device manufacturers. He frequently collaborates with regulatory and standard bodies, including the CSIA, Health Sector Coordinating Council, H-ISAC, Bluetooth SIG, and FDA to present, define, and codify tools, techniques, and processes that enable the creation of secure medical devices.