The Department of Homeland Security (ICS-CERT) recently issued more warnings about cybersecurity vulnerabilities which has become all too common in recent months. In most cases, these vulnerabilities are found by researchers or the manufacturers themselves. It’s encouraging that discovery is improving but it’s discouraging that so many of the vulnerabilities are right out of “security 101.” For example, the use of hard coded credentials for external access and code injection from un-sanitized external input.
These bulletins follow a recent increase in medical device warnings from the DHS. The FDA has recognized cybersecurity as a critical part of software development and they released recent guidance on cybersecurity to make sure manufacturers are taking the matter seriously. However, this doesn’t cover products already in the market and may not be enough to impact products already under development.
Given the increased scrutiny of medical devices and the potential for harm to patients what are the options open to manufacturers? The answer depends on which stage of development they are in. In the early stages of development is by the far the easiest place to adopt better security practices. In fact, this should already be the norm for medical device developers. However, products that are in later stages of development or already productized and on the market, are much harder to deal with. Despite this there are options available and advanced static analysis has a role in improving quality and security at any stage of development.
Threat Assessment and Security Audits
It’s never too late to perform a system-wide threat assessment on a product. In fact, some of the issues disclosed in the CERT advisories could have been discovered during an assessment. In many cases, however, external expertise is required and companies may shy away from the intellectual property exposure or the potential impact of the assessment on their current products and projects. Regardless, the understanding of the attack surface and potential threats from such an assessment are critical to improving security in the long term. Although threat assessments are often manual and without tool support (depending on what they entail), they are a critical first step into improving overall product security.
A security audit is a next step or integral to the system wide threat assessment and although it isn’t only based on source and binary analysis, static analysis tools play an important part in evaluating the security “health” of the code base. Although it’s ideal to start using static analysis as early as possible it’s still very useful even for products that are already on the market. In fact, the FDA used GrammaTech CodeSonar to do an independent evaluation of source code for various commercial infusion pumps following a series of device failures. The outcome of the threat assessment and audit(s) result in a “to do list” of improvements to make on the product. Whether these improvements are economically feasible in an already fielded product is a different discussion. Despite this, there’s still ways to understand a product’s current security status and a path to improvement rather than depending on issues discovered by external sources.
Applying Static Analysis in Late Stage Development
The role of static analysis tools in products that are either already manufactured or near completion is more of an audit tool than a day-to-day software development tool. Long term, this should be the goal for any new development henceforth. As a security auditing tool, static analysis can detect security vulnerabilities and other quality issues that extensive unit and system testing may have missed.
Applying static analysis tools to an existing code base requires some initial effort to make sure the tool understands the code properly. In most cases, it’s parse errors that come from missing information about the software build. However, once an initial analysis is complete, it’s possible to focus the static analysis reports solely on high priority, high risk security warnings. By analyzing these warnings, the development team can decide whether there’s a likelihood of exploiting the vulnerability and the associated risk from an attack. CodeSonar has filtering and priority assignment capabilities that allows teams to quickly build their security must-fix list.
Digging into SOUP
Risk management of third-party software and other SOUP (software of unknown pedigree/provenance) is already a required activity for FDA pre-market approval for medical devices. However, this scrutiny may have missed important security testing and analysis. Static analysis tools provide quality and security assessments of code without extensive hands-on testing or understanding of the code or source. Security vulnerabilities and serious bugs can be detected and analyzed for cause and effect. Detailed reports can be sent to software vendors or internal teams for reparation.
GrammaTech’s binary analysis technology, built into CodeSonar, can evaluate object and library files for quality and security vulnerabilities, augmenting static source code analysis by detecting tool-chain induced errors and vulnerabilities. It can also be used to evaluate the correct use of library functions from the calling source into a binary object, making the combination of source and binary analysis a very powerful tool indeed.
Although the possibility of investigating and fixing issues found in third-party code is often limited, it does provide a bellwether of the security of the code. Customers of commercial off-the-shelf (COTS) products can go back to technical support of the vendor and ask for confirmation and analysis of the discovered vulnerabilities. Key here is that the impact on risk management is better understood — third-party software with a large number of vulnerabilities found using binary analysis must be dealt with appropriately in the risk management plan.
Applying Static Analysis in Early Stage Development
Using static analysis tools as part of the development process, as early as possible, is the ideal situation. Finding and fixing security vulnerabilities and other bugs before they become a problem later in the lifecycle has a significant impact on overall product quality. This is a topic I’ve discussed in a previous post so I won’t repeat it here although the gist is: Static analysis finds bugs and security vulnerabilities that “slip through the cracks” of traditional testing and prove invaluable when dealing with third party code (“SOUP”) and proving due diligence when applying for a premarket approval. Manufacturers can leverage static analysis tools immediately on existing products and adopt them as standard practice in new products.
Conclusion
A recent increase in DHS ICS-CERT advisories on medical devices certainly raises concerns about the security of medical devices. Although products already in the marketplace are harder and more expensive to fix there is still an important role to play for proper security practices. These practices include threat assessments and security audits and the continuous application of static analysis tools to detect security vulnerabilities. Products like CodeSonar are designed to work with large legacy code bases and still provide significant benefit in tracking down quality and security issues. In the long term, the application of static analysis on an ongoing basis early in the SDLC for new products is encouraged.
