Cybersecurity in medical devices - Part 2 Stakeholders
After a long interruption, we continue this series on cybersecurity in medical devices with a review of stakeholders involved or concerned by cybersecurity requirements, and the consequences on architectural choices.
The main characteristic of connected medical devices is to be ... connected. They can't fulfill their intended use alone and need a technical environment to work. This technical environment is never provided by the manufacturer alone. Thus several stakeholders are involved in the fulfillment of the intended use, directly or indirectly.
Borrowing the vocabulary of ISO 9001:2015, stakeholders are interested parties, and we have to understand the needs and expectations of interested parties (quote of 4.2 of ISO 9001:2015).
The goal of cybercriminals is to break the security measures to steal medical or financial data (welcome to the depths of the internet), or to injure people (mostly in movies).
- Needs: to have a better living whatsoever,
- Expectations: to find devices and IT infrastructures with vulnerabilities.
Medical device manufacturers
The goal of MD manufacturers is to design and place on the market secure devices, without vulnerabilities. To be more specific, without known vulnerabilities.
- Needs: to have the capabilities to design and maintain devices without vulnerabilities,
- Expectations: to place connected devices on the market, compliant to regulations, safe and secure.
IT infrastructure providers
We have two types of infrastructure providers: those who are aware of medical devices (MD) and health data (HD) regulations and standards, and the others who are not aware or deliberately won't set a foot in the constraints of e-health. The former usually build an offer of services compliant to MD and HD regulations, the latter don't or won't.
For example, some cloud storage providers currently sell services compliant to HIPAA regulation in the US, and will sell services compliant to GDPR in Europe. Others are for example telco companies or general cloud service providers.
- Needs: to have the capabilities to design and maintain IT platforms without vulnerabilities,
- Expectations: to sell services compliant to MD and HD regulations.
- Needs: to have the capabilities to design and maintain IT platforms without vulnerabilities,
- Expectations: to sell services while staying out of MD and HD regulations.
These organizations have the mission to enforce regulations and to watch the market. We find organizations of the MD and HD world, like the FDA or the Department of Health & Human Services in the US, and like national authorities of member states in Europe.
Specific to cybersecurity, we can also quote the Information Sharing and Analysis Organizations (ISAO) cited in the FDA guidance on postmarket management of cybersecurity.
- Needs: to have a clear understanding of what other stakeholders do,
- Expectations: to have devices and IT infrastructures compliant to regulations throughout their lifecycle.
We have here several type of end-users:
- Medical and paramedical personnel,
- Hospitals, healthcare centres.
They have similar but not identical needs and expectations.
- Needs: to have a better health or quality of life,
- Expectations: secured devices/services, which are not labyrinthine systems.
- Needs: to cure or take care of patients,
- Expectations: secured devices/services, which help them in their daily work.
- Needs: to provide connected devices to their personnel (even if they're reluctant :-)),
- Expectations: to buy secured devices/services.
End-users (patients and caregivers) have in common to be passive regarding cybersecurity. It is not their problem. When it becomes their problem, it is usually too late, data have already leaked.
While it is preferable to have security by design, training of end-users is part of the measures of protection. It is difficult to make end-users actors of the cybersecurity but it is a mandatory and endless task.
Architectural choices and constraints
Coming back to technical considerations, we can see that the more the architecture of a connected object is complex, the more we have stakeholders involved in cybersecurity.
Let's see an example, with a connected object used at home, which transfers data for monitoring/processing by medical personnel.
In this case, the MD manufacturer has to build a technical and organizational solution, which is able to meet its expectations: a safe and secure connected medical device architecture.
This is its responsibility. The implementation can be delegated to subcontractors. But the responsibility of the manufacturer cannot be "subcontracted".
In the example of the schema above, the goal is to use patient data acquired by connected objects to help the caregivers in their work:
- Raw medical data of the connected medical devices are transferred to a gateway,
- The gateway preprocesses data, like filtering or compression and send them to the application server,
- Data are routed to the application server through the telco modem and the internet,
- The application server stores health data in a database and processes data (syntheses, comparison to encyclopedic data...),
- The medical/paramedical personnel can consult and assess data by the means of a care management interface.
We consider here that the connected weight scale, blood pressure monitor, software on the application server, and care management interface belong to the same manufacturer. The gateway, the database, and the application server infrastructure (a server in a datacenter) are subcontracted.
Let's see how the outsourced parts will have consequences on cybersecurity and on the constraints applied to the manufacturer.
Database service providers
In this example, the provider of the database storage service is a MD/HD compliant service provider. The provider is certified for storage of health data.
Its goal is to ensure that the manufacturer won't compromise its own infrastructure. Thus it will add contraints in its service contract (and probably also in the technical solution and/or available APIs) to ensure that the security of its service remains at a validated level of security.
As a consequence, the manufacturer won't have a lot of choices of technical implementation for its own solution, as the health data storage service providers are not so many on the market. It means also an effort of selection of the provider, to match the technical needs of the manufacturer with the capabilities of the platform of the provider.
Gateway service provider
Let's assume in this example that the gateway is part of a MD/HD compliant service. The gateway is rented by its manufacturer, and is capable of managing secured wireless health data transfer over bluetooth and wifi.
Likewise, the gateway service provider will add constraints to ensure that its device will remain safe and secure. As a consequence, the manufacturer will have to adapt the data protocols and interfaces on its connected objects and on the application server.
Telco service providers
Even if some telco firms begin to provide health data transportation and storage services, let's assume that we use a generic data transportation service. Their goal is to avoid any involvement in the management of health data. As a consequence, the manufacturer shall identify and implement technical measures ensuring a safe and secure data transfer over their infrastructure. While the telco providers already implement cybersecurity measures on their network, the manufacturer will probably have to ensure that the data transfer remains compliant with MD/HD regulations.
Application server hardware provider
Most application servers are now hosted in datacenters. Let's assume that the application server runs on a cloud server different from the database server. This cloud server is managed by a provider without compliance to MD/HD regulations.
On the HD regulation side, the manufacturer shall ensure that health data will never be stored in the application server. They can be cached in memory during data processing but data are stored on the compliant database.
On the cybersecurity side, the application server shall be secure, as well as its interfaces with the database server, the gateway and the care management interface. The server will be hosted in a secured datacenter, thus physical/hardware security measures will be implemented by the server hosting provider. But the manufacturer will have to implement software security measures.
The message behind this example is the necessity to perform a risk management oriented to cybersecurity hazards. The manufacturer shall do this risk assessment, and identify the mitigation actions, which depend on the subcontractors.
And the mitigation actions can heavily depend on qualified subcontractors.
This is a bit new in the domain of software, as software MD manufacturers don't have the habit to outsource their critical processes when software is in production.
This is also a bit new, as many cybersecurity risks and mitigation actions are "located" in the deployment, production and decommissioning phases of the software lifecycle.
We can make a comparison with manufacturers of physical medical devices, which need to mitigate risks related to devices in contact with the patient, like biocompatibility. They depend a lot on specialized subcontractors for production processes like manufacturing, cleaning and sterilization.
Likewise, manufacturers of connected objects or software on the cloud will more and more depend on qualified subcontractors to mitigate risks related to cybersecurity.
The medical device business is changing with more complex and smarter devices, more stakeholders, new regulations brought by health data processing, and more work for the manufacturers to place compliant and secure devices on the market.
Next time, we will actually see risk management and cybersecurity.