Today hospitals have 15-17 connected medical devices per bed, with the total number of connected medical devices in operation projected to grow to 50 billion over the next decade. Facing a growing attack surface, the US Food and Drug Administration (FDA), the governing body over medical devices, has issued an update to the premarket cybersecurity guidance.
The recent FDA premarket cybersecurity guidance requires medical device vendors design devices with security in mind. This guidance will be the measure for 510(k) clearance for new medical devices, and outline industry leading practices for live devices. Whether you’re in product security, an R&D engineer or part of information security, there are five critical considerations to heed when implementing industry-leading practices.
The new guidance establishes two tiers of medical devices. Tier one includes connected devices where if an incident occurs, it could impact patient care. These devices have rigorous documentation requirements, risk assessments, design controls, methods to limit access, labelling requirements, incident response and data integrity requirements. Tier two devices, defined as anything that’s not tier one, must either demonstrate the same attributes, or cite a compelling justification for a failure to meet these requirements.
Tip: Determine (early on!) which tier a medical device is categorized as, then build the requirements into the development and subsequent support lifecycle.
Secure Development Lifecycle
Device vendors are very familiar with clinical safety product lifecycle management requirements, but for many cybersecurity is a less familiar area. Understanding clinical use of devices can be straightforward, but the cybersecurity attack surface requires thinking beyond standard operational use. Coding standards, fuzz & penetration testing and ongoing maintenance procedures collectively can limit the attack surface.
Tip: Security practices should cover the entire development lifecycle, including third-party validation and testing after products are deployed.
Focus on Cryptography
Perhaps the most frequently referenced technical intervention in the premarket guidance document, encryption must be extensively implemented to keep data private. Encryption is used so attackers can’t read plaintext messages or stored data (such as medical records). The best practice is to encrypt data and then sign it with a cryptographic signature. These digital signatures are used to verify authenticity of devices, data, and instructions.
Tip: Never rely on security through obscurity. The most brilliant cryptographers recommend a system that has faced intense security from the security community.
Improve Postmarket Maintenance
Devices should be designed in a way that anticipates regular, routine cybersecurity patches. Having transparency into device components, via a Cybersecurity Bill of Materials (CBOM), allows for better understanding of potential risks when vulnerabilities are identified. Updates should come from an authenticated source, with an attached digital signature, allowing updates to address known vulnerabilities without introducing new ones.
Tip: Information security threats change rapidly. Identify potential issues proactively and resolve them before they become costly problems.
Monitoring of Device Behavior
Devices should be able to alert users when a cybersecurity breach occurs. This will be a challenging feature to implement in certain classes of devices, and has been the subject of some debate inside the medical device security community. The most likely way a manufacturer would meet this objective is through active monitoring of device behavior, spotting when a device looks to be under attack. This means being able to identify what ‘normal’ behavior looks like for entire classes of devices, without sharing otherwise sensitive device data.
Tip: Security doesn’t “work” in a vacuum. Move from security decisions made ad-hoc to a deliberate data driven approach.
This guidance emphasizes that product cybersecurity not only focuses on securing sensitive patient health information, but needs to minimize the chance for exploiting cybersecurity vulnerabilities for clinical safety concerns. Incorporating these critical considerations should not be perceived as a compliance requirement, but as table stakes in medical device software development.