Team Discussion
In my previous blog we discussed how connecting your medical device to digital services in the cloud can introduce risks such as exposure of data, unauthorised control and denial of service. This second blog will look at what we can do during the development process to mitigate these risks and their potential commercial, reputational and regulatory impacts.
De-risk by design
Effective cybersecurity is not something that can be retrospectively bolted onto a device – security risks need to be mitigated as design activities during development. This includes adopting best practice for passwords, effective encryption of data, authentication of communications and following latest security regulations and best practices.
1 Adopt best practice for passwords
Passwords are a crucial point of vulnerability in device cybersecurity, and so the importance of robust password handling is well known. Good password hygiene practice is crucial to minimising the risk of attack, so much so that many are now recognised within device manufacturing regulations (eg UL-2900-1), even included in legislation.
• Do not use default passwords; either set a unique password for each device at the time of manufacture, or prompt users to set their own upon first use of the device
• Specify ‘strong’, hard to guess passwords as a requirement
• Do not store passwords as clear text, instead use non reversible hash codes, such as SHA-256
• Limit the number of retries and resets available within certain time windows to mitigate against brute force attacks
• Be explicit about user roles and data privilege levels
2 Encrypt data
Exposure of sensitive or personal data to unauthorised viewers risks reputational, regulatory and financial damage.
Any data stored on a device is vulnerable to extraction by hackers. The first priority in protecting data is to disable any hardware debug ports or development ‘back doors’ at point of manufacture. All stored data should be encrypted when not in use and protected by checking data is trusted and valid (eg via signature checking). Importantly, this should include the embedded firmware code which controls the device and which a hacker may seek to tamper with or replace as part of a more sophisticated attack.
Any data that can leave or enter a device is particularly vulnerable to attack. Such data should be protected by end-to-end encryption, which guards against data interception (‘eavesdropping’) or tampering to manipulate device behaviour. When using industry standard protocols that already contain encryption support, Bluetooth, for example, be sure to turn end-to-end encryption on.
3 Authenticate communications
All communication channels – whether to a paired sensor, smart phone, or website – should be authenticated to ensure that each connecting device is what it claims to be. This can be done through handshaking and signing protocols, which require the sharing of a known secret between two communications agents. There are established technologies in this space – such as authentication algorithms and security chips – available for adoption to provide protection.
4 Implement cybersecurity standards
There is a growing set of standards and regulatory guidance notes available to support medical device cybersecurity development. It will become increasingly necessary to demonstrate specific cybersecurity conformances as part of the EU CE marking and FDA approval processes. Therefore, ensure your engineering teams are familiar with these standards, include them in your early requirements and risk assessments and document all resulting design mitigations.
Be aware that there are specific sections of the General Safety and Performance Requirements in the new EU Medical Devices and In Vitro Diagnostics Regulations which specifically call out cybersecurity as requirements for these devices.
Some of the medical device specific documents in this area are:
• AAMI TIR57 “Principles for Medical Device Security – Risk Management”
• FDA Guidance on Cybersecurity for Medical Devices
• The UL 2900 series of standards for software cybersecurity for network-connectable products should also be consulted
Test, test, test
Throughout the development lifecycle, testing of a device’s cybersecurity is necessary to ensure that the security measures being taken are functioning successfully. This requires ongoing unit, integration, and system level testing in preparation for formal verification at the end of development. Including security in your user and product requirements will ensure that they are overtly tested as part of your verification and validation strategy at the end of development.
Penetration testing – also known as “white-hat hacking” – by an independent security testing firm – can provide reassurance that your device is secure, as well as highlighting any potential areas for improvement. This testing can also reveal any defects in non-security areas of software which could influence the security of your device.
Post-market activities
Once your product is on the market, you will be keeping an eye on the device as part of your post-market surveillance plan. It is crucial that this plan involves looking out for potential security flaws that are identified and providing suitable software patches for your products. Although some security flaws will be due to malicious intent, be aware of potential obsolescence of any software parts from third parties. This is especially key if your product relies on an operating system which could stop being supported by the manufacturer.
No device can ever be guaranteed 100% secure. But, by considering cybersecurity during device design, testing and post market surveillance, risks can be lowered to an acceptable level and managed successfully.
To find out more about cybersecurity in medical device development, check out our full-length Insight article or get in touch!
Looking for industry insights? Click below to get our opinions and thoughts into the world of medical devices and healthcare.
