Understanding and implementing the new FDA cybersecurity guidance
What makes a medical device seaworthy?
The new medical device your team is developing is not intended to sail the oceans, but thinking about it as a ship can help in understanding cybersecurity requirements and what’s required to keep it secure. This article is intended to provide an introduction for people who aren’t familiar with medical device cybersecurity without going into technical details (see this article and the links at the end of it for more detailed information). So let’s take a look at what’s needed to make a new ship seaworthy and then see how that translates into cybersecurity principles for medical device manufacturers.
First, there are some key features in the ship’s design to make it seaworthy (“security by design”):
- Watertight hull to keep the ship afloat
- Marine-grade components that are robust enough to survive the stress and corrosion at sea
- Warning systems to detect if the ship is taking on any water
- Emergency pumps to automatically pump out any water that leaked in
- Watertight bulkheads separating sections of the ship so that a hole in one section won’t sink the entire vessel
Second, the ship needs to be tested, monitored, and maintained by a seasoned crew (“security in operation”):
- Testing emergency responses and emergency equipment
- Crew training to ensure they know how to respond when disaster strikes and how to keep the ship safe
- Certifying seaworthiness by inspections and documentation to show the ship is ready for ocean voyages
- Monitoring for unsafe conditions or leaks in the hull
- Maintenance and upgrades – replacing broken or outdated components, patching holes, improving emergency equipment, etc.
Third, the ship needs clear leadership and responsibilities to safely operate on the ocean. Who will lead when something goes very wrong on the ship? During a crisis the crew can’t stand around arguing about who’s responsible for fixing the problem!
So now that we have a big, beautiful ship in mind, let’s return to medical device cybersecurity and the basic concepts in the new FDA cybersecurity guidance.
SECURITY BY DESIGN
Watertight hull
The ship’s architect rejected the proposal to have big openings in the sides and bow of the hull for easy loading of cargo.
Making a new medical device “watertight” starts with the very earliest stages of architectural design and will dictate many decisions on software technologies/platforms it will use (the security architecture). Typically, this means choosing a balance between ease-of-use and interconnectedness and security. It’s much easier to design security features from the start than to try to add them at a late stage of development. This is also the stage at which inexpensive or open source solutions need to be evaluated in terms of security and not just features or performance.
Marine-grade components
Shipbuilders use marine-grade components that are stronger and more corrosion-resistant than their land-based counterparts.
Likewise, developers of medical device software need to select components (software libraries, services, etc.) that don’t have known security vulnerabilities and that are actively supported. A single vulnerable component is all that a hacker needs to get past an otherwise watertight hull.
Warning systems
The red flashing light alerted the ship’s crew to a new leak and where it was located so they could quickly contain it and repair it before there was extensive damage.
Software monitoring will be a key factor in keeping your connected medical device secure after product launch. Therefore, any features designed into the software that can detect a security breach will help your incident response team to quickly focus on the cause of the breach and start working on a solution. Even if your device doesn’t have the capability to “phone home” with a security alert, it should have event logging that will support a subsequent forensic analysis of the security breach.
Emergency pumps
The ship’s architect knew that leaks are inevitable and included automatic bilge pumps down in the depths of the hull to remove seawater.
The software team needs to assume that security attacks are inevitable and design the software in your medical device to automatically resist them. Two key protective measures are to design the software to verify the integrity of all incoming data to the device and to verify the integrity of the code while it is being executed on the device.
Watertight bulkheads
Only one section of the ship was flooded when it collided with the rocks, preventing the ship from sinking.
Things will go wrong. Expect things to go wrong and plan for it. Security risk planning for a new medical device needs to include worst case scenarios. If practical, consider designing a safe mode into your medical device which maintains basic functions and which it defaults to in case it is seriously compromised. For example, for a ventilator, its safe mode might consist of simple operation with default parameters. The ventilator won’t be operating per the custom parameters the hospital staff have configured for each patient but this is far better than the ventilator stopping altogether. Or all the ventilators in the hospital stopping simultaneously.
SECURITY IN OPERATION
We have now built a beautiful, secure ship but we’re not yet ready to sail off across the Pacific Ocean. We need to fully test all the ship’s safety features. And we need to crew the ship with seasoned sailors who can deal with rough weather and emergencies at sea and who can maintain the ship. Without regular maintenance every ship, no matter how well designed, will eventually lose its seaworthiness.
Testing in the shipyard and the harbor
The captain made sure that every piece of emergency equipment was fully tested before the ship left the dock.
Security testing of a medical device is multi-faceted. At the lowest level it involves the use of tools for static and dynamic analysis and code reviews against secure coding standards to ensure robust code. Then it involves vulnerability scanning and software verification testing of the security requirements at a module or system level. Additionally, software interfaces with external systems need to be security tested. Finally, penetration testing (“pentest”) should be conducted on the full system by a third party. And some or all of these types of security testing should be repeated after each software upgrade to ensure that code changes or configuration changes do not undermine security.
Crew training
Seasoned sailors know if they see seawater pouring into the ship, to sound the alarm immediately! Also, to never leave the hatches open on the ship during a storm.
Companies that want to ensure their medical devices are secure need to become secure organizations. That means implementing a systematic security program (HITRUST, Drata, etc.) and training personnel in multiple departments beyond IT (Software Engineering, Operations, Customer Support, Field Service, Regulatory Affairs, etc.). That also means the quality system should include clear procedures and responsibilities for responding quickly to security incidents and rapidly deploying security patches. And that means not leaving any ‘hatches’ open on the medical device. For example, manufacturers should disable or otherwise restrict unauthorized access to all test and debug ports (e.g., JTAG, UART) prior to delivering products and should make sure service personnel don’t inadvertently change the security configuration.
Certifying seaworthiness
Before they paid for their new ship, the shipping company carefully reviewed all the test reports and other documentation from the shipbuilder.
The FDA requires a considerable amount of documented evidence in a submission to be able to conclude that a new medical device will be resilient to cyber threats (seaworthy). So medical device manufacturers need to conduct their security activities systematically and fully document the results in a manner that aligns with FDA expectations. Note that re-submissions for any updates to legacy medical devices need to meet the same rigorous documentation requirements.
Monitoring
The ship’s chief engineer carefully studied sensor logs from the ship’s engines and other critical systems to predict if they were deteriorating and maintenance was required.
Just as medical device companies track product quality and how well quality system processes are functioning, they need to track product security metrics and how well security processes are functioning. This means recording and evaluating metrics such as percentage of identified vulnerabilities that are patched and how long it takes to deploy patches.
Maintenance: updatability/patchability
The ship’s crew was continually performing maintenance while at sea and in port. They knew that old seals and gaskets had to be replaced before they started leaking.
Just because your ship was seaworthy when it was originally launched doesn’t mean it will continue that way without regular maintenance. Likewise, a new medical device, no matter how carefully designed, will not remain secure for its entire lifetime which could be many years. Software technologies evolve rapidly and new cyber threats emerge. Vulnerabilities are regularly discovered in older software components which must be replaced. Therefore, to remain secure medical devices must be designed for efficient and secure software updates/patches. Devices that cannot be updated may have to be removed from the market as soon as the first significant security vulnerability is discovered.
Conclusions
A seaworthy medical device, like a well-designed ship, requires security measures in its design, operation, and maintenance. In the design phase, it needs a secure architecture, robust components, warning systems, and safeguards against vulnerabilities. During operation, it requires thorough testing, crew training, certification, ongoing monitoring, and prompt response to incidents. Maintenance involves regular updates to address evolving threats.
Make sure that cybersecurity is part of every stage of your product development process and your company has the resources and processes to support and maintain medical devices until they are withdrawn from the market.
Now that you’re familiar with the basic concepts for cybersecurity, let’s look at what the FDA requires in its new cybersecurity guidance.
“The art of the sailor is to leave nothing to chance” – Annie Van De Wiele
“A ship in harbour is safe, but that is not what ships are built for” – John A. Shedd