In a previous post, I discussed the role of static analysis in managing cybersecurity for medical devices. It was in reaction to initial guidance published by the FDA in the document “Premarket Submissions for Management of Cybersecurity in Medical Devices.” Since that time the FDA has updated the guidance and current has this update in draft form, “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices” which supersedes the previous guidance (once finalized.) This post is to address some of the changes in the guidance and update our position on how static analysis helps medical device developers improve the quality and security of their products.
Some Highlight from the New Guidance
The new guidance differs from the 2014 document in several key ways that make more specific requirements around important security practices:
- Recognition of increased connectivity as a leading vector of cyber attack, presumably recognizing the role of medical devices in the Internet of Things:
“Medical devices capable of connecting (wirelessly or hard-wired) to another device, to the Internet or other network, or to portable media (e.g. USB or CD) are more vulnerable to cybersecurity threats than devices that are not connected”
- Introduction of tiers of cybersecurity risk. Devices where a security incident can result in patient harm are considered tier 1, “Higher Cybersecurity Risk”, and anything else is tier or “Standard Cybersecurity Risk.” This helps clarify the guidance since not all devices require intense cybersecurity review, especially if they aren’t connected or connectible. Class III devices where a failure may lead to sever harm or death, might be classified as Tier 2 for cybersecurity if they are completely disconnected from any network or external access.
- FDA guidance now applies the NIST Cybersecurity Framework which is mature, well researched and recognized across industries. This change makes sense and prevents the FDA from duplicating the work of an existing framework.
- Verifying authorization for safety critical functions is spelled out specifically in the new guidance.
- Code, data and execution integrity are now stated in the new guidance.
These are important changes and I think it clarifies the guidance provided in 2014. However, I don’t think this impacts our previous recommendations on using static analysis tools as part of secure-by-design process for medical devices.
How do Static Analysis Tools Help Improve Security for Medical Devices?
Static analysis tools are a staple in the tool chest of organizations building safety critical software. The majority of software development costs come from finding and then fixing problems in code, so discovering defects early in the development cycle helps reduce risk and cost in the following ways:
- Finds defects before unit testing: Static analysis tools can be used right at the developer’s desktop environment and can prevent defects before they enter the build system and the unit test phase of development.
- Finds defects that testing misses: Unit testing, even on projects demanding high code-coverage levels, can still miss important defects.
- Prevents defects in the first place: Enforcing strict coding standards, such as MISRA C, can help prevent many classes of defects in code from the beginning. Enforcing good discipline in coding and creating a develop-analyze-test micro cycle for small code changes can prevent many defects from being created in the first place.
- Analyzes SOUP: Use of third-party code such as commercial off-the-shelf software (COTS) and open-source software is common in medical device software development. Software of unknown pedigree (SOUP) needs to be managed carefully for safety and security before inclusion in a device. Static analysis tools can analyze third-party source and in the case of GrammaTech CodeSonar, binaries to discover defects and security vulnerabilities in software that could be impossible to test otherwise.
- Accelerates premarket submission: Static analysis (and many other testing and lifecycle management tools) provides automated documentation to support testing, coding standard, and quality/robustness evidence. Much of the manpower used in satisfying safety certifications is documentation and evidence production – automation (specifically static analysis) reduces this burden significantly.
Summary
The updated FDA guidance on managing cybersecurity in medical devices looks like an important step in clarifying what’s required for due diligence in security in the industry. These changes don’t change the need to design-in security and making secure practices part of the day-to-day workflow. This updated guidance also doesn’t change the benefits that static analysis tools bring to helping secure medical devices and I’ve reiterated them here again.
Interested in learning more? Read our Guide “The Role of Static Analysis in Management of Cybersecurity in Medical Devices”
{{cta(‘b850329c-2041-47aa-92b8-c8494e5c9e31’)}}
