Guidance on protecting medical devices

This guidance has been written to cover a very broad remit. Individual trusts will have to interpret this and apply security measures in a way that makes sense for them as the same mitigations will not be appropriate across all the health trusts in the UK.

Download a PDF copy of this guidance on protecting medical devices.

Using medical devices on clinical networks compounds three related issues:

• as a medical device, security updates, patches and potentially virus signatures must be properly assessed by the supplier and confirmed as safe before they can be implemented on the medical device. This can take three months from the time that a security update is released
• when security updates are released, they are retro-analysed by attackers, increasing the likelihood that exploitable vulnerabilities will become known
• the latest security mitigations not being present, increases the impact of vulnerabilities, making exploitation more likely to succeed, and making detection of any exploitation more difficult

In combination, these issues mean that high-impact security incidents become more likely to occur. Security incidents affecting connected medical devices can cause significant disruption to the delivery of healthcare services.

The following steps should apply to any network connected medical device regardless of operating system.

Identifying all the devices in your estate that are in scope. A complete picture should be made that details the types of devices that need protecting, along with information such as what operating system they run and the ports/service they need to utilise.

A complete network topology should be draw up to show how the devices that are in scope communicate with associated devices and services and also how access can be enabled for remote updates to be delivered if this is appropriate for the device in question.

Having this information in an accessible format will make the following steps easier and ensure that security gaps are not left in the trust’s networks.

Examples of medical devices may include MRI scanners, handheld vital signs monitoring and syringe drivers; you may wish to refer to the European Council Directive 93/42/EEC, which lays out the definition of a medical device.

Weaknesses that are found in medical products will remain unpatched during the supplier’s period of assessment and will be exploitable by relatively low skilled attackers. There are two types of mitigations that can be used to reduce the risk:

• reduce the likelihood of compromise by preventing the devices from accessing untrusted content (effectively making it hard for malicious content to reach the device and exploit it)
• reduce the impact of compromise by preventing access to sensitive data or services from vulnerable devices (so even if the devices are compromised, the damage will be minimised)

An effective mitigation plan will require a combination of these two approaches.

Exploits based on malicious data can only be successful if the data can actually reach a vulnerable product. If untrusted data is prevented from reaching a system, then the likelihood of malicious content reaching the vulnerable system is lowered, and so the risk from malicious content is reduced.

Routes by which malicious data could reach unpatched software include email, web browsing, file shares, network ports, and removable media. We recommend that these routes be reduced for all medical devices. Devices should not be used for end-user activities (such as email or web browsing), and data flows to medical servers should be carefully considered and constrained wherever possible.

Data and files sourced from the Internet should be treated as untrusted even if originating from a known third party. Data retrieved from enterprise storage services should also be treated as untrusted if its source was originally external.

3.1 Prevent access to untrusted services

Implement technical controls to prevent access to external untrusted services from medical devices and associated workstations. This should include preventing access to external email and preventing the device from browsing the internet unless absolutely necessary. These controls will not be effective if they are not technically enforced.

By preventing access via email and the web browser to untrusted content and services, two of the most likely attack vectors for client systems are removed.

3.2 Prevent or reduce access to removable media

Access to removable media should be prevented as it can be used to transport untrusted content. It is also important to consider devices such as smartphones and tablets, which can be used to transfer data, and, if compromised, can also launch attacks against devices they are connected to. Access to removable media and any connected devices can be controlled through numerous mechanisms.

When considering mobile devices, it may be useful to see what the NCSC considered whilst choosing a product to manage all of theirs.

3.3 Constrain network access

When a medical device is connected to untrusted networks via its network interfaces, for example, to allow access by remote workers, it is directly exposed to external network-borne attacks. The only technical mitigation available would be to disable/remove all network access from the device, effectively making them stand-alone devices. This is clearly only possible if the applications on this device do not require access to network services.

Hence, the device could be connected to a physically or logically separate network which only has similar medical applications and their required services on it, which has no direct external connectivity through which malware could get in.

3.4 Remove unnecessary services

Devices should be checked to ensure that they only offer the services required. Those services which are not required to support the business function of the server should be removed or disabled permanently.

3.5 Constrain Remote Access

To reduce the attack surface, medical devices should not be exposed to the wider network. Intrusion prevention systems and application firewalls can be used to help defend against attacks, as can the use of reverse proxy servers.

3.6. User management

User accounts need to be managed appropriately. This means they need to be available for every user with a need to use the system they concern, and they need to allow the user to do their job. Past this, they need to restrict the user’s permissions so that they can’t do anything they shouldn’t.

Accounts need to be managed throughout their lifecycle too. For example, it’s important to delete them as staff leave the business or change jobs.

An unpatched end user device that is directly exposed to malicious content is likely to result in successful compromise. The impact of compromise can be reduced by controlling access to enterprise services hosting sensitive data and improving the ability to detect attacks.

4.1 Remove access to services

The level of access granted to medical devices to connect with an enterprise environment should be restricted to only those functions which are absolutely critical. Implementation of this mitigation may include network separation and zoning controls.

4.2 Network zoning

By zoning the network, it is possible to reduce the ability for malware to spread laterally through an enterprise. The traffic flows between zones should be well defined, providing the ability to block and prevent unauthorised communications, such as those made by malware trying to reach its command and control systems.

It must be assumed that successful attacks against temporarily unpatched medical systems are likely to be able to subvert the controls provided by any software firewall in that operating system.

Appropriate internet gateway mitigations, such as using an outbound proxy, will help ensure that internet-bound traffic flows are authorised.

Medical devices should be placed into network zones that minimise the traffic which can reach them. Access to those zones should only be granted to clients with a need to communicate with devices in those zones. Consider using an air gap if feasible.

4.3 Protective monitoring capability improvement

It is especially important to ensure an effective and proactive protective monitoring capability is in place. Many organisations often have the ability to record security events but do not proactively alert or act based upon those events.

The first step to having a good protective monitoring solution in place is to ensure that the logs you are collecting are useful. Advice on how to decide what information to log can be found on the NCSC website.

Once you’re logging data it might be appropriate to set up a Security Operations Centre. A high level overview of SOCs is available.

4.4 Anti-malware and intrusion detection products

Products such as antivirus, host-based and network-based intrusion detection systems can be used and will continue to offer some benefits in detecting malicious code. Their effectiveness may be reduced as the products may not be updated during the supplier’s assessment period.

Intrusion detection products located on the medical devices segregated network may provide an early warning of malware as these devices can be maintained and updated immediately when patches are released. Care should be taken to ensure that implementing a path for updates to these intrusion detection devices does not bypass the network segregation controls needed for the medical devices on that same network.

4.5 Incident response

Timely response to security critical events is important given the vulnerability of medical devices. Actions to contain and eradicate the compromise should be timely to try and reduce any compromise spreading.

Ensure engagement with clinical colleagues to understand the potential impact of any incident and plan for remediation.

If third party organisations use their own devices within or to connect in to your environment (for example, suppliers that manage services within your enterprise environment), it is important to understand whether they are running vulnerable software which could pose a risk to your systems - and to act to address such risks.

When procuring contracts, you should consider support and security. For example, in the event of a security incident how quickly should you have support engineers on site to apply mitigations? Similarly, once a patch has been released and tested, how quickly should it be applied to any medical device it concerns? Getting these statements into contracts will make it easier to stay on top of your own security requirements.

The above steps should be a continual piece of work. The trust’s estate will change over time: new devices will be added, and others removed, contracts will expire, and new technology will come on the market. All of these and more, mean that the risks associated with your medical devices are forever changing and you need to change to ensure you are mitigating them as best as you can.