Introduction
The scope of this post is to give an overview about the IEC 81001-5 which is a new compulsory regulation, that the MedTech manufacturer shall take into account for their new health software and for legacy device that should be recertificated under the new MDR.
This post is part of a series which will be focused on chapter 5, 6 and 7 of IEC 81001-5-1.
The IEC 81001-5-1 is a standard process which contains some compulsory tasks that the manufacturer shall perform during the lifecycle of a health software to increase its security. The standard should be used by the manufacturer, as a base to define development and post market processes. In this way a certain grade of security can be guaranteed in the final health software.
The IEC 81001-5-1 describes in detail all the documents and their main contents that should be generated during the different phases of the health software lifecycle. It is very similar to the IEC 62304, which describes the lifecycle process of a software for a medical device, but fully oriented to the security of that.
Photo 1: Describing process ref. ISO Figure 2.
In this specific post the focus is on chapter 5 which describes the main steps that should be taken during the development phase.
Software Development Plan
The manufacturer shall establish a series of activities that should be performed during the lifecycle of the health software in order to guarantee its security. The software development plan should describe all the activities performed during the development (Ex: Requirements, Software Architecture, V&V, Patching, Software Update, etc.).
As well a list of tools and technology used to support those activities shall be declared in this document.
Requirements
The manufacturer is responsible for defining the security requirements and capabilities related to installation, operation, maintenance, and decommissioning of the health software. These are fundamentals to create a good health software and it could be defined as the basis of development. Usually, they are performed at the very beginning, but considering an agile approach, they should be constantly monitored and updated based on the new needs of the health software that can appear during its development or lifetime.
The requirements should describe a unique characteristic of the health software in a clear way without any ambiguity, and it should state in terms that allows an establishment of the test criteria.
After the creation of the requirements, a deepest review should be performed by a team of software architects to validate them and define the feasibility of such development.
Secure Architecture Design
The aim of this activity is to define all the security measures that the software should contain to mitigate any possible vulnerability. One of the key concepts introduced by the secure architecture design is the defense in depth. The idea behind is to define different levels of security which can be applied to different software items. In this way the core functionality of the system is protected by different layers of security which means a complicated challenge for a possible attacker.
The manufacturer shall also fulfil the requirement of security by design documenting all the security best practice used to implement the different mitigations.
Software Design
The IEC 81001-5-1 group in this chapter all the activities that the manufacturer shall perform to correctly implement all the security mitigation defined by the software architecture, for example:
- Software technology applied to all levels (algorithms, programming methods, etc.)
- Program language used third-party components
An important aspect that the IEC 81001-5-1 highlights in a special subchapter (5.4.3), is the software interface. The IEC 81001-5-1 requires that the manufacturer shall identify the following as part of the design:
- The interface is accessible internal, external or both items
- Security implication, consideration, and context
- Potential use and the Asset that can be accessed through the interface
During the design phase, the manufacturer shall conduct a series of design reviews to ensure that all the security requirements have been implemented and all the threats have been correctly mitigated.
Software Implementation and Verification.
The manufacturer shall establish a series of code standards to implement the code and ensure its usage by doing a periodical SCA (Static Code Analysis).
The principal activities that should be performed during the verification of the software are:
Threat Mitigation Testing
The manufacturer shall create specific test protocols to ensure that each mitigation works as designed and it doesn’t introduce a new vulnerability.
Vulnerability Testing
The manufacturer shall create specific test protocols to ensure that known vulnerabilities have been mitigated correctly focusing on the following points:
- Abuse of malformed/unexpected input
- Attack surface
- Scanning hardware and software items
- Dynamic security testing
Penetration Testing
The manufacturer shall establish a series of test activities to identify weaknesses discovering and exploiting security vulnerabilities.
Software Release
The IEC 81001-5-1 group listed in this chapter all the activities that a manufacturer shall establish to release a health software; see the main ones below:
Resolution of findings
The manufacturer shall ensure that all findings from the testing system have been handled by the problem resolution process.
Release documentation
The manufacturer shall define all the additional documents related to the security of the health software, such as:
- Secure operation guideline
- Information about residual risks
- Account management guidelines
File Integrity
The manufacturer shall establish a procedure to verify the integrity of all artifacts used with the health software.
Private Keys
The manufacturer shall define a procedure to protect private keys from unauthorized access or modification.
Secure decommissioning guidelines
The manufacturer shall create documents that describe a procedure to decommissioning the health software and its security features.