Secure By Design And Default: Compliant Medical Device Development

By John Giantsidis, president, CyberActa, Inc.

Heightened awareness about cybersecurity issues has led regulatory agencies and customers alike to demand security and high quality from medical devices. An effective way to protect medical devices against cyberthreats is to integrate security — whether that is the FDA’s Quality System regulation (QSR), ISO 13485, or ISO 62304 — into every step of an established medical device development process. Medical devices that are secure by design start with that goal before the design process even begins to render products that are secure to use “out of the box” with little to no configuration changes. Furthermore, secure by design eliminates the integration problems, cost, and increased likelihood of vulnerabilities that comes with add-on security components.

Leading national agencies, like the Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Federal Bureau of Investigation (FBI), and international partners (“the agencies”),¹ issued recommendations for technology manufacturers to ensure product security and, thereby, assist medical device designers and manufacturers in meeting the quality system cybersecurity considerations mandated by the FDA.

Approach

Secure by design and default (SBDD) is an approach to medical device software and hardware design and development that seeks to minimize systems’ vulnerabilities and reduce the attack surface through designing and building security into every phase of the medical device development cycle, including security specifications in the design, continuous security evaluation at each phase, and adherence to best practices. Integrating security into medical device development includes:

• Early identification and mitigation of security vulnerabilities and misconfigurations of medical devices.
• Identification of shared security services and tools to reduce cost, while improving security posture through proven methods and techniques.
• Facilitation of informed key stakeholder decisions through comprehensive risk management in a timely manner.
• Documentation of important security decisions throughout the medical device life cycle, ensuring that security was fully considered during all phases.

Since the FDA has proposed to amend its current Quality System regulations to better align with ISO 13485, we would be using the same standard for the SBDD approach, under ISO 13485’s Clause 7 Product Realization.

Medical Device Security Planning

The medical device security plan aims to set a common understanding of security goals and objectives, identify key security roles, and develop a high-level security schedule and, through systematic security identification and cybersecurity risk management planning, identify the various threats and vulnerabilities to systems, determining the level of risk the medical device is exposed to, and recommending the appropriate level of protection. By now, a medical device design and development team should have established the following:

1. Key security roles and responsibilities in the development project;
2. A common understanding of the goals, implications, and considerations by the preliminary review of:
   1. functional requirements,
   2. threats and vulnerabilities,
   3. cyber risk identification, analysis and evaluation, and
   4. any early recommendations for security controls;
3. Key security milestones and activities for the medical device; and
4. The pertinent architecture and coding standards.

Medical Device Design And Development Security Requirements

ISO 13485 requires that records of design and development inputs must be maintained and must be able to be verified and validated. The agencies have provided a non-exhaustive list that could be used for finding and removing vulnerabilities in released software, mitigate the potential impact of the exploitation of vulnerabilities, and address the root causes of vulnerabilities to prevent future recurrences:

1. Use memory safe languages wherever possible. Some examples of modern memory safe languages include C#, Rust, Ruby, Java, Go, and Swift.
2. Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from verified commercial, open source, and other third-party developers to ensure robust security in consumer software products.
3. The device shall be able to back up system configuration information, patch restoration, and software restoration.
4. Use web template frameworks that implement automatic escaping of user input to avoid web attacks such as cross-site scripting.
5. Use parameterized queries rather than including user input in queries, to avoid SQL injection attacks.
6. Analyze product source code and application behavior to detect error-prone practices.
7. Ensure that code submitted into medical devices goes through peer review by other developers to ensure higher quality.
8. The device logs or audit trails shall not store personal identifiable information (PII) or sensitive data in clear text.
9. Incorporate the creation of a software bill of materials (SBOM) to provide visibility into the set of software that goes into medical devices.
10. Eliminate default passwords. Where passwords are used and, in any state, the medical device passwords shall be unique per device or defined by the user.
11. The medical device shall be able to log actions and activities performed on the device.
12. The device shall ensure that only authorized users are permitted to access the functionalities/resources according to their assigned permission.
13. Mandate multifactor authentication (MFA) for users.
14. The device shall be able to assign and segregate different roles (i.e., user, administrator and/or service accounts).
15. The device shall have the capability for the permanent deletion of sensitive or PII data from the device or media.
16. Encrypt data prior to transmission via a network or removable media by default.
17. Ensure data is not modified during transmission via suitable means.
18. Ensure, via suitable means, that the remote user performing remote administration on the device is authenticated and legitimate.
19. If appropriate, the device shall employ recommended industry standard Wi-Fi security protocols.
20. Local interfaces (i.e., USB, SD card readers) that support the use of removable storage media on the device shall be logically and/or physically disabled (i.e., tamper evident stickers, lindy port blockers) by default, if not required.

Medical Device Design And Development Security Testing

The security features of a medical device should be tested as part of the verification and validation activities. The following two type of tests are imperative to demonstrate and generate the requisite evidence for medical device cybersecurity:

• Fuzzing — The medical device is subjected to unexpected and erroneous inputs in order to find bugs. Fuzzing can be automated and can be done without access to your source code. There are various free and commercial products for fuzzing.
• PenTest — Penetration testing is an activity performed by dedicated security experts, who try to break into a service or system and point out security problems.

Furthermore, since it is relatively easy to introduce vulnerabilities to the code that supports or runs the medical device, and such, the code must be well documented, modular, readable, testable, and tested. Static analysis tools can find flaws by analyzing the source code. Static analysis tools can help immensely, so strongly consider their adoption in your medical device development program.

In addition to a thorough code review, emphasis should be placed on software composition analysis, which takes a compiled binary and then inspects which components have been used to assemble it. This process reveals the external dependencies a medical device has, which can be otherwise hard to enforce when the numbers of engineers, software developers, and modules in a medical device grow.

Conclusion/Further Considerations

Many medical devices – from glucose meters and insulin pumps to smart wearable devices, sophisticated software, and hospital equipment – are now deemed cyber medical devices by the FDA, and the FDA and other regulatory bodies around the globe have increasingly pursued medical device cybersecurity as a policy objective. SBDD is a key component of how cybersecurity will be improved within cyber medical devices. The culture, approach, and regulatory and customer expectations of how cybersecurity is addressed across medical device designers and manufacturers are changing. Cybersecurity was often bolted on at the end of a product’s life cycle and did not deliver secure capabilities into the users’ or patients’ hands.

Security isn’t treated as an add-on or an optional extra that can be traded out, and cybersecurity needs to be treated the same. With the ever-increasing cyberthreats that exist in the world, this new approach is essential. The approach will lead to the delivery of more secure medical devices and medical systems through clearer accountability, simplified processes, use of security standards, better guidance, more flexibility, and empowered decision-making.

References

1. https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf

About The Author:

John Giantsidis is the president of CyberActa, Inc., a consultancy headquartered in Boston, Massachusetts, providing data-driven digital, regulatory, cyber, and privacy solutions. The company's products and services are used by Fortune 500 companies, government agencies, and startups around the world. John is the Vice Chair of the Florida Bar’s Cybersecurity and Privacy Law Committee and a Cyber Aux with the U.S. Marine Corps. He holds a Bachelor of Science degree from Clark University, a Juris Doctor from the University of New Hampshire, and a Master of Engineering in Cybersecurity Policy and Compliance from George Washington University. He can be reached at john.giantsidis@cyberacta.com.