Readers of the blog will agree that the last few guest medical device software experts; Muddy Waters, Led Zeppelin, Meatloaf and the Beatles have been, shall we say, not current. Some of the blog readers, namely my daughter and her roommates, have objected. So, this week's guest expert is at their suggestion.
In the song Stronger, it sounds like Kelly Clarkson is singing about a relationship but if you really listen closely she is telling us about the NIST Cybersecurity Framework.
You think you got the best of me
Think you've had the last laugh
Bet you think that everything good is gone
Think you left me broken downHere she is definitely talking about the five functions that comprise the core of the NIST Critical Infrastructure Framework; identify, protect, detect, respond and recover. Of course, we hope that our medical device systems are never attacked in use. We don't want to believe that there are people who would go after a medical device, however, we know that there are. There are people who have shut down whole hospital systems with ransomware.
As designers of medical device systems, what do we do when our systems are attacked? Do we let the attackers have the "last laugh" and that our systems will be "left broken down"? Of course not, this is why the NIST Framework has identified 5 functions. Before I summarize those 5 functions for medical devices it is worth noting that these 5 functions are called out by the FDA in both the (draft) premarket and the postmarket cybersecurity guidances for medical device software.
Identify
For a medical device system the identify portion is about the organization and the modeling. This is "developing an organizational understanding to managing cybersecurity risk". This is the work instructions and training for the team to make sure all understand the cybersecurity threats. Within the system itself this comprises the premarket (and postmarket) threat modeling, attack trees or kill chains so that any potential issues may be discovered early in the design. Questions to ask: On the network interfaces, how can attacker exploit the system? In the data stores, how could someone be able to disclose or tamper with patient information? Can a bad guy pretend (spoof) to be your mobile device and extract key information from your embedded device? In the postmarket context, organizationally, there is a need to examine complaint data for the identification of any cybersecurity signals. The premarket threat models can be used to assist with this postmarket analysis.
Protect
For a medical device system, the protect function is the cybersecurity controls. For every threat, well thought-out controls need to be implemented. Address everything from the threat modeling as far as possible. A cybersecurity risk analysis is used to ensure that the severity of the threat drives the most robust controls. The pre-mitigation ability to exploit should be significantly reduced for the threats with the greatest severity. Controls should be based on industry standard approaches for the most secure network protocols, authentication, cryptographic signatures and encryption techniques. It can be tempting as an individualistic, do-it-myselfer to come up with some clever, home-grown scheme but this is likely to be easily broken by an attacker. Let the weight of the industry knowledge be your friend.
Detect
The detect function involves determining that an attack has occurred or is occurring. For a web site or a larger system with greater resources, there are many tools and technologies that can be employed to look for the patterns of an attack such as firewall logging. On a smaller, embedded system this is more difficult. However, for each of the threats and controls in your threat model, one should be able to record that the undesirable thing is happening. For example, for a system login, perhaps you implemented a control to add a delay after 3 failed logins to slow down a dictionary attack. The system should definitely log that there have been 3 failed logins and the delay was employed. Ensure that the log is analyzed and reviewed properly somewhere as well. (No trees falling in a forest without a sound.) A single occurrence of this log entry could just be a user with a bad day of 'fat fingers' but many occurrences could indeed be an attack. Another example is the use of digital signatures for software updates. If there is a signature failure, then this should be at the very least logged with the logs being analyzed and reviewed.
Respond
Taking it one step further, the system should do something, i.e. respond, in the case of a detected attack. How can it do this? In the example of the bad signature the user should be warned that something potentially bad was prevented. If this was a bad image downloaded the user could be asked to assist in reporting the issue that could be indicative of a supply chain attack. Or, the system could phone home and report the issue and provide some actionable information. For the bad password example, perhaps 20 bad passwords in a short timeframe would trigger a phone home type response. In the FDA premarket guidance, designing in the ability to do a software update is included in the respond category. The architecture and V&V techniques should be chosen to facilitate upgrades quickly.
Recover
Recovery is getting the system back to a safe state. A software update makes sense as a recovery for the case of a zero day attack to an off the shelf component. One way to recover is to upgrade the component. The system should be designed to be resilient even if compromised. Perhaps the critical apps are protected by signatures and backup copies so that if someone tried to swap with malignant versions, this would be detected and the backup copy used. Also, the system should be resilient and continue to deliver critical therapy or record diagnostics in the case of a denial of service attack on the network.
Stronger
As we are designing our systems we cannot lose sight of the goal of delivering for our customers on good days and on bad days. We need to make sure our systems are ‘Stronger’ as Kelly sings even when the ‘good is gone’. As Kelly knows the NIST Framework can help with that.
Comments