Medical Device Security

By Jeff Fortin

Jeff Fortin

A recent study published by GAO caused quite a bit of uproar over medical device security. The GAO declared in its report [read more] that the FDA has not put enough oversight in the premarket approval (PMA) of certain medical devices that are susceptible to threats. In the report the GEO referred to an experiment described in the 2008 IEEE Symposium on Security and Privacy. The experiment was conducted by a number of experts in security, medicine and engineering. They demonstrated the potential for a hacker to expose patient information as well as interfere with the correct operation of a medical device. The FDA has agreed to the GAOs insights – however pointed out that there have been no real world threats that have been reported to date.  According to the FDA, it did consider unintentional threats for information security, but did not consider information security risks from intentional threats until recently. In summary, the HHS – governing body for the FDA, concurred with the GAO recommendations and have initiated activity in this direction.  Medical device manufacturers must take the threat of security seriously.

Of all medical devices, devices that are implantable, portable or used in a home health scenario represent a growing concern for security and information privacy. I refer to these classes of devices as embedded medical devices. Developers and manufacturers of embedded medical devices are increasingly exposed to security risks as these devices become more complex and also connected to open networks. The good news is that in responding to this threat they need not operate in a vacuum nor do they need to re-invent the wheel. Best practices exist in other industries that can be leveraged by medical device manufactures. Of them the most straightforward is to design your products with security in mind. In other words, design for security. Here are a few things to think about when you design your medical devices.

Pre-market: Design for safety and security

Step 1: conduct an end to end threat assessment. Identify the threats, evaluate the impact of the test not only from the point of view of the manufacturer but also the end user and the ecosystem in which the device gets deployed.

Step 2: Develop an advanced system design for security. This may involve defining the workflows, partitioning the safety-critical function from non-critical functions, keeping the basic functionality alive in case of an emergency et al.

Step 3: Select the proper run time platform: Leverage technology such as a secure OS, embedded virtualization, and interoperable middleware. Also be sure to follow best practices regarding run-time and network configuration to improve the integrity of your design.

Step 4: Select proper tools and testing infrastructure for securing the systems

  • Create a software development plan following an established software development methodology (examples: IEC 62304, IEEE/EIA 12207)
  • Requirements analysis and traceablility
    • Requirements should include
      • Security manual including Standard Operating Procedures with a  method for updating
      • Risk mitigation requirements as identified in the End to End Threat Assessment
  • Test Plan and Test Case Repository (Wind River Test Management)
    • Include vulnerability testing to validate risk mitigation requirements
  • Identify data needed from the test results to support 3rd party reporting
  • Test Framework to help identify potentially malicious code
  • Test mechanism to simulate hacker attacks
  • Industry standard Fuzz testing to ensure protocol robustness

Production: Validate the system and ensure the right software is loaded into the system with no malware.

  • Validation and authentication is a relatively new domain for certain medical devices. Methods used in the IT space tend to assume a reliable, cheap and nearly permanent connection to the end device. Such assumptions are not always possible for medical devices that are either implantable, portable or used in a home health scenario. But there is technology available that could help here. Authentication services for access to the device as well as secure updates and secure boot technology are available for these types of devices. For instance in the upcoming release of IDP 1.0, Wind River will be including a Secure Boot feature that will leverage the root of trust and the Trusted Platform Module (TPM) to ensure that the software on the device is authorized by the manufacturer.

Post-Market:

  • Secure your applications. Lock down your applications to prevent unintended data access or  denial of service. McAfee provides excellent guidance as to how to qualify the applications that run on your product so as to prevent intrusion.
  • Adopt a comprehensive life-cycle support process. Security is a constantly evolving problem. Include security updates in the lifecycle management of your device. The current published practices on this topic such as IEC 80001-1:2010 generally only address enterprise applications but Wind River has been helping companies deploy secure embedded devices for decades and can help your company do the same.

Waiting for the adverse event to happen and reacting to security afterwards may be very costly. Think Stuxnet and how it is changed the way the energy sector looks at security. We can be proactive and design for security in medical devices. While designing security consider both the enterprise and the embedded aspects of security. The embedded security part is often overlooked and can seriously undermine the efforts in locking enterprise security at the back office and servers. After all, information (data) originates at the embedded devices and the integrity of this data determines all the workflows that follow it.

 

For additional information from Wind River, visit us on Facebook.

3 Comments

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>