INTRODUCTION:
The widespread connectivity of electronic products to the Internet, including medical devices, creates an ever-increasing opportunity for cyber-attacks and possible compromise to the safety and privacy of these devices. Medical devices are unique in that they encompass several key aspects of concern; safety, privacy and ever increasingly used in a professional (clinical) and consumer environment. This post proposes a security-first, inception to end of life approach that leverages agile development and automation as the best way to improve security for medical devices.
Related:
- Addressing Cybersecurity Threats in Medical Devices
- FDA’s Role in Cybersecurity for Medical Devices
- New Approaches Needed for Medical Device Software Development
Guidance rather than regulation
The current environment for building medical devices under the FDA and other jurisdictions is guidance on recommended practices to build-in security. However, there is little concrete specifications on practices. Although this is consistent with the FDA’s approach in general, it might not be enough to ensure manufacturers are dealing with security at the correct risk level. Although there is harmonization of accepted development practices in IEC 62304, the only specific relationship the standard has to security is the management of risk. I dealt with this specific topic and another post. Since this post, the FDA has further clarified its role in medical device cybersecurity, in particular by making it clear the cybersecurity is imperative but also clarifying, for example, that FDAs role is not validate or test devices for security.
Cybersecurity is not optional
The FDA has made it clear to manufacturers that cybersecurity is not optional with the following statement:
“Medical device manufacturers must comply with federal regulations. Part of those regulations, called quality system regulations (QSRs), requires that medical device manufacturers address all risks, including cybersecurity risk. The pre- and post- market cybersecurity guidances provide recommendations for meeting QSRs”
It’s clear that the FDA doesn’t intend to regulate security practices but does expect that medical device manufacturers address security risks as they as they do other risks, e.g. safety and privacy. The implication is also that security can’t be bolted on after the fact but must be part of the inception, design, development and testing of a medical product.
Agile development and a lifecycle approach
In previous posts (1, 2) I advocated for a new approach to managing the security risk and how to incorporate software development tools into an end-to-end lifecycle approach. I won’t duplicate the content here but it’s important to reiterate the need to deal with security as part of risk management early in the development lifecycle and leverage both proven approaches to security and tool automation to reduce the extra workload required.
It’s idealistic to assume that all possible security risks can be managed during inception and design. Realistically, security must be dealt in a proactive and reactive fashion since the threat landscape can change during development and most certainly during deployment and the lifecycle of the product in the field. For this reason it makes sense to adopt an agile development method which is best suited to reacting to changes in requirements, scope of the product, marketplace shifts and security threats.
Software Development Tool Automation and Agile Development
One of the key parts of the Agile Manifesto is working software, the agile principles state “Working software is the primary measure of progress.” The implication here is twofold; working software is a key goal for each iteration and is a superior way of demonstrating what and how the software operates (instead of lengthy design documents, for example.)
Testing is critical in proving working software and automation is important in making testing efficient by increasing testing productivity, providing intelligence on where to test (isolating impact of new features) and collating results. Static analysis augments this by detecting bugs before they enter the project, at the developer’s desktop, and detecting highly impactful bugs and security vulnerabilities in the whole project and in third party and legacy code.
How Static Analysis Improves Security of Medical Devices in an Agile Development Environment
Static analysis helps agile projects by decreasing the backlog of defects by either finding them in existing code, in newly developed code or during build and integration cycles. In addition, static analysis can find security vulnerabilities and other bugs that are often missed or too complex to find with testing. Here’s some examples of the benefits that static analysis brings to agile development:
- Continuous source code quality and security assurance: Static analysis is often applied initially to a large codebase as part of its initial integration, however where it really shines is after an initial code quality and security baseline is established. As each new code block is written (file or function), it can be scanned by the static analysis tools and developers can deal with the errors and warnings quickly and efficiently before checking code into the build system.
- Tainted data detection and analysis: Analysis of the data flows from sources (i.e. interfaces) to sinks (where data gets used in a program) is critical in detecting potential vulnerabilities from tainted data. Any input, whether from a user interface or network connection, if used unchecked, is a potential security vulnerability. Code injection and data leakage are possible outcomes of these attacks which can have serious consequences.
- Third-party code assessment (SOUP): Most projects are not greenfield development and require the use of existing code within a company or from a third party (known as SOUP, software of unknown pedigree/provenance.) Performing testing and dynamic analysis on a large existing codebase is hugely time consuming and may exceed the limits on the budget and schedule. Static analysis is particularly suited to analyzing large code bases and providing meaningful errors and warnings that indicate both security and quality issues. GrammaTech’s CodeSonar binary analysis can analyze binary-only libraries and provide similar reports as source analysis when source is not available. In addition, CodeSonar’s binary analysis can work in a mixed source and binary mode to detect errors in the usage of external binary libraries from the source code.
- Coding standard enforcement: Static analysis tools analyze source syntax and can be used to enforce coding standards. Various code security guidelines are available such as SEI CERT C and Microsoft’s Secure Coding Guidelines or MISRA C and C++.
- Accelerate premarket submission: Static analysis tools in conjunction with other testing and lifecycle management tools provide automated documentation to support testing, coding standard and quality/robustness evidence. Much of the manpower used in safety certifications is documentation and evidence production, automation and specifically static analysis reduces this burden significantly.
CONCLUSION:
The FDA has made it abundantly clear that security for medical devices is not an option. In order to deal with a changing threat landscape, an agile development approach is recommended. Static analysis tools have an important part to play in an agile medical device development project; most importantly, the ability to support and enhance automated and manual testing and acceptance processes. Static analysis tools also fit well with the FDA’s published guidance on managing cybersecurity. Following a “security first” mindset and process, manufacturers can build-in security rather than make it an add-on.
