Facebooktwittergoogle_plusredditpinterestlinkedinmail

In 2008, Gartner predicted that by the year 2015, 99% of all Global 2000 enterprise software teams would be using open source software in their application development*. Well, it’s 2015 – and this is one prediction that has come to pass. In the case of medical devices, the use of open source software seems ubiquitous. Almost 100% of the medical device software we’ve assessed at OpenSky is using at least one open source package, and frequently more than one.

The rationale for using open source in application development makes sense. Open source software is a great way to speed time-to-market for a team by plugging commonly used functionalities (think logging or printing) into an application. It’s a win for the team because they don’t have to spend valuable development cycles and developer time to make that functionality available. It’s especially true in the case of encryption libraries where having a known framework that has been publicly used and evaluated is far safer than creating something in-house. But, we’ve discovered there are some caveats to the use of this software.

Medical_Devices_Security.jpg

Medical devices, however, present a different use case than the typical inclusion of open source in application development. For device manufacturers and healthcare organizations using a device, it’s the safety and security that is paramount. If we consider that medical devices are held (and must be held) to a higher standard of software quality – then using open source software presents a challenge. The challenge revolves around due diligence and careful vetting of any open source package that is used by a medical device manufacturer.

As part of a vulnerability assessment process, the application code is scanned and all positive findings are manually verified . Typically a number of flags are found that are raised by open source packages. Does this mean that the findings are critical and need patching yesterday? No. It most emphatically does not. But, a large number of positive flags, even of a less critical nature, tend to weaken the overall security posture of any application. It means that there may be weaknesses that could become critical and exploitable in the future. For medical device manufacturers, this has serious implications for how they manage their application code base.

As part of a security controls assessment, the development team is typically asked if they have assessed the open source software used in its development for security vulnerabilities or weaknesses. The answer is almost invariably: “No, why would we? It’s open source….” The assumption is that its security has already been adequately assessed by the open source community.

Of course, the assumption underlying the use and security of open source software is that the many eyes of the software community are observing, testing and ensuring that any discovered security “holes” are patched quickly. The users of the software are made aware of a patch – and the software is quickly secured. For some open source software, this is the case. Many software programs have active communities that do test, and quickly patch vulnerabilities as they are found. There are, indeed, “many eyes” on these projects. (One community that does a stellar job of this is the Drupal community.)  However, the idea that we can rely on volunteers to monitor the security of all the open source frameworks and libraries out there is a bit naive. As an example, there were nearly 8,000 security vulnerabilities disclosed in the national vulnerability database last year, and nearly 40 percent were in open-source software. Ostensibly, at least a few of those programs had active, engaged communities that were doing their best to identify potential issues.

The idea that all security vulnerabilities can be found without rigorous, systematic and iterative testing is simply incorrect. Even with that testing, weaknesses will still be discovered, because  software is deployed for different uses and in different environments.

Medical device manufacturers using open source software need to understand that, if they include open source software in their applications without completing a rigorous security review of the software, they are incorporating risk into their applications. This may be a risk they decide to accept. For other organizations, with lower risk tolerance or applications that are particularly sensitive in terms of user impact, security review is absolutely essential. Few companies are doing this now. But, as the security barometer rises and becomes a higher priority, with a more intense focus than it has had in the past, the need for this vetting becomes more visible and more necessary.

Open source is amazing stuff and teams rightly look to leverage it for its time-saving and economic advantages. It holds a deeply valuable place in application development – that is without question. But, relying on a volunteer open source community to secure the code running in a medical device simply isn’t an adequate standard of application security any longer. The standard for application security is rising for all applications and when it comes to critical medical devices deployed in a healthcare setting, the bar is rapidly becoming even higher.

Comply With FDA Medical Device Security Guidelines and Protect Patient Information


Source: Sky Chat IT Blog

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Leave a Reply

Your email address will not be published. Required fields are marked *