Prepare Your Medical Device Software for the New FDA Cybersecurity Guidance

As the FDA adds more cybersecurity requirements in their new software validation guidance, medical device manufacturers can turn to static analysis, the most effective method to address safety and security concerns and deliver predictable software.

As I mentioned in a blog post a few weeks ago, this year at Embedded World, we enjoyed significantly more conversations with medical devices manufacturers than ever before. So I thought I'd address the topic of many of these conversations, centered around cybersecurity and static analysis. It is clear that medical devices manufacturers are focusing on improving their software development processes to (a) address growing security threats, and (b) satisfy the FDA’s requirements, which are becoming more precise.

New Cybersecurity Guidance From the FDA

The FDA used to be focused on functional safety aspects of the systems, but now cybersecurity is a subject of equal importance. Even though safety and security are very similar (and you could easily argue that both of these things are simply about creating predictable software), the FDA is now considering cybersecurity as something that requires dedicated attention and measures.

There is a new FDA standard coming. In the draft “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices” we can read:

"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."

What Are the New FDA Requirements?

So what do the new requirements change, for the typical organization developing software for medical devices? Well, the requirements from the medical standards previously were not very specific regarding recommendations for testing. Even if we take a close look at the popular regulatory documents, such as IEC 62304 or the FDA General Principles of Software Validation, we won’t find a requirement to use static analysis or dynamic testing with code coverage. With the new standard, this becomes more clear, directly part of the submission.

In point VII.B of the “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices” we can find the recommendations regarding the content of the risk management report of a trustworthy device:

"4. A description of the testing that was done to ensure the adequacy of cybersecurity risk controls... c) static and dynamic code analysis including testing for credentials that are “hardcoded”, default, easily-guessed, and easily compromised"

This is a clear recommendation to define and follow the static analysis process. How to do it? A lot depends on the existing processes in the organization and the technologies used for the development.

How to Adopt Static Analysis for the New FDA Software Development Requirements

Many of our medical device customers, when starting from the ground up, have found success introducing static analysis for C/C++ by following these steps:

1. Review existing guidelines in the organization, and even if designed to be enforced manually, map them as much as possible to the checkers that are provided with the static analysis tool. A mature static analysis tool will likely cover most of them, and you can consider building custom checkers for the remaining guidelines that could not be mapped to static analysis checkers right away.
2. Review the popular coding standards, especially those created with security in mind, and select a subset of guidelines for your team to follow. When selecting the guidelines, it makes sense to follow the categorization from the standards and select the guidelines which are categorized as the most important. For example, for CERT guidelines you probably want to start with L1 guidelines, and for MISRA C 2012 (with Amendment 1) you will want to review mandatory guidelines.
3. Define the static analysis tool configuration, and include your organization-specific guidelines and selected guidelines (i.e. CERT). Do not enable all checkers at once, but start with a small subset to avoid flooding developers with violations.
4. Make sure your developers are able to scan their code immediately after it is created. It also makes sense to include the static analysis in the CI/CD process.
5. As the developers make progress and clean the source code, make sure to progressively enable more checkers from your list. At the end of the day, you want to provide evidence that you comply with the entire set of guidelines you selected (not that you stopped halfway through). To better orient yourself in the process, and understand your current progress, you can deploy a central reporting system to help you aggregate the testing data and monitor developer’s work. See example of this below:

Demonstrating Static Analysis Tool Suitability (Tool Qualification)

Since static analysis reports become part of the Quality Management System, you can’t use just any tool. FDA requires that all tools used in development and verification of the software be validated for intended use. There are different ways to demonstrate the tool's suitability for use in safety-critical development. Depending on the risk of the device, it could be as simple as re-using a certificate of compliance or completing the lengthier process of tool qualification.

Using a TÜV SÜD Certification

For the end user, the most convenient option is to take the credit for the work done by the tool vendor and re-use the certification that is granted for the testing tool by an external certification organization such as TÜV SÜD. Parasoft C/C++test, for example, is covered with a TÜV SÜD certification that can be re-used for demonstrating suitability for developing software according to medical standards such as IEC 62304.

Performing Tool Qualification

For the high risk devices such as Class C, you may need to actually validate the tool internally in your development environment. The intention is to provide the evidence that the tool operates according to its operational requirements, gathered in the project’s development environment. This is a very tedious and time consuming process.

The best situation is if your tool vendor can support you in this effort and provide a special Tool Qualification Kit, containing well-designed test cases, the automation framework to execute them in the project’s development environment, and automatically generate the documentation that can serve as the evidence for tool validation. Here again, Parasoft’s flagship product C/C++test, provides a very good support in the form of the automated tool qualification kit.

Hardening Medical Devices

Introducing static analysis of course is a dedicated effort, requiring developer time and cost. But it is a proven way to harden your system against malicious attacks. Deploying static analysis with a well thought-out set of security guidelines enables you to build systems that can stand up against unforeseen future attacks.

“MISRA”, “MISRA C” and the triangle logo are registered trademarks of The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. All rights reserved.