Cybersecurity in Medical Devices Guidance

THIS IS MY PERSONAL OPINION AND NOT THE OPINION OF ANY ORGANISATION I AM EMPLOYED BY

In April of this year, the new, much anticipated, United States Food and Drug Administration (US FDA) draft ‘Cyber Security in Medical Devices’ guidance was put forth to the public and industry to comment on. This article aims to look at the bill in terms of the good, the bad and the ugly.

With that out of the way, the first thing that comes to mind when thinking about this guidance is the line that states that this guidance contains ’nonbinding’ recommendations, which is exactly what a guidance is: it is a recommendation of what you should do. The biggest complaint I have had over the years is that the FDA needs to have bigger teeth to enforce these recommendations. I digress here, but it’s true that this guidance certainly has some elements which are really good, however historically it has been a bit hit-and-miss.

Right at the start there are references made to Wannacry which, let’s face it, is old news. There are much wider-spread attacks on healthcare systems, more recently, from new attackers. The lack of clear definition as to what constitutes a medical device is still problematic and this is apparent from the onset. The conversation is had here about ransomware which largely affects devices with a Windows operating system. There needs to be a clear definition as to which devices and what category of devices this guidance is applicable to. There is a huge difference between custom firmware, designed to run on bare metal and those devices that traditionally run Windows Embedded or a version of Linux. They say the devil is in the details. This has been a gripe that I have had with the way that the message is delivered and that cyber security is (attempted to be) universally applied. There are many variables when it comes to medical devices and certainly there is a huge difference in how you approach security when comparing a desktop used in the medical industry and an actual medical device (a device that serves a primary medical purpose).

Talking about definitions that are open for interpretation: the use of the term ‘Secure Product Development Framework’, which is very loosely defined, leads to it being largely open for interpretation. There is a large focus on applying traditional security (corporate end-point security) to medical devices (like pacemakers!?). This is much like attempting to put a square peg in a round hole. Cyber Security, no matter what the industry, should never be a one recipe approach. Indeed it is much like baking a cake. The basic ingredients may be the same; however there will be tweaks needed in terms of the flavouring and sprinkles. We can all admit no one likes exactly the same cake, or cake at all.

This brings me to threat modelling - which is heavily relied on to identify security objectives, risks and vulnerabilities. This again is much an interpretive sport. It is not really a process that can be replicated scientifically. Every threat model that you build will be different. The questions of when, and how often, do you build threat models also remain. This leads me to wonder if these are reviewed for each submission or whether this is just a tick box to say that there is some form of threat model created at some point in the past. Then, which threat modelling system do you use: STRIDE, PASTA or INCLUDES NO DIRT

The Software Bill of Materials (SBOM) is another hot buzz word that has been introduced albeit not new. This is something that is generally expected for a manufacturer to have, it is part of good manufacturing and manufacturers should know what components (whether physical or software) your system has. My concern is much about how this information will be shared with the hospitals or others that might request them, and in the expectations that pass with the delivering of them. In my opinion the responsibility should be for the manufacturer to maintain this and then make it available to healthcare providers. This can easily be achieved by having an accessible website or portal that collates and presents this information. The fear that I have is that this becomes a shift in responsibility that lands in the laps of understaffed hospitals to create and maintain and update a system which lets face it is not their responsibility to maintain. The other thoughts are about whether the SBOM will contain how these software components are implemented. We can all agree that a vulnerable software component may be just that, vulnerable, however the manner in which it is implemented means there may be security controls in place which make it not exploitable. I agree with the concept of the SBOM but for me the concern is about ownership. There will be an article that follows with regards to my ideas and thoughts on this. The last question on the SBOM which I have considered is whether when patients request this information, would it be made available to them?

The security architecture section is quite robust, and I almost wish other sections were given this much attention. This clearly defines what is expected to be done and the definition of security controls is not all together bad. The biggest thing here is that these are very universal and there will be those devices that fall outside of this.

The section that I potentially disagree with the most is, you guessed it, the ‘Event Detection and Logging’ section. This section would be great if all the medical devices that were manufactured had a native operating system. This is not the case. I had high hopes finally seeing that logs and early detection gets attention, I have been on a soapbox for long enough about this. However if you were hoping for some strong recommendation this is a good start but it has a way to go. I think this says it all?

While many of the following recommendations are tailored for workstations, the concepts presented below also apply to embedded computing devices. Manufacturers should consider these items for all devices.

If you know me I live and breathe Digital Forensics and Incident Response (DFIR). The guidance states that within the design phase there should be a capability to capture forensic evidence. This is not a huge ask, to be fair, but what about devices that have low CPU cycle capabilities, or for which power consumption needs to be limited? This is one which should be handled with caution. Also, if you consider the type of device, the hardware and the operating system it will have these abilities built in. This, in my opinion, should be something which should be introduced with caution and not all devices would this be viable for. I agree that the ability to do DFIR is critical. There are established practices within development and engineering that can be leveraged. The wheel exists already. The introduction of logs is created, most devices have a log but perhaps not with the right security information in as the logs are for debugging purposes. The statement however that logs should be stored on the device, well does this mean all devices should be connected. There are certainly instances where logs are not needed for security because the device has sufficient controls in place and that the device does not connect out. I know, shockingly, it is easy to motivate logs for systems, and business purposes however there are devices which do not require a security log. The recommendation to ingest these in some form of automated analysis software is good, however you might be creating a data swamp containing logs that have no relevance. I would have liked to see some strong logging requirements of what should be placed in logs. In my experience most devices have a log. It might not be a good log but it exists.

The following few bullet points focus very strongly on Windows based medical devices. The recommendations there are nothing new, it is things we already do to protect Windows based machines. It is very generic. When it comes to Android, Windows, Linux, and iOS no mention is made of leveraging operating systems level logs. These are critical to use, in fact they are one of your best insights into the devices. This section in my opinion is not considering what is needed to have logs in which you can practise early detection on. If you are wondering what good logs should look like, I have done many talks, and written numerous articles about this topic. This guidance proposes more logging without stating what exactly is meant by that. If you think logging is not a double edged sword, a quick search on CWE Mitre you will see that overlogging or sensitive data disclosure in logs is a real concern.

• CWE-778: Insufficient Logging
• CWE-779: Logging of Excessive Data
• CWE-532: Insertion of Sensitive Information into Log File
• CWE CATEGORY: OWASP Top Ten 2021 Category A09:2021 - Security Logging and Monitoring Failures

Similar to the predecessor to the current draft regulations, the 2014 one lacked clarity. Although it cannot be argued that some progress has been made the overall recommendation is somewhat generic and unclear. There are such a vast number of different devices however the focus has largely not been inclusive of embedded devices but more so general security as traditionally applied to workstation security. This leaves the manufacturer to determine and motivate what is relevant or “best practice” for their specific devices. Due to these forming part of premarket submissions one can argue that there is a need for better structured and conclusive and clear guidelines.

My hope for the future is that the way in which medical devices are classified becomes more clear, and well defined. That the guidance is less open for interpretation and has clarity in the guidance. That the focus shifts from the known devices to include guidance for those that do not fit the mould. I think a redraft to elaborate some sections, and perhaps take on board some points which simply do not work. This is my opinion and my thoughts both from the patients and the researcher perspective. It is a step in the right direction but we have still fallen short.

If you would like to read the guidance for yourself I invite you to have a look at it here FDA CyberSecurity Guidance Draft. The FDA has invited members of the public and manufacturers to submit their commentary to the guidance. This is available until the 7th of July 2022. I certainly will be submitting my notes. Cyber security of medical devices is a shared responsibility and I believe transparency and collaboration is key. This is certainly a step in the right direction. The work is not done yet, it is only starting. There are concepts and implementations that need to be better defined and conceptualised.

If you’re responsible for delivering digital products, services, software systems, applications, smart connected devices, pretty much anything technological and you’d like some help in making sure that everything is as secure as it needs to be then use our contact form below and we’ll get in touch for a chat.