Designing and developing trustworthy medical devices, according to the new FDA guidance on cybersecurity, will be our focus for the next two posts.
The guidance’s stance is as follows:
“In particular, devices and systems should be designed to protect assets and functionality in order to reduce the risk of multi-patient harm due to the loss of:
- authenticity
- availability
- integrity
- confidentiality
Specifically, protection mechanisms should prevent all unauthorized use (through all interfaces), ensure code, data and execution integrity, and as appropriate, protect confidentiality of data (insofar as its release could be leveraged to effect multi-patient harm).
As a part of premarket submissions, manufacturers should submit documentation demonstrating how these design expectations are met.”
There’s a lot to unpack in the above statement and the changes it introduces. Let’s begin with a hypothetical example:
Assume there is a medical device which contains a serial port that is exclusively used for developers to interact with the device itself, and is not part of its normal operating communications system. The port’s only function is to transmit non-patient-related, non-patient-identifiable device operating information.
Under previous standards, this would have been an interface a manufacturer could have justified leaving unprotected, due to lack of therapy-modifying functionality, zero risk for exposure of patient data, and minimal potential for disruption of device operation. Under the new guidance, however, there is no leeway for interpretation. Any port that potentially could be used to infiltrate the device must be secured.
Moving on to consider individual requirements, we come to:
Prevent Unauthorized Use
One of the first requirements named in the section excerpted above includes both people and devices. If two devices or systems connect to one another, each must be authenticated to the other in a cryptographically strong way.
To clarify, we must understand the difference between authentication and authorization: the former being complex and difficult, and the latter relatively simple in comparison. Authentication is a process by which two systems communicate with each other to determine that each party is in fact who they say they are. Authorization is granting access to exactly the data or actions allowable to a given authenticated user.
For example, a junior engineer can request access to the source files of a specific project and can be authenticated within the system, but their authorization would only allow them to view and edit a subset of those files. The lead engineer, once authenticated, would be authorized for unrestricted access to all files. In security terms, this is referred to as “user privilege”.
Code, Data, & Execution Integrity
Assuring code and data integrity requires processes that most medical device manufacturers already follow; those who don’t, will be soon. These processes entail a signature or hash of the code, protected in a cryptographically strong way. (A cyclic redundancy check (CRC) does not qualify, as it is not cryptographically strong. Manufacturers should instead look to crypto hashes such as SHA256, HMAC, CMAC, etc.)
While code and data integrity were covered in the previous FDA guidance, execution integrity is a new guideline that will be difficult to implement. In simplified terms, execution integrity means defining how the device can verify that intended software execution is being executed in the way the device was designed.
As an example, execution integrity can be thought of as an aggressive watch dog timer. It would monitor that the correct functionality was being executed within the processor and during the proper time frames. This functionality can be found and provided by ARM or TrustZone-enabled microcontrollers.
This can be particularly challenging in small, resource-constrained microcontrollers. While difficult, engineers and developers should remember that maintaining the intended execution integrity within the device (aka “essential clinical performance”) is what’s most important. This can be partly linked to code integrity in that once the device boots up, it can check to see if the right program exists and confirm it is executing the intended one.
Maintain Confidentiality of Data
The new guidance does not restrict data confidentiality to patient health information (PHI) or patient identifiable information (PII) only. It is intentionally all-inclusive, encompassing all data transmitted through these devices. It also defines data into two separate classes - “at rest” and “in motion”.
“At rest” data has been or is being saved to memory within a cellphone, hard drive, flash memory, etc. Its defining attribute is that it is not being actively transmitted and is “at rest” in a data cache. This data must be encrypted, as it encryption is the only acceptable solution for confidentiality.
“In motion” data is the exact opposite of its “at rest” counterpart. This is data that is being transmitted or communicated across devices. Examples include a Bluetooth Low Energy transmission to a cell phone, a phone sending data over Wi-Fi to a network access, or between two PCs over ethernet. Once again, encryption is the only security solution that is accepted by the FDA for this process.
The difficulty with encryption is that encryption/decryption activities require “keys”. If keys are compromised, this could potentially expose a larger attack surface, where if one device is infiltrated, it can lead to the penetration of all similar devices.
To mitigate the risk of exposure, do not utilize a “common key” for any operation where the same key value is applicable to all devices of the same type. Each device should require a unique key value. This is completely different from the discussion between utilizing symmetric vs. asymmetric encryption, as in either case unique keys or key pairs need to be utilized.
This concludes the third part in this series of coverage over the new cybersecurity guidance by the FDA. In the next installment, we will continue our discussion on the proper way to design and develop trustworthy devices. 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.