Medical Device Security – A Challenge to Overcome

The device security challenge is how to deliver cutting edge therapies without falling prey to cutting-edge cyberattack strategies. Medical devices’ data-security is part of and directly influences the safety of said device. In the US, the FDA gives guidance on cybersecurity for both pre and post market in the form of a requisite 510K premarket submission from manufacturers. IEC 62443, IEC 62304, and ISO 27001 are just a few of the many standards and guidelines specified for the cybersecurity of medical devices. HIPAA among other regulations enforces the protection of user confidential data and patient privacy. Across the world, different jurisdictions have their respective regulatory authorities that mandate similar requirements.

Development of a secure device needs two foundational considerations

1.          Protecting the device from known issues

2.         Protecting the device from future issues

Security vulnerabilities are errors (or defects) that expose an application to the unintended influence of other internal or external applications. Security vulnerabilities are in every product and can be inherited from the components used to design the product. Often, these vulnerabilities are discovered after products are deployed to the market. Therefore, as a device manufacturer, you must consider the security threats of not only the present, but also the future.

When designing your device, you need to understand how the device might be attacked by unauthorized users. There are many ways to understand this for your device; a common technique is a Threat and Risk Assessment (TRA), there are many other methods that can be employed here. The results of the analysis will lead to functional requirements that improve the security of the device; some of these are:

When it comes to the implementation of these requirements in software, you must begin by referencing the past. Many security issues are known to the worldwide community. The main source of knowledge is called CVE (Common Vulnerabilities and Exposures), a joint effort of MITRE Corp and the National Vulnerability Database. You should verify that no known CVEs are in your device before release. There are several tools that can help tackle known CVEs. Your teams should also reference the most common coding and design errors using readily available information such as the OWASP Top-10 (https://owasp.org/www-project-top-ten/) and make sure your development and verification processes ensure that these common mistakes are avoided.

It’s also important to remember that most (at least, the well-made) medical devices are meant to last for several years. It is of utmost importance to consider how securely and how often the device will be updated; how the downtime will be minimized; how the user data will be protected in the process.

Over 300 CVEs are identified each week. Most of these won’t be applicable to your device. An impact analysis will be required to determine which will. Then you will need to find patches for applicable CVEs. The Linux community typically provides patches for current release and sometimes the previous release of each package you might use. But, how will you handle CVE patches if the community does not provide one for the version you are using? This necessitates continuous monitoring for CVEs that can expose your device to attacks; secure device updates to address future CVEs

It is important to understand that, at the time of release, any product is likely to have vulnerabilities not yet known to you or the community. Bad acters can find these figurative chinks in your armor. You must beat them to it. When the “bad guys” try to access your device, they use a number of techniques. Some of these can be used during testing to help secure your device. 

Fuzz Testing- Probing the device with large amounts of valid and invalid data packets and see what happens. These packets can be randomized to verify that your device will withstand an attack.

Penetration Testing-The things the “bad guys” do are well known to the security community. Security experts are available to perform these techniques on your device. This way, if exploits are found, you can fix them before release.

Making a device secure requires considerations throughout its lifecycle… But most of this consideration must come up-front. As a manufacturer, you need to equip yourself with the right tools that will keep you and your customer secure. And now, more than ever, you can do it!

Learn more in this white paper Minimizing Device Security Vulnerabilites using Embedded Linux