This post resumes our discussion of the FDA’s new cybersecurity guidance for medical devices surrounding the design and development of trustworthy devices.
The next criteria the FDA has laid out for manufacturers involves the ability to detect cybersecurity attacks in a timely fashion. Conveniently, the definition of a “timely fashion” has been given some flexibility to vary depending on the medical device in question. This could be defined in microseconds, milliseconds, hours, or even days, depending on the application. An appropriate definition must be included in your security documentation.
To comply, manufacturers must first have a system in place to log security events as they occur. Currently, few medical devices or systems log or store data appertaining to security events. An example would be attempting to authenticate to a device, or performing a data integrity check, which results in a failure. Such events should be placed into a security log..
These security events can occur by improbable releases of static electricity or a coordinated attack. The FDA is not looking for a deep level of forensic detail, but does want to make certain that these events are logged and accounted for as they take place -- even if there is little chance the log will ever be transmitted out of the device.
The guidance also makes note of forensic evidence capture (AKA “non-repudiation”). First, forensic evidence capture is used to make certain that the log’s integrity is maintained. As records are stored in this log, the integrity of the contents of each record and the integrity of the order of each record relative to the other records is continuously verified. This ensures the event logs cannot be tampered with while avoiding detection. In the event of patient harm or fatality, these logs could be used as forensic evidence in legal proceedings.
Device Configuration
If a device has been compromised, it is imperative that it can be reset to a safe & secure configuration. An example would be if a pacemaker loses its ability to communicate via BLE because of a “denial of service” attack, the device must continue to provide stimulation to the patient’s heart, ensuring its intended functionality remains uncompromised. The pacemaker must be designed to limit the impact from any vulnerability within its base mode of operation, while retaining the ability to disable features to prevent the attack from progressing. Many medical devices do not have this capability, but it is now an FDA requirement.
Software Configuration Management
Manufacturers are now required to create an interrogation process which reveals device configuration, e.g. device and firmware versions, to authorized users. In addition, interrogation must reveal a software bill of materials that itemizes all third-party software components utilized in the device and its system, including the name, origin, and version of each software component. This is important because if a vulnerability is discovered in one of these third-party software components and disclosed, hospitals must have a method to quickly determine whether a given device is now known to be susceptible to attack and whether patients are at risk. This information will determine what action the hospital should take, including updating or replacing the device as necessary.
This concludes the fourth part in this series of coverage over the new cybersecurity guidance by the FDA. Our final installment surrounding the design and development of trustworthy devices will be next. 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.
To learn more about Christopher Gates and his background in medical devices and cybersecurity, click here.