The Internet of Things (IoT) has changed the world. Arguably the industry most profoundly impacted by IoT is Healthcare . Connected medical devices are critical to providing patient monitoring, care, and comfort. Yet, for all convenient and even life-saving uses, Internet of Medical Things (IoMT) can also be a security risk. IoMT security is crucial because failures in their design or implementation have life or death consequences. Improperly securing medical devices could result in malicious actors altering a pacemaker’s pace or adjusting how much insulin is automatically injected into a person. IoT-focused cyberattacks have occurred in 82% of healthcare organizations. These attacks often stem from vulnerabilities in medical devices. How can organizations identify areas where vulnerabilities make their way into their products?
Throughout this three-part blog series, we’ll focus on vulnerability management for digital medical devices. In this post, we’ll explore how to manage vulnerabilities during the development process.
Note: The second part of this series, exploring how to prioritize vulnerabilities for remidiation can be found here. The third and final part, looking into the the people and roles needed for a succesfull vulnerability management program can be found here.
External Libraries: TTM vs. Risk
As organizations strive to accelerate the development of their products, they often utilize software libraries that come from other development teams or external parties. This allows them to incorporate functionality previously developed. Popular sources for these libraries are the open-source community (OSS), where developers freely contribute code for public use.
The downside of the OSS is the lack of standardized development and QA processes before code release. In commercial products, this process is formalized and adhered to rigidly. In open source development, the contribution is voluntary and processes are determined by the contributors as they see fit. This is important when support issues arise as vulnerabilities are not guaranteed timely remediation.
Some might consider avoiding this problem by using commercially available libraries to guarantee better quality and support. However, these libraries can also have limited lifespans and even they, with their more rigid and structured development processes, have vulnerabilities.
Using external libraries increases development speed, but it brings additional risks regardless of whether it is open source or licensed by the manufacturer. When bugs are present in the libraries used for development, they propagate into the finished software. To detect these potential vulnerabilities, medical device manufacturers (MDMs) need to know what libraries they utilize and keep track of them. Just because a library doesn’t have known issues does not mean that it is defect-free.
The Danger Is Real
An example of this happened with the Treck IP stack for embedded systems in 2020. Many organizations utilized this lightweight IP stack across a range of embedded products. This library was considered safe and reliable for a long time, which is why it was so pervasive in embedded systems. When the Ripple20 remote code execution vulnerabilities were discovered in Treck, each of the products using it also ended up inheriting that set of vulnerabilities. This required developers of embedded systems to scramble to find solutions quickly
To stay on top of this type of problem, organizations need to monitor for potential vulnerabilities continuously. If you have the source, organizations can proactively identify issues by including external libraries in their Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) scanning. Unfortunately, SAST tools tend to generate many false positives, which consume valuable resources and furthermore, not every library developer will give you access to the source code and a binary is all that is available. This eliminates the usefulness of SAST tools. Binary software composition analysis (binary SCA) offers deeper insight into the component and identifies security risks. Once a vulnerability is found, steps can be taken to mitigate the problem.
Gaps In Training
Supply chain developers are experts in creating code that runs quickly and efficiently; securing the code is often secondary. This is because secure coding requires an understanding of security best practices and the potential ways in which attackers could circumvent legitimate functionality. Mastering this skill requires training and practice, which means the investment of time and money.
Even though baking security into the product early in the development life cycle (SDLC) saves significant amounts of money in vulnerability remediation long-term, this is not always feasible for some suppliers. With tight budgets and a global skills shortage, teams can’t focus on security training and instead must focus on delivering a working product. This creates a catch-22 where vulnerabilities are more likely to emerge in the supply chain and require more costly remediation.
Automated Security Testing
Even when developers are skilled in secure development, there is still the potential for mistakes. Developers often face pressing deadlines and skip testing in favour of expediency. While less testing does speed up development, it also circumvents secure coding practices and eliminates the ability to identify vulnerabilities before release.
Automated binary SCA testing should be integrated into the CI/CD pipeline and baked into the process so developers can plan for it as part of their development cycle. Contextually aware binary SCA testing based on Cyber Digital Twins further enhances the software development process. They provide more accurate identification of relevant issues with fewer false positives, which is a significant advantage of binary scanning vs. source code scanning. This approach improves risk management decisions, reducing the overall risk for both MDMs and their customers, and provides quick and efficient remediation of vulnerabilities.
Building a Complete Program
Vulnerability management requires a complete toolbox to ensure all aspects are addressed. It requires a comprehensive program to deliver secure medical devices. The entire process needs to integrate with business workflows, operational systems, monitoring, and governance. Knowing all of the pieces and how they interact is a daunting task.
But knowledge is power. To learn more about all of the components that can help your organization build a complete vulnerability management program, download Cybellum’s eGuide The Blueprint. This comprehensive guide empowers you with best practices for preventing vulnerabilities from slipping into your product.
