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.
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.”
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.
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:
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.
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.
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.
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.
Product Manager for Parasoft's embedded testing solutions, Miroslaw's specialties include C/C++, RTOSes, static code analysis, unit testing, managing software quality for safety critical applications, and software compliance to safety standards.