Software Of Unknown Pedigree (SOUP) is a term used to describe any external code where the internal development team is unsure of security. Implementing exclusively internal solutions for every aspect of software development is rarely efficient. With the massive amount of external tools and libraries available, there is a solution for almost anything. This can be a massive time saver and lead to increased efficiency and functionality, though it also runs the risk of introducing risk. Careful analysis of these external software sources can help to mitigate this risk.
Creating a Software Bill Of Materials (SBOM)
As of Oct 1, 2023, it is now mandatory for new medical devices being released to the market to include a Software Bill Of Materials. This cuts down on the risk of including insecure code in an otherwise secure device and massively reduces the risk of supply chain attacks. The frequency at which new vulnerabilities are discovered is staggering; keeping track of everything can be extremely difficult. Even secure dependencies during initial development may become vulnerable during the development lifecycle.
The first step in analyzing the security of external sources is to identify all outside components actively used in the development environment. While this sounds simple, it can be easier said than done, especially in larger environments. When many people work on a project, lists of dependencies can get massive and difficult to track. The best way to stay on top of this is for developers to enforce good documentation practices to prevent anything from being missed.
Aside from reviewing how well-documented software is, there are a few other ways an SBOM can be generated. Analysis of programs during build time and during run time can give a better picture of all the components being used. This is done by looking for calls to outside sources and seeing how those sources are being used in the program. This will often provide a more complete list of everything being used in the software, though it is often best to use a combination of techniques.
This should not be a one-time process. New software analysis should be done when major changes or new components are implemented. This helps prevent problems with documentation falling behind and is a good way to catch vulnerabilities as they come up. Even if no major changes were made, review should still be regularly done to ensure no old dependencies have recently discovered vulnerabilities.
This is an extremely important step for medical devices before they are produced for larger scale and public use. Due to the potentially massive impact of vulnerabilities being identified in medical devices, great care must be taken to ensure that every step is being taken to keep security at the forefront during all stages of production. This also streamlines the process of getting FDA approval, which cuts down on the time to get devices to market.
Controlling Vulnerabilities In External Components
After generating a comprehensive list of external components used in a device, the next step is working around the vulnerabilities present in 3rd party sources. Managing vulnerabilities can be a difficult task, especially without direct control of the vulnerable components. Security solutions must be unique to the environment to provide maximum benefit, and medical devices are no different.
The easiest solution for vulnerable components is to update them to the latest version. This is great when vendor solutions are available for identified vulnerabilities. Updating components is going to be a very fast solution, but it is unfortunately not always possible. There can often be dependency problems where newer software versions do not work well with certain other components. Vendors also can be slow with fixes, or, in some cases, not publish one at all
When these problems arise, there need to be other solutions. A fast and simple one is to find an alternative solution, though this can often be expensive and may not have the same levels of functionality. In some cases, vulnerable functionality can be mitigated in other ways. Often, there will be a single vulnerable functionality that can be exploited. If this functionality is completely avoided, it can reduce the associated risk. There can often be other workarounds that get published for identified vulnerabilities. When properly implemented, these will go to great lengths to keep devices secure.
Test Medical Device Security With Blue Goat Cyber
Our team can work with you to meet the latest FDA requirements and reduce the time needed to get your product to market. Our team is highly experienced in medical device security, and we help bring your devices to top security standards. Contact us to schedule a consultation.
