12 Nov Cybersecurity – An Imperative in Medical Devices
Cybersecurity in medtech? You’ve got to have it. The rising tide of connected medical devices, data collection and the IoT makes cybersecurity the ominous buzzword of the healthcare industry. Key Tech’s cybersecurity approach is founded in our expertise in designing medical devices. Key Tech’s three-step de-risking process of threat evaluation, secure coding techniques and protocols and utilization of our cybersecurity design process are designed to help your company manage the risks inherent in software and cloud-based medical devices.
Why is Cybersecurity so Critical for Medical Devices?
Even global medtech companies have cybersecurity issues. [i] There have been multiple devices like the Medtronic MiniMed Insulin Pump that was recalled due to cybersecurity risks discovered after their initial deployment. The FDA now requires device manufacturers to consider cybersecurity when designing devices – These are addressed in the pre-market and post-market guidance provided by FDA, to ensure a structured risk approach to specific cybersecurity threats[ii].
Safe interoperability requires the continuum of care to be appropriately engineered to address needed systems, such as new apps to prevent unwanted interference. Medical devices, electronic medical records (EMRs) and the data produced by and warehoused in these systems have become critical to the practice and improvement of modern medicine and healthcare. Interoperability enables these devices and systems to communicate, enriching patient care using connected and autonomous applications, such as programmed error detection.
Avoid Compromise of the Device When Running its Stock Software
For implanted devices, several concerns need to be addressed. The first is a compromise of the device when running its stock software. This is a hijacking of the designed communication protocols by sending an exploit that subverts the standard communication channel. In this case, an unauthorized user could take control and perform malicious operations designed to harm or attempt to steal data. The next concern is the flashing of an unauthorized firmware or software build, by utilizing the manufacturer’s upgrade method or with physical access using the system microcontroller’s built-in bootloader (the software that facilitates upgrading of the firmware). Either attack surface yields the same result, allowing for complete control of the hardware by replacing the validated and verified firmware. In the following sections, we will review design mitigations available for these attack surfaces.
Cybersecurity is also Crucial for Devices that are not Directly Connected to a Patient
For medical devices that are not directly connected to the patient, there are also cybersecurity concerns. Pharmacy compounders and drug reconstitution systems, for example, can have a significant patient impact if compromised. In the compounder example, multiple prescriptions could be covertly altered to produce malicious and potentially life-threatening outcomes. In this model, there are multiple attack surfaces that need to be managed. Starting at the lowest level of the system, the firmware must be unaltered to protect the integrity of the hardware control and physical actions of the device. Typically, prescriptions are sent from the control PC and can be changed or intercepted in communication transit, making communication between the controlling PC and the device vulnerable to tampering. Going further upstream, the prescription database or management system sends the scripts to the control PC. If any prescriptions are altered on this system, all other security mitigations would not be effective in protecting patients from malicious modification.
Diagnostic Devices Can be Compromised Also
An in vitro diagnostic (IVD) device requires the same threat analysis process to provide comprehensive cybersecurity coverage. In an IVD, manipulated test data could cause incorrect diagnosis and lead to incorrect therapy. Similarly, to the compounder, a complex multi-level system is in place with most IVD devices. The laboratory information system (LIS) is often connected to the IVD device, which may contain multiple systems, such as a single-board computer (SBC) and embedded system to control the tightly timed operations.
Special Care is Necessary when Selecting the Encryption for Connected Healthcare Systems
Patient data is stored and transmitted increasingly on multiple medical devices to a centralized system. Gaining access to patient data will often be a more valuable target than causing any patient physical harm. A data breach not only would violate HIPAA and other regulations, it could be embarrassing for the patients and cause substantial financial loss to a device manufacturer or healthcare data company. Mitigations such as data encryption and data integrity checks are mandatory both when the data is offline (cold) and when in transit between systems. By itself, encryption is not sufficient to completely protect patient data. Special care and analysis is necessary when selecting the proper encryption for the system, and an understanding of current threats to these encryption schemes must be well understood before adopting a particular scheme.
Key Tech’s Cybersecurity Approach
How does Key Tech navigate the challenging landscape of cybersecurity when designing medical devices and systems? At the core, we view everything from a risk perspective and build in the required security mitigations from square one. Each device has different use models, physical security, network security, and threat vectors based on its intended use. Our approach complies with the IEC 62304 software development process and benefits from our experience in designing and de-risking medical devices for cybersecurity.
- Threat evaluation
For each device, we start with the use case. The Key Tech team limits attack surfaces and privileges on the device to only the core set needed at the requirement and architecture stage. Our de-risking process also identifies the best fit for the needs of the system, such as designing for wireless connectivity only when necessary. Typically, the well-known wireless protocols (Wi-Fi, Bluetooth) have microcontroller-provided software stacks that are treated as SOUP (Software of Unknown Provenance). As part of the IEC 62304 process, we carefully analyze these modules, to determine if they open an attack surface that must be evaluated before use in a medical device. See my article in On Drug Delivery for a deeper dive into the topic of wireless security. Bottom line, we start the design process with cybersecurity in mind and limit access to the minimal subset of actions.
- Secure coding techniques and protocols
The Key Tech team also employs multiple best practice secure coding methodologies and techniques to enhance the quality and safety of the code we write. Here are some of the actions we take:
- Training – Our Computer Engineering team is trained in cybersecurity and best secure coding practices.
- Static Analysis – All code written at Key Tech is put through a static analysis tool. Static analysis is run offline on code and detects common memory and code quality issues that can quickly lead to an attack vector.
- Unit Testing – Unit tests are generated by a Computer Engineer independent of the code creator. The independence provides the opportunity to evaluate and attempt to find security defects in addition to functional / requirement defects. We employ both white and black box testing based on the system risk assessment and software classification level.
- Code Review – As part of our process, all code is reviewed using our detailed internal work instruction protocols. Review activities are designed to find functional defects and defects that could also become security risks.
- Threat Modeling – During design, tools are used to model the system and clearly identify all attack surfaces and feed this information back into the architecture design. This allows for the right cybersecurity architecture decisions to be made early in design.
- Logging – Robust internal logging allows us to detect and log anomalies for offline system analysis. A “black box” can protect against intentional and unintentional destruction of data on a medical device.
- Proven Cybersecurity Design Process
As mentioned before, security is designed in from the onset of a project based on the unique device’s environment and risks. Mandatory mitigations are built into the Software Requirements document, Software Architecture Design, and all other planning documentation. This process allows us to focus on security as early as possible in the design process, instead of putting a “band-aid” on a nearly complete system. Late-stage security retrofits are possible, but typically more costly when done later in the design lifecycle. Our team can also stay engaged to also ensure on-market products stay robust in the face of evolving threats.
Dynamic Nature of Cyber Security
The global cybersecurity threat is ever-evolving, and this equally applies to medical devices. Medical devices can require more time than consumer products to update with the required design controls, as well as the required verification and validation efforts. It is therefore imperative for device manufacturers and developers to stay in the loop with any upcoming and ongoing threats. Thankfully, there are many resources available to assist in the tracking of these threats and sharing of new best practices.
On the Medical design and development side, the public / private partnership Healthcare and Public Health Sector Coordinating Council (HPH SCC) Joint Cyber Security Working Group (JCWG) maintains a “Joint Security Plan” (JSP) as well as many other resources such as a report on improving cybersecurity in the healthcare industry. The Joint Security Plan is publicly available, and participation is voluntary, but is targeted at manufacturers, healthcare IT vendors, and providers. Figure 1 of the JSP shows the quality system and high-level actions recommended in the various design and maintenance phases. These activities can be integrated into a new product design process or an existing product lifecycle. Any device manufacturer or design firm should be aware and familiar with the tools available from the HPH SCC.
There are also a few industry groups that facilitate collaboration in the Cybersecurity space. We can recommend the global non-profit Health Information Sharing and Analysis Center (H-ISAC). This is a group comprised of infrastructure owners and operators focused on sharing relevant and time-critical information on threats, incidents, and vulnerabilities. Also, best practices, tactics, and mitigation strategies are all part of the H-ISAC information sharing goals. This information is shared through periodic workshops/conferences, listservs, and online via their website. H-ISAC has partnered with the 3rd party Anomali threat platform that facilitates the sharing of these security insights with other members of the organization.
Beyond forums for device manufacturers, in recent years the DEF CON security conference has included a BioHacking Village focused on the vulnerabilities of medical devices and healthcare IT infrastructure. Security experts are given access to medical devices at this event in order to evaluate Cybersecurity. The DEF CON event is one of the largest hacker conventions, and this attention to BioHacking highlights the concern in the security community for medical devices and infrastructure.
Medical Devices are Key Tech’s Specialty
Cybersecurity is not just a buzzword that has grown in popularity recently. Medical devices are a special example of systems that, if compromised, can cause immeasurable and potentially widespread harm to patients, via physical harm or breaches of private data. Key Tech can help! Whether during development or providing an evaluation of on-market products, you can feel secure in Key Tech’s cybersecurity expertise. Please TalkToUs to see how we can support your cybersecurity imperatives.
[ii] https://www.fda.gov/medical-devices/digital-health/cybersecurity
He received his BS in Computer Engineering from the University of Maryland College Park and completed his MS in Computer Science at Hood College.
- Decrease Time-to-Market by Developing Medical Device Software “In the Spirit” of IEC-62304 - January 18, 2022
- Re-Architecting Software Following the Spirit of 62304 - July 14, 2021
- Cybersecurity – An Imperative in Medical Devices - November 12, 2019