Medical device cybersecurity: exploring the threats

Medical device cybersecurity threats to be aware of

In any medical device development, risk management should form a central part of your processes. As medical device manufacturers, distributors, and designers, we need to identify the risks associated with your device, in accordance with ISO 14971 – a regulation about the application of risk management in medical device development. Once we understand the risks, we then need to consider mitigations that we can put in place to reduce the severity or probability of them. Throughout the device lifecycle, from the time of production to when its in the hands of users, manufacturers need to closely monitor their devices to ensure new threats are mitigated too.

Whilst cybersecurity risks aren’t necessarily medical device security risks per se, risks of this kind must still be identified and mitigated in the same way. The National Institute of Standards and Technology (NIST) has established a framework regarding cybersecurity, which is quite similar to ISO 14971. The framework isn’t specific to medical devices and instead focuses on cybersecurity risks in critical infrastructure. However, we can still draw on this for medical device risk assessment. The framework outlines five activities:

● Identifying threats, assets and impacts
● Implement safeguards to protect assets against the identified threats
● Create ways to detect, respond to, and manage cybersecurity events
● Detect said events as they happen
● Recover from said events and minimise their impact

Whilst a lot of cybersecurity risks will be specific to the device, depending on the way that they operate and their design, there are still some general threats to be aware of across all medical devices:

Harm to patients

Direct patient harm is a worst-case scenario, but it should still be considered when managing the risks associated with your medical device. In some instances, attackers may wish to harm patients, caregivers, or other users via your device. As an example, if a wireless interface is used to control your device and trigger therapeutic behaviour, the attacker could use this interface to control the device. Protection is therefore essential for a wireless interface, otherwise it will be left open to attack.

Leapfrog attacks

In a connected system, all points in the network are connected in order to distribute information between nodes. For attackers however, such a connected system can provide an entry route to the wider system of devices. As such, a system is only as secure as the least secure device within it. Developers must therefore ensure all devices within each system are as secure as possible.

Denial of service attacks (DOS)

A “denial of service” (DOS) type of attack is intended to temporarily block your services. This usually happens due to a large number of access requests being received in a short period of time, resulting in server downtime. Attackers may also use ransomware to block your services, as seen during the WannaCry attacks on health services. These attacks showed just how damaging the effects of cyberattacks can be, resulting in delays to surgeries and treatments for patients.

Manipulation or loss of data

Attackers often seek out sensitive data to extort individuals, steal their identities or sell to suspicious organisations. Most of the time, IT systems have protection in place for this data because of required legislation such as GDPR. However, in the context of medical data, attackers might seek to manipulate and modify this in a way that affects a patient’s treatment. To use a current example, consider what might happen if COVID-19 test results were modified by an attacker – infectious patients with a false negative result could continue to mix as usual, spreading the infection further.

Loss of intellectual property

If your software can be understood and interpreted directly from the device, attackers could take advantage of this to replicate your designs, exploiting the development work that has taken place to create your product. As a result, they might recreate elements of your functionality to get to market quicker.

Whilst both the bottom-up and top-down approaches are effective in their own right, they work best when they are used together. For example, the bottom-up approach might help you to identify risks that the top-down assessment may miss and vice versa. Using both approaches will help you to identify an exhaustive list of vulnerabilities, helping you to then put mitigations in place for them.

Data in transit

Data transferred between devices is known as data in transit. While moving between devices, data can become vulnerable to attackers trying to intercept and steal information. Just like data at rest, you can mitigate this threat by using encryption, specifically ‘end-to-end encryption’. In this type of system, only the parties that need to use the data (the sender and recipient) know the encryption keys. As such, whilst the data is handled by the server, it cannot be read by anyone or anything other than those that understand the encryption keys.

When using end-to-end encryption however, it’s important to be aware that the sender and recipient sharing the same encryption key could also act as a single point of failure for multiple devices. With all of this in mind, it could be safer to use asymmetric key encryption. This method involves encryption keys that are unique to each individual communication session between two devices and, better still, these devices aren’t required to know the encryption key in advance.

Data authenticity

Another way for attackers to cause harm is to disrupt data whilst it’s in transit and then modify it. Random data corruption from electromagnetic interference is often one of the tactics used, or attackers may carry out ‘man in the middle’ attacks. Either way, corrupting data can cause significant harm. For instance, it can lead to incorrect patient records, or in the context of your medical device, it can also lead to incorrect instructions to remote modules. Corrupt data can be identified and mitigated against by attaching robust signatures – like SHA256 – to the data. Devices receiving the data can then confirm that it’s valid by calculating the signature of the data that they’ve received. If the signature doesn’t match the signature provided, the data cannot be authenticated.

The second part of authentication involves identifying whether the source of the data is valid, as well as the data itself. Website and server certificates can be crucial here, as they can be used to confirm that communication is taking place with the correct host. Authentication data can then be exchanged between devices once encrypted communication sessions have been set up and it’s clear that the recipient is valid.

One of the easiest ways for attackers to access data stored on a device is to simply gain physical access to the device. While it’s common to use passwords to secure computer systems and similar devices, these can often be used as a point of entry if attackers are able to find them or figure them out. As with any IT security measures, using the same passwords across entire systems isn’t wise – it increases the chances of attackers accessing all devices within an ecosystem. When devices are configured, they will require a default password, but this should always be entirely unique. One way this risk can be mitigated is by implementing adequate password policies – each user and each device should have a unique password and, wherever necessary, access to data must be restricted. Password updates post-launch are also vital.