Back in May 2017 the EU, through its Medical Device Coordination Group (MDCG) published the Medical Device Regulation (MDR) (EU) 2017/745, which came into effect on 25th May 2017. The regulation was put together to ensure high standards of quality and safety for medical devices being produced in or supplied into the EU. Manufacturers of currently approved medical devices have until May 26th, 2021 to meet the requirements of the regulations. Even if a product is Medical Devices Directive (MDD) compliant, they still need to meet these new regulations.  The MDCG has been busy recently issuing a flurry of guidance documents related to the application of the EU MDR and IVDR (In Vitro Diagnostic Regulation) with a lot more expected to be released in 2021.

The regulation covers a wide set of requirements, including cyber security. With requirements for information security, data breach, data security/privacy, electronic programmable systems and software development. Safety, security and effectiveness are critical aspects in the design of security mechanisms for medical devices and in vitro diagnostic devices, which must be taken into account by manufacturers at an early stage of the development and manufacturing process and throughout their life cycle.

Section 3 of MDCG 2019-16 calls out a “Secure by Design” approach and a “Defense in depth” strategy to security lifecycle management, where the main concepts are summarized in the image below:  

(Source MDCG 2019-16)

 

The MDCG 2019-16 Guidance on Cybersecurity for medical devices is split into 8 key practices:

Practice 1 – Security management: Ensure security-related activities are adequately planned, documented and executed throughout the product’s lifecycle.

Practice 2 – Specification of security requirements: Identify the security capabilities that are required for appropriate protection of confidentiality, integrity and availability of data, function and services of the medical device along with the specified product security context. Security capabilities can include such items as authentication, authorisation, encryption, auditing and other security capabilities a product needs to include.

Practice 3 – Secure by design: Ensure that the product is secure by design including defence in depth.

Practice 4 – Secure implementation: Ensure that the product features are implemented securely. Requirements in this practice apply to all hardware and software components in the product with the exception of externally provided components.

Practice 5 – Security verification and validation testing: Document the security testing required to ensure that all the security requirements have been met for the product and that security of the product is maintained when the product is used as intended.

Practice 6 – Management of security-related issues: Used for handling security-related issues of a product.

Practice 7 – Security update management: Ensure that security updates and security patches associated with the product are tested for regressions and made available to product users in a timely manner.

Practice 8 – Security guidelines: Provide and maintain user documentation that describes how to integrate, configure, and maintain the defence in depth strategy of the product in accordance with its product security context.

 

Throughout the specification Manufacturers are required to demonstrate “state-of-the-art” within their decisions, while demonstrating appropriateness to proportionally address security risk. 

Let’s discuss practice 2 and 7 in a bit more detail. Practice 2 highlights the need to have the correct security controls in place on your IoMT Device to manage protection of confidentiality, integrity and availability of data. The example capabilities could include such items as authentication, authorisation & encryption.

These are indeed a good set of capabilities to adhere to, but they do all come with their own security management challenges especially when you consider the scale of such IoMT devices i.e. we are not typically talking about 10s of devices, more like 10s of thousands. The scale is the problem here and why Security Lifecycle Management (Practice 1!) and Automation has to be considered e.g. How to manage unique authentication keys/certificates or crypto keys to 1000s of devices. It’s not good security practice to install a generic key on all devices, this wouldn’t be classed as “state of the art” or consider as a “defence in depth” strategy!

Managing the process of certificate provisioning, renewal and revocation needs some serious thought… The same applies for device centric crypto keys, products which encrypt data need unique crypto keys, ones which can be rotated & are bound to the identity of the device. These capabilities have to be considered to prevent a rogue actor gaining access to the “keys for the kingdom” and ultimately lead to big data breach, potential safety issue to patients.

Let’s look at Practice 7 Security update management: Ensure that security updates and security patches associated with the product are tested for regressions and made available to product users in a timely manner. Secure updates are an integral part of any IoT deployment. If you can’t patch old device software then you could be in a position where your devices are useless, could be bricked, compromised the list goes on. Similar key management challenges apply here, as were discussed above.

Secure code updates/patching requires the appropriate keys in place on each IoMT device to check the package is from a verified source, hasn’t been tampered with and to prevent malicious updates being applied to the devices. An end to end solution has to be considered to mitigate threats in the update process. From back end to device end. This can be quite challenging for manufactures as there has been no real unified update process/model to date. Typically services and solutions are “hobbled” together in an ad hoc manor.  

 

If you would like to speak to Device Authority about these challenges and potential solutions for them then please contact us! We are here to help.

Robert Dobson