Implementing Medical Device Cybersecurity: A Two-Stage Process
By James Baker, Cambridge Design Partnership
Connectivity is ubiquitous – it’s moved beyond an overhyped buzzword and become part of life. Offering ever-advancing levels of access, control, and convenience, widespread connectivity also increases the risk of unauthorised interference in our everyday lives.
In what many experts believe was a world first, manufacturer Johnson & Johnson recently issued a warning to patients on a cyber-vulnerability in one of its medical devices. The company announced that an insulin pump it supplies had a potential connectivity vulnerability. The wireless communication link the device used contained a potential exploit that could have been used by an unauthorised third party to alter the insulin dosage delivered to the patient.
It’s not hard to imagine the devastating impact to both consumers and the company if the reported vulnerability had been exploited. However, risks such as security will not prevent evolution of connected devices – demand for ever-increasing levels of convenience and access are driving the continued evolution and adoption of these products and services.
Cyber-security considerations shouldn’t be viewed as stumbling blocks for the connected device concept. Rather, it’s another of the many product requirements which, if considered and specified correctly at the design stage, can be implemented robustly. Above all, cybersecurity can be validated as part of a wider-reaching regulated device development process. It can’t be considered an isolated element to be bolted on, since it inherently helps to define the system architecture of what is developed.
Connected device cybersecurity is best approached in two stages:
- First, security is considered and specified in a top-down process, steering system architecture design at a fundamental level, and devolving down through the development process into testable units.
- Second, the design implementation is tested and verified against the specification requirements. To further prove system integrity, penetration testing can be used, conducted by testers separate from the original developer.
Security implementations don’t necessarily need to be complex, but they must be robust and considered. A simple system is more straightforward to validate than a complex one. At a test level, completeness of coverage when testing is a building block to demonstrating that the implementation is robust.
In connected products and devices, such as the insulin pump, one of the primary security challenges is proof of identity. If the pump receives an instruction from a connected device, was the instruction from the authorised control device, or from a third party, impersonating the control device? Traditionally a ‘key’ has been used as proof of identity, but if the key never changes, it can be duplicated. Transmitting this key over a radio link, especially an unencrypted one, creates a route for security failure.
But, there are many ways to add robust security. One approach for the insulin pump example could have been “challenge and response.” Using this method, a challenge consisting of randomised data is sent. The receiver then computes a response based on a cryptographic algorithm and a private key, which is built into both the sender and receiver. If the response to the random challenge data matches that computed by the sender, then the keys belonging to both parties are shown to be identical without ever openly communicating the key. The only data shared openly is a random challenge and a cryptographic response computed from the challenge. Since the challenge is random, it is unlikely to be repeated – simply cloning the response and repeating it to the next challenge will fail.
The security in such a system comes from keeping the keys private and using a cryptographic algorithm that is one-way (i.e., the private key cannot be calculated from the cryptogram). These algorithms are known as one-way hashes. Robust and certified implementations are commercially available that have been thoroughly and independently reviewed and tested. However, just selecting this approach is not the end of the story, since this only closes the highlighted security vulnerability. Other penetration techniques may still have been successful in this particular example.
In short:
Plan device security at a system-level — Define how the device will be used. Understand how information will move through the system. Each development must clearly understand the multiple points where system insecurity could occur, and the multiple approaches that could be used to exploit them. Design the system to prevent interruption, alteration, or exploitation of information transfer, applying security measures as appropriate.
Use proven building blocks — Using proven solutions, such as standard cryptographic algorithms, means that security implementation can be more straightforward to validate. It can concentrate on validating system level architecture and implementation for the specific product, in the knowledge that the building blocks utilised already are secure.
Test and validate before release — Check all aspects of the developed system against the architecture and requirements defined earlier in the process. For robustness, use independent teams to avoid over-familiarity. Test the device in its final usage scenarios. Consider using independent penetration testing for a final robustness check.
Cybersecurity in connected devices can be considered like any other development requirement – if considered early in the design and specification process, it becomes a fundamental part of architecture and can become a robust part of the product that is delivered. Its importance should be judged from the potential impact if it is incorrectly specified or implemented, and a commensurate amount of effort planned for its development in the product.
About The Author
If you’d like to know more about medical device development, contact James at hello@cambridge-design.co.uk.