Welcome back to our continued breakdown of the new FDA Cybersecurity guidance. In this post, we will conclude our analysis of the “Trustworthy Devices” section of the document.
As previously touched upon in the last blog post, a new task set out for manufacturers revolves around ensuring each device should have the ability to make a Software Bill of Materials (SBoM) available in a machine-readable format. This should be independent of whatever communications systems are used. A user must be able to interface with the device in order to determine which operating system, libraries, and software components were used in development. Like the guidelines surrounding the configuration of a device, if a hospital or other authorized user wants to know if a device is vulnerable to an attack due to 3rd party software, they should be able to quickly obtain this information. This could take the form of something as simple as a comma separated file or as complex as some existing standards, such as SWID or SPDX.
The device also needs to be able to respond to and contain the impact of a potential cybersecurity incident. This may include resetting itself back into a secure state, and it should notify the user if this occurs.
There also exists a requirement for the rapid deployment of software patches. Should a device need to updated for any reason, specifically to patch a known vulnerability, it is necessary that it be able to have both its software and firmware updated while in the field.
Finally, the device needs to be designed to recover capabilities or services that were impaired due to a cybersecurity incident. Below are a few examples of these types of incidents:
- Ransomware – an unauthorized user penetrating a device to encrypt part of the system to prevent access or function of aspects of the device
- Secure Configuration –engineers must ensure manipulating a device, e.g. increasing the dosage or changing therapy settings, can only be done by authorized users of appropriate privilege levels
- Autonomous Functionality – if a device uses feedback from the body to fine-tune its therapy, and the component reading the body malfunctions and can no longer provide this information, the device should revert to a safe mode of operation and continue functioning at a baseline level, regardless of which features are temporarily unavailable.
- Tolerance of Quality of Service – If a device is expecting to receive a packet very 100ms, but a delay occurs, how will the device handle this delay? Designs needs to be sufficiently resilient in the event that communications do not occur at the expected intervals.
The good news is that most manufacturers have already considered these scenarios as part of normal operation and expected interference, not necessarily with security in mind. Where appropriate, this type of functionality is may already be in place.
This concludes our section on “Trustworthy Devices”. Part 6 will examine the portions of the new guidance pertaining to “Cybersecurity Labeling”. If you'd rather not wait, you can download the entire white paper here.
If you would like to be notified of when these posts go live, please sign up for up-to-date email alerts to the right of this page.
