IEC 81001-5-1 “Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle.”, which is expected to be recognised by the EU in May 2024, is a significant new standard for any organisation involved in developing any medical equipment containing software.
While the UK may no longer be part of the EU, given the global nature of most electronics products, it is of relevance to the UK too.
Supplementing IEC 82304-1 and IEC 62304, both of which focus on the general requirements of the software life cycle and safety, IEC 81001-5 addresses cybersecurity in health software development and associated IT systems throughout the lifecycle. Its introduction is none too soon, given growing concerns around cybersecurity risks, especially as products and systems become more interconnected in an increasingly IoT-driven world.
The standard also encompasses a wide range of products, far beyond the standard medical devices such as insulin pumps and heart monitoring machines, and includes consumer electronics, including smart watches with healthcare features, nutrition, and yoga apps.
Secure software
The basis of IEC 81001-5-1 is development and maintenance of health software by a manufacturer, with the emphasis on the implementation of process standards to provide the best practices for a secure software lifecycle.
These regulations cover:
- Software in medical devices
- Software as part of hardware intended for health use
- Software-only products for health use
However, it also recognises the importance of communication with Healthcare Delivery Organisations (HDOs), such as clinics that provide healthcare services once the software has been developed and released. Future parts of the standard will address this.
The time to plan is now
Although May 2024 may seem far away, the reality is that preparing for a new standard takes time. Many of the process requirements within IEC 81001-5-1 will be familiar to organisations who already have robust safety strategies in place and have adopted other standards and guidance, such as the MDR, IEC 62443-4-1 and ISO 14971.
The structure of IEC 81001-5-1 is based on IEC 62304 but with an emphasis on cybersecurity rather than safety. However, IEC 62304 safety classes, which are assigned depending on the risks posed by the product, are not applicable. So, there is no difference in the processes to be followed based on risk. It is also intended to assist in fulfilling the processes required by IEC 62443-4-1, taking the specific needs of health software into account.
The scope of IEC 81001-5-1 is larger and includes more software (for example, operating systems) than IEC 62304 for safety because, for security, the focus includes foreseeable unauthorised access rather than just the intended use. So, there is still work to be done to comply with IEC 81001-5-1 such as implementing enhanced quality management and risk management systems, as these are core requirements of the standard.
Standard specifics
Drilling down into the details, IEC 81001-5-1 includes specifications for the processes which are part of a secure software development lifecycle. These processes include software development, software maintenance, security risk management, software configuration and problem resolution.
Although the general software development lifecycle may be familiar to organisations that have processes related to safety, these process specifications extend it to include cybersecurity considerations in every phase.
As part of software development planning, the manufacturer needs to establish a secure coding standard consistent with current best practices for implementing secure software systems. Examples of the specified best practices include simple design, removing backdoors and protecting debug information from unauthorised access.
To manage the security risk, the review process is required to identify which secure coding standards are enforced and if any parts of them are not followed. This includes agreeing any system wide deviations and considering other actions for mitigation. It is preferred that static analysis is performed to determine violations of the standard for the supported programming language. Although it is possible to achieve this manually, it is best practice to use an automated supporting tool.
It is important to identify possible known vulnerabilities using publicly available vulnerability databases, for example, the Common Weaknesses Enumeration (CWE). The risks exposed by these vulnerabilities need to be avoided, mitigated, and the impact on the intended purpose reduced. There also needs to be a risk analysis of the effects of vulnerabilities on safety as well as security.
This process is also necessary during the maintenance phase of the product development, as there is an activity required to inform regulatory authorities and users of vulnerabilities detected in the product software, together with the resolution (for example, a software patch).
Secure coding best practices
Appendix A of IEC 81001-5-1 provides details of the minimum activities required to implement secure coding best practices.
This includes avoidance of development and design patterns known to have security weaknesses and the avoidance of banned functions — it is noted that there are public lists of banned functions within common libraries and programming languages.
It is also considered a best practice to avoid code based on undefined and unspecified behaviour in programming languages used.
To ensure that known vulnerabilities are avoided and undefined and unspecified behaviour is detected, a published secure coding standard should be used. The standard suggests ISO/IEC TR 24773 – which is a certification standard for software, and also that well-respected coding standards – MISRA-C, SEI CERT C and SEI CERT C++ – are used in the test and verification of the software.
IEC 81001-5-1’s best practices recommend the use of automated tools and settings to enforce secure coding standards, for example, static analysis tools such as Helix QAC and Klocwork by Perforce. This allows repeatability of the testing after any code change and throughout the lifecycle. The standard also stipulates that ‘the manufacturer should evaluate each type of alert from static analysis whether it justifies a code change’.
Reducing developer workload
When enforcing coding standards, static analysis tools take away much of the heavy lifting for software developers by automatically checking code while it is being created and raising alerts for anything that does not fall within the rules or guidelines. So, developers can work at speed, without having to manually check code and have confidence in the code they are writing.
Also, since static analysis tools can often run checks even before code has been run or compiled, they contribute towards ‘shift left’ security, whereby monitoring remedial actions are carried out earlier in the development process. The earlier code issues are detected and addressed, the lower the cost, impact and time involved, and the larger and more complex systems are, the greater these savings become. IEC 81001-5-1 incorporates this principle by specifying that static analysis tools are used early to find security issues.
Best practice culture
Other best practices that teams might wish to consider include engendering a greater ‘security first’ mindset, top-down and across the board, with regular communications to increase awareness and training sessions. Also, given that the industry often has multiple contributors to a project, manufacturers need to evaluate the security processes of third parties they have contracted to develop software.
IEC 81001-5-1 is an important introduction and much needed, focusing for the first time on both cybersecurity and health in one standard. With 2023 now into its last quarter and the new year increasingly close, starting to plan for IEC 81001-5-1 is expected to be high on the priority list for any organisation developing software for the healthcare industry.
Author details: Jill Britton, Director of Compliance, Perforce
