The aim of this article is to give an overview about the main standards which regulate the cyber security of a Medical Device, they are:
- IEC 80001-1: Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software – Part 1: Application of risk management.
- IEC 81001-5-1 (not published): Health Software and health IT systems safety, effectiveness, and security – Part 5-1: Security – Activities in the product lifecycle.
- IEC/TR 60601-4-5: Medical electrical equipment – Part 4-5: Guidance and interpretation – Safety-related technical security specifications.
This post doesn’t mention the IEC 80001-1, as it deals with network security, and the main idea is to focus on standard which deals with software design and maintenance.
Impact on the design process of a connected medical device
IEC 81001-5-1 has inherited its structure from the IEC 62304, in this way the MedTech manufacturers are familiar with the process and the terminology. IEC 81001-5-1 complements IEC 62304 with the definition of task strictly related to cyber security of a connected Medical Device.
IEC/TR 60601-4-5 defines a list of security requirements that should be considered from Hardware and Software prospective of the connected medical device. Here is an example of security requirements:
We can summarize that those two standards together define the state-of-the-art development of a software of a connected medical device. The first defines the process (the “how to”). The second defines the security requirement (the “what”).
Content of IEC 81001-5-1
The table of contents IEC 81001-5-1 is copied from the one of IEC 62304, organized in processes. The 6 processes of IEC 62304 are illustrated in the diagram below.
Likewise, IEC 81001-5-1 defines security processes throughout the software lifecycle.
IEC 81001-5-1 doesn’t contain a definition of software safety class, contrary to IEC 62304, it means that all the requirements are applicable for any software whatsoever.
IEC 81001-5-1 requires documenting the secure design and the secure interfaces, the effort is comparable to what is required for IEC 62304 class B software.
Instead of safety class, IEC 81001-5-1 recommends using the concept of security level (SL) and secure capabilities (SC) as described by IEC/TR 60601-4-5.
Origin of vulnerabilities
A principle of secure software lifecycle is that security weaknesses can be introduced in every step of the development and leads to a vulnerability once the medical device is on the field, for example:
- specifications: wrong behavior specified,
- architecture: unsecured architecture,
- detailed design: unsecured interface detailed design,
- coding: language traps or wrong coding patterns,
- make / build: unsecured generated binary or bytecode,
- installation, configuration: wrong installation or configuration.
Therefore IEC 81001-5-1 covers all the steps of SDLC (Software Development Lifecycle) with the necessary activities related to cyber security, independently from the safety classification, like IEC 62304.
Content of IEC/TR 60601-4-5
The IEC/TR 60601-4-5 is based on the requirements of the IACS IEC 62443 family of standards, which is very engineering-intensive for its implementation.
The standard defines Security Levels (SL) and Security Capabilities (SC), which depend on the impact of a security breach on the system. The SLs are on a scale of 0 to 4 – Definition (IEC 62443-1-1):
- SL 0 – No prevention.
- SL 1 – Prevent the unauthorized disclosure of information via eavesdropping or casual exposure.
- SL 2 – Prevent the unauthorized disclosure of information to an entity actively searching for it using simple means with low resources, generic skills and low motivation.
- SL 3 – Prevent the unauthorized disclosure of information to an entity actively searching for it using sophisticated means with moderate resources, medical device specific skills and moderate motivation.
- SL 4 – Prevent the unauthorized disclosure of information to an entity actively searching for it using sophisticated means with extended resources, medical device specific skills and high motivation.
Security zones can be defined with different SL, it means that a medical device can have more than one security zone, with different SL.
Like IEC 62034, the security zones shall be segregated and of course, like IEC 62304, IEC/TR 60601-4-5 doesn’t define the kind of technical measures required for an effective segregation!
IEC/TR 60601-4-5 defines a total of 7 Foundational Requirements (FRs), borrowed from the IEC 62443-1-1:
- Identification and authentication control (IAC)
- Use Control (UC)
- System Integrity (SI)
- Data Confidentiality (DC)
- Restricted Data Flow (RDF)
- Timely Response to Events (TRE)
- Resource Availability (RA)
These 7 FRs are refined in 123 requirements. That is a very high number of requirements!
The 123 requirements are only applicable to software in SL4. It can be easily seen that SL3 and SL4 are the SL with a higher overhead. For software in SL1, “only” 50 requirements are applicable.
These security requirements found in IEC/TR 60601-4-5 can be seen a “pool” of secure product requirements to be refined in HRS and in a Secure SRS document or a security section in the SRS.
IEC/TR 60601-4-5 § A.6 allows to define different SL, according to the types of foundational requirements applicable. For example, for a device that does not handle confidential data, the SL for data confidentiality (DC) will be set to 0, whereas the SL for the system is 4.
This “SL vector” approach (the term used in the standard) is possible for any system. This is a way to make a lighter list of security requirements applicable to your device.
IEC 81001-5-1 and IEC/TR 60601-4-5 work in combination, the first defines the process to develop a secure software for a connected medical device, the latter defines a set of security requirement that should be fulfilled.
IEC 81001-5-1 and IEC/TR 60601-4-5 are clearly defining the way to conformity to cybersecurity requirements. In EU and USA, the plan is to be harmonized in 2024.
For more info please contact us
Author: Alessandro Vitiello
Head of Software & Hardware at D.med Software