Intertech Engineering Associates, Inc.

Build The Cybersecurity IN!

Build The Cybersecurity IN!

by: Gary Girzon

“Build the Quality In” is one of the pillars of lean manufacturing as first introduced by Dr. W.E. Deming and well perfected by Toyota Production System. The same practice should be applied to medical device cybersecurity. “Build the Cybersecurity In”, or face the consequences, as recently disclosed in FDA warning letter to St. Jude Medical (now owned by Abbott), on April 12, 20171. The letter is the latest chapter in issues concerning St. Jude implantable cardioverter defibrillators (pacemakers) and their wireless monitors. The full story continues to be well documented. Here’s a chronology of the key events: 

August 25, 2016 Muddy Waters, a hedge fund specializing in short stock positions, and MedSec, a medical device security firm, publish a report4 describing several vulnerabilities in the St. Jude devices, such as 

  • Debugging and development capabilities left on the device; 
  • Lack of encryption and authentication in the communication protocol between the implanted and external devices; 
  • Examples of ability to remotely crash the device and drain the battery 

MedSec claimed it had no choice but to go public in a joint press release with Muddy Waters since St. Jude had already known about these vulnerabilities and failed to address them.   

August – September 2016 – St. Jude refutes the Muddy Waters claims5. Muddy Waters responds to St. Jude6. University of Michigan cybersecurity researchers finds flaws in MedSec findings7. St. Jude Medical sues Muddy Waters and MedSec8. 

October 2016 FDA issues a “Safety Communication” on Premature Battery Depletion in St. Jude devices but recommends continued usage of devices9. FDA notes the investigation of cybersecurity allegations. Muddy Waters and MedSec release additional evidence (videos showing emergency shock, vibration and disabling of features) of how the devices can be compromised10, and St. Jude in turn responds11. MedSec hires an independent expert witness (Bishop Fox) to collaborate the original findings12. 

January 9, 2017 St. Jude releases a software update with cybersecurity fixes13. FDA issues another “Safety Communication” affirming the software update, with the recommendation that “health benefits to patients… outweigh the cybersecurity risks”14. ICS-CERT, a team within the NCCIC division of US Department of Homeland Security, issues an updated advisory on a “man-in-the-middle” vulnerability which has been mitigated by the software update15. 

April 12, 2017 FDA issues a “Warning Letter” to Abbott (St. Jude) describing several reliability and security problems, notably: 

  • St. Jude did not “confirm all corrective and preventative actions were completed, including full root cause investigation of actions to correct and prevent recurrence of potential cybersecurity vulnerabilities” 
  • St. Jude failed to perform a full verification of network port vulnerability – no threat testing was performed using an unauthorized interface. 
  • St. Jude did not fully address and incorporate a 3rd party security assessment commissioned in 2014 as part of its internal risk assessments. The 3rd party identified a “hardcoded universal unlock code as an exploitable hazard”.    

The FDA letter also noted several battery related issues not related to cybersecurity. Abbott’s initial response acknowledged the FDA observations – the company has 15 days to fully respond. Meanwhile, any such class III devices will not be approved for sale to the public. 

One hopes that St. Jude / Abbott, and other medical device companies, learn from this story. It may be that Abbott has addressed some of the issues noted by FDA, and either was incomplete in testing (such as not doing “negative” testing) and disclosing the changes (perhaps the “hardcoded universal unlock code” was removed). It may be that the cybersecurity fixes are more complex than originally thought, as could be the case when dealing with a communications protocol.  Clearly, St. Jude did not follow the FDA premarket guidance on cybersecurity16 and design it in at the beginning of the product creation. And by not acknowledging the full extent of issues found by Muddy Waters / MedSec early St. Jude at best created the perception of a cover-up. Even if no patients have been harmed by a lapse in security so far it’s the possibility that alarms the medical and patient communities. The FDA has recently released guidance for postmarket management of cybersecurity in medical devices17 in which methods collaboration and communication between medical device manufacturers, cybersecurity researchers, clearing houses and the public to disclose vulnerabilities is deemed integral to managing such threats. To be safe and secure, design the cybersecurity in at the start of the product lifecycle, model the threats, and be prepared for any new vulnerabilities.   

Medical Device Validation Series. Part 1 of 4

Medical Device Validation Series. This is part one of a four-part series on medical device validation practices.

Part 1, Introduction

The Food and Drug Administration (FDA) pays special attention to software because it is now embedded in a large percentage of electromedical devices, and the amount of device functionality controlled by software is continually growing. Software also controls many of a medical device manufacturer’s design, development, manufacturing, and quality processes, regardless of whether software is a part of the manufactured device.

Software failures often can be invisible and difficult to detect; thus, these failures can have disastrous consequences on the operation or quality of medical devices. For this reason, the FDA specifically requires validation of both device and quality-system automation software. Validation activities are meant to keep defects from getting into the software, as well as to detect and correct any defects that do end up in the software.

The FDA’s control over software used by medical device manufacturers is detailed in the Quality System Regulations (QSRs) found in FDA regulation 21 CFR 820. Software regulations focus on the development and use of two large categories: (1) software that is part of the device being manufactured and (2) software that is used to design, develop and manufacture the product or otherwise automate any part of the quality system.

Guidelines for complying with the FDA’s regulations are published by the agency as a “Guidance Document”. These documents are updated periodically, and new a guidance is issued as the need arises. While compliance with the guidelines is voluntary, the device manufacturer should be prepared to explain and defend any deviation from the guidances.

The most important FDA guidance available for the validation of software is the General Principles of Software Validation (GPSV), and can be obtained for free from the FDA’s website (https://www.fda.gov/downloads/MedicalDevices/…/ucm085371.pdf ). This is a “must read” for all software engineers and quality engineers working with software in the medical device industry.

From: Vogel, David A., Ph.D. “Validating Medical Device Software Includes and Goes Beyond Testing.” Medical Product Outsourcing Mar. 2006