What should my cybersecurity management plan entail?

"The future of cybersecurity is not in building higher walls but in building smarter systems that can adapt and learn from each new challenge".

-Dan Schulman, CEO of Paypal

FDA risk mitigation overview

This is not intended to be an exhaustive list. We recommend that you consult FDA resources to plan and implement better risk mitigation strategies.

According to the FDA, you must have a strategy for identifying, monitoring, and addressing cybersecurity vulnerabilities and potential exploits, a plan for addressing vulnerability disclosures and for establishing incident response protocols, as well as a plan for post-market updates and patches on a routine basis.

Strict cybersecurity breach notifications coming soon!

The FDA will soon require that you report major cyber incidents to the Cybersecurity and Infrastructure Security Agency (CISA) within 72 hours after the incident. For ransomware payment cyber attacks, you will have 24 hours to report this to CISA. These requirements will likely go into effect late in 2024 or 2025.

They also require that you report major cyber incidents to the Cybersecurity and Infrastructure Security Agency (CISA) within 72 hours after the incident. For ransomware payment cyber attacks, you have 24 hours to report this to CISA.

Need more detail on FDA requirements?

Here's the government-speak for you!

• Postmarket cybersecurity vulnerabilities and exploits: Section 524B(b)(1) of the FD&C Act requires that you provide a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures.

• Known acceptable vulnerabilities: Section 524B(b)(2) and 524B(b)(2)(A) requires that you make available postmarket updates and patches to the device and related systems to address these, on a reasonably justified regular schedule.

• Critical vulnerabilities that could cause uncontrolled risks: Section 524(b)(2) and 524(b)(2)(B) requires that you make available postmarket updates and patches to the device and related systems to address these, as soon as possible out of cycle.

"The pace of technological change requires us to rethink our strategies for security, and embrace a proactive, not reactive, mindset."

-Bruce Schnier

FDA 2014 premarket cybersecurity guidelines

The FDA 2014 Premarket Cybersecurity Guidance recommended that manufacturers provide the following:

• Hazard analysis, mitigations, and design considerations pertaining to intentional and unintentional cybersecurity risks associated with your device, including:

  • A specific list of all cybersecurity risks that were considered in the design of your device;

  • A specific list and justification for all cybersecurity controls that were established for your device.

• A traceability matrix that links your actual cybersecurity controls to the cybersecurity risks that were considered.

It also recommends managing the device postmarket and providing the plans as part of the premarket submission in Section 6, Items 3 and 4.

• Plan for continuing support: How your company will monitor and maintain cybersecurity

• Plan for malware-free shipping: How your company will ensure malware isn’t introduced in the manufacturing process or while devices are being updated in the field.

Managing postmarket cybersecurity in medical devices

Section X of the Postmarket Management of Cybersecurity in Medical Devices guidance also makes recommendations about the elements of an effective postmarket cybersecurity program.

MITRE also provides a Medical Device Cybersecurity Regional Incident Preparedness and Response playbook and the Playbook for Threat Modeling Medical Devices.

Device labeling

You should also address labeling as part of your cybersecurity program, including device instructions for use and product specifications related to recommended cybersecurity controls appropriate for the intended use environment (e.g., antivirus software, use of firewall). This should be consistent with your risk controls, including any configuration on the computer or platform (e.g., popup blocker recommendation). It should also include instructions to ensure the safe and effective use of the device, including interfaces and functionality, security controls that the user interacts with (e.g., password, software updates, etc.), your Manufacturer Disclosures Statement for Medical Device Security (if you provide it to customers), also called MDS2., your SBOM (if you provide it to customers), and logging capabilities and forensic log capture.

Create your cybersecurity strategy

This list isn't exhaustive, but should help you get started on created your cybersecurity strategy.

1. Understand the regulatory requirements for medical devices

2. Choose encryption tools

3. Determine encryption algorithms

4. Key management

5. Auditing data

6. Speed of the encryption

7. Consider hardware resource constraints

What does a medical device encompass?

"The definition of a medical device encompasses not only capital equipment, but also surgical instruments, patient monitoring, and even software. The breadth and variety of the field, combined with the critical importance of med devices to life and safey, requires a deliberate, focused approach to cybersecurity to ensure that they are resilient throughout their lifecycle."

-Nancy Brainerd (CISSP/CIPP), Senior Director of Product Security

Common risks to be aware of

Get the Medcrypt expert inside scoop!

In our experience with several clients, we have found the following to be common risks to mitigate to improve likelihood of obtaining FDA submission approval:

• Using authentication by proprietary means: The FDA and Medcrypt have found that “proprietary” often means that it has not been widely or thoroughly tested.

• Not using unique keys on each device: If one device’s secret is compromised, now all devices are compromised. This has already led to at least one recall.

• Impacts caused by unexpected, non-standardized, or malformed NFC/RFID exposure

• Designs that did not initially implement channel authentication and communication signing and encryption.