Thus far, regulatory guidance for medical device cybersecurity has been focused on the approval or compliance of the device itself and has not been very specific about what cybersecurity assurance information is provided to the health care customers that host the devices within their IT infrastructure. Medical device labeling has been sparse related to cybersecurity leaving hospital cybersecurity managers on their own to understand the risk to their overall network. As a result, it is very common for hospitals to now request very specific information from medical device manufacturers using questionnaires and forms – we refer to this as Customer Facing Cybersecurity Documentation. This is information needed by the health care institution to assess the risk of connecting these devices to their network, and often includes questions such as the type of encryption and security algorithms used by the device among others. It is important for the manufacturer to respond to these questionnaires with clear, complete, and well thought out responses.
Our advice is to be proactive with preparing customer facing documentation related to cybersecurity. Often this is simply an exercise in documenting the overall strategy and design that has been created during the engineering process. Typically the hospitals’ request is usually known and documented somewhere within the design history file, but not collected in a way that is useful as information to hospital IT security. A good proactive approach is to begin collecting and documenting this information that can be expected from hospital questionnaires into an internal summary, so that responses can be prepared more quickly and consistently. As with all cyber security management, the process is on-going and questionnaires will likely be an annual process even for the same device.
Let’s consider an example of interaction between healthcare system cybersecurity and the medical device manufacturer, using a scenario regarding vulnerability to a denial-of-service (DoS) attack (such as a SYN flood). We know that many embedded systems (including medical devices) do not currently have much internal firewall capability, and they rely on network routers to prevent this kind of attack. However it is appropriate to communicate this vulnerability to the clinical system integrator using Customer-facing Cybersecurity Documentation, so that they are clearly aware that the medical device manufacturer is fully relying on broader hospital network protection for that case. There might be specific aspects to the vulnerability that could be addressed by hospital network firewall configuration, and specific clinical risks with the device if an attack were to succeed. This device information is helpful for hospital cybersecurity, to assure that the risk is effectively managed.
As a side note… If warranted by the clinical risk, consider an option to implement some firewall capability in the device, as it reduces risk much further to have protection in multiple places. Some devices have main processors that are running operating systems such as embedded Linux, which provide capabilities to have protection within the device without much added effort. A good case can be made for providing these DoS risk controls within the device embedded system.
You can read the latest FDA guidance on pre-market expectations for cybersecurity engineering activities in the 2018 draft guidance. Click to download: 2018-Content of Premarket Submissions for Management of Cybersecurity in Medical Devices
See our previous post about the FDA role in Cybersecurity: The FDA’s Role in Medical Device Cybersecurity