Security in medical devices, Part 2: The attack surface analysis
June 13, 2018
Story
Today we?ll examine the attack surface analysis ? what it is, why it?s used, and some best practices to use when developing secure applications.
This is the second in a three-part blog where we will look at improving security in medical devices. Here, we’ll examine the attack surface analysis – what it is, why it’s used, and some best practices to use when developing secure applications. Read part one here.
All medical device developers are familiar with safety, but for many, security is a new subject. To identify safety requirements, you need a structured technique such as a HAZOP. To identify security requirements, you need to ignore the limitations of that structured environment, and consider all contexts that are possible, using an attack surface analysis.
The attack surface analysis allows developers to understand the risk areas in a medical device, to make developers and security specialists aware of what parts of the medical device are open to attack, find ways of minimising this, and to notice when and how the attack surface changes and what this means from a risk perspective.
In a high integrity design life cycle, the attack surface analysis results in a set of security requirements. It is best performed in parallel with the HAZOP, which results in a set of safety requirements. Safety and security cannot be considered in isolation. Safety and security share many properties; however, these similarities can be dangerous, and if handled incorrectly can result in the wrong design decisions being made. In real terms this means that safety requirements should be subjected to a security review, and security requirements should be subjected to a safety review.
How can we reduce the attack surface? For every application, the attack surface analysis will bring up a variety of risks, but there are some measures which can almost always be taken:
- Disable all data streams into the system that don’t authenticate and encrypt data, to prevent bad actors circumventing the security measures already put in place and gaining easy access to the medical device via a back door.
- Remove from the board or completely disable the JTAG interface. JTAG is an extremely powerful interface to embedded devices, and provides access to almost all of the processor’s functionality.
- Ensure that all code segments can be traced back to a requirement, that each requirement has a test case associated with it, and that the test case tests each and every path through the code. Unused or undocumented code sections may offer a back door into the system that no one was even aware of. For SAFERTOS, we use modified condition/decision coverage (MC/DC), as a metric to show that all paths through the SAFERTOS code have been verified. 100 percent MC/DC coverage means that there is no unused or undocumented code within the device itself, and every path through the software has been tested.
- On smaller devices, running from FLASH rather than RAM could be a viable option.
In some ways, designing for safety is easier; the device works in a known context, and if the context moves outside of its defined operating parameters, then the system is placed in its safe state. Security is more difficult to ensure, as the attacker is attempting to manipulate the system context to gain access to it. The danger is that a context that was impossible to conceive during design is presented to the system, resulting in unwanted side effects which might leave the system open to attack. Herein lies the importance of a thorough attack surface analysis.
Stay tuned for the third part of our blog, which will cover wider security mechanisms that can be used to improve security in a medical device. For more on this topic, download WITTENSTEIN's free white paper, Increasing Security in Medical Devices.
