The interconnectivity of diagnostic devices, information systems and mobile phone or tablet applications is growing exponentially. This brings fantastic opportunities for better medical care, but also serious risks. The greater the interconnectivity, the greater the risk of a security breach, which could have life-threatening consequences.
A single compromise of your network—maybe from a staff member opening an inconspicuous email, an innocent-looking file from an infected USB drive, or a malicious attack—can jeopardize the safety and effectiveness of all medical devices on that network. Indeed, in 2011 diabetic researcher Jay Radcliffe demonstrated a technique at the Def Con hacking conference in Las Vegas for attacking the same insulin pump that delivered insulin to his body. He hacked into the pump that provides him with measured doses of insulin by remotely accessing the wireless system the computerized pump used to monitor its surroundings for commands.
Designers and manufacturers have a significant role to play in ensuring that a diagnostic device is secure. For instance, the American Food and Drug Administration requires manufacturers to “take steps to assure that appropriate safeguards are in place to reduce the risk of failure due to cybersecurity threats.” They must remain “vigilant about identifying risks and hazards associated with their medical devices, including risks related to cybersecurity.”
So, what should you, as a manufacturer, do about cybersecurity when developing a new diagnostic device? The first step is to perform a detailed threat assessment. Then use this as the basis of a security strategy for the device. But your role does not end there. You must continue to monitor, assess and update your strategy for the lifetime of each device.
How can you give patients and doctors full confidence in the cybersecurity of your diagnostic device? What can you do to minimize the chance of a security breach, to ensure the safety and effectiveness of your device? And if there is a breach, how can you make sure no serious harm is done to users?
Your device is part of an ecosystem
No diagnostic or medical device operates alone. It is just one element of a complex technological ecosystem and, as a manufacturer you need to understand that ecosystem. The security of a healthcare organization’s network is beyond your control; instead you must focus your efforts on making your device a responsible part of the ecosystem.
Many healthcare organizations comply with standards such as CLSI AUTO11-A2, which prescribes IT security for in vitro diagnostic (IVD) instruments and software systems. Standards such as these set out the responsibilities of all parties – from the physical security of laboratories, to the infrastructure managed by the healthcare organization’s IT department, to the requirements for a single medical device.
There are many options for providing security – the market offers hardware and software solutions by the thousands. But without thoroughly analyzing the threats and risks applicable to your specific diagnostic device, you cannot be confident that a particular security tool will work.
Healthcare organizations rely on connectivity between their diagnostic devices, information systems and staff terminals, to provide an effective and efficient system that helps manage their workloads. As the number of devices on the network increases, so does the risk. And if the organization’s internal network is connected to the internet, the risks and complexities of network security can seem almost insurmountable.
What can threaten your diagnostic device?
The need for good security depends on what is at stake. For a diagnostic device, the stakes are as high as they can possibly be – patients’ lives. Depending on the device in question, a patient’s life might depend on:
The accuracy of a medical diagnosis
Access to private patient information (such as compliance with the Health Insurance Portability and Accountability Act, or HIPPA)
The reliability and availability of the device (for time-critical use)
The risk of a device posing a threat to other devices on the network
When the stakes are this high, the burden of providing a secure system can seem overwhelming. But to develop a security strategy that will protect people’s lives, you must first understand the nature and magnitude of the threats.
When analyzing threats specific to your diagnostic device, there are three areas to focus on:
Vulnerability–What exploitable weaknesses exist in your system?
Access–How could a malicious user or program get into your system?
Capability–In the event of a security breach, what type and amount of damage could a malicious user or program cause?
If only one or two of these risks apply, the problem is not critical. For example, a malicious UNIX program, sitting on a USB stick that is plugged into the instrument (access), can exploit a security flaw in the kernel (vulnerability). But if this is a Windows-embedded system it can cause no harm (it has no capability, because it is impossible to directly execute a UNIX binary on a Windows-embedded system). So, this scenario is not a threat and you do not need to take action.
But when a particular risk scenario involves all three areas, it must be documented and given the highest priority for mitigation. Systems and software design will significantly influence the nature of threats that need to be prioritized for mitigation. Your strategy should focus on eliminating the occurrence – or at least reducing the frequency – of breaches, and then on minimizing the severity of harm caused by any breach that does occur.
If a threat cannot be neutralized or mitigated, detection is the fallback strategy. A diagnostic device that can detect when its security has been breached can alert users and the manufacturer, who can immediately take action to avoid harm.
Discussion: A High-Volume, Point of Care Diagnostic Device
This benchtop, Point of Care diagnostic device is used in various environments, including general practitioners’ offices. For this reason, the manufacturer cannot assume that users in all these environments will comply with regulations such as CLSI AUTO11-A2.
The instrument software comprises:
Customized Linux kernel for ARM processor
Drivers for Wi-Fi, Ethernet and USB connectivity
Various Linux tools
Instrument software (built to Software Safety Class C standards.)
All these software items contain vulnerabilities that allow execution of arbitrary program code.
The instrument is not serviced in the field. Defective instruments are returned to the supplier and replaced with a new instrument.
The instrument has the following access points relevant to cybersecurity:
Any attacker who manages to breach the system security can access the following:
The software installed as part of the Linux root file system
All data stored on the disk or in RAM, including:
Patient details and diagnosis history
Proprietary diagnosis algorithms (the manufacturer’s intellectual property)
Encryption keys stored on disk
Networks available via Ethernet and Wi-Fi (including the manufacturer’s cloud-based information system)
Any device connected via USB
I recommend that the manufacturer take the following steps:
Do not install anti-virus software. Dramatic as this may sound, the likelihood of a malicious executable targeting the CPU architecture and operating system of this instrument is extremely low. But if clients do request anti-virus software (perhaps for marketing reasons), engage security experts to develop it, as commercial products for this architecture are not readily available.
Install a software firewall for the TCP/IP stacks provided by the Wi-Fi and Ethernet access points. Only the TCP and UDP ports necessary for communication with the manufacturer’s cloud-based information system will be open.
Only connect the instrument to Wi-Fi networks that are securely encrypted. We strongly recommend that end-users use the Ethernet connection during installation wizard.
Remove all non-essential Linux tools and programs (for example, bash shell and telnet) from the deployed root file system.
Run the application software in user mode limiting access to system functions.
Give each instrument a unique root user password, which is automatically generated during manufacturing and recorded only on the manufacturer’s internal network.
The only encryption keys to be stored on the instrument are public keys that are part of a public–private pair (such as RSA). In the unlikely event of a security breach, the attacker gains no valuable information.
The actions listed here are general in nature and can simply be considered good security practice. In reality, you would implement significantly more mitigations, including activities specifically designed to protect the manufacturer’s intellectual property.
Vigilance brings security
The analysis undertaken during the initial design and manufacture of a diagnostic device is only the first step in the process of maintaining security. Once you have decided on which mitigations that your system will use, you need to analyze new threats to see whether they can be fully neutralized by these mitigations.
Many different factors can highlight the need for a threat analysis. These might be external (such as new vulnerabilities and capabilities, operating system patches) or internal factors (such as a device software update or patch). As a manufacturer of diagnostic devices, you are responsible for ensuring that threat analysis is performed continually and thoroughly.
No IT system is ever 100% secure. But producers of diagnostic devices are responsible for the way their products operate within a larger ecosystem.
By working collaboratively with an instrument development partner who is experienced in designing and implementing cybersecurity measures for a range of medical and other devices, you can have increased confidence that your device will be safe and reliable in protecting patients’ lives.