All systems fail; the difference is the consequences. An implanted medical device may have different threats, technologies, and attacker motivations than a banking or telecom system, but the security principles are the same. The recent FDA-issued guidance, while new to the mandate but not to the technology/security industry, states that all new medical device applicants must now submit a plan on how to:
- Monitor, identify, and address cybersecurity issues
- Create a process that provides "reasonable assurance" that the device is protected
- Make security updates and patches available on a regular schedule and in critical situations
- Provide the FDA with "a software bill of materials" (SBOMs), including any open-source or other software their devices use
Notably, many of the requirements were documented in Medical Device Manufacturer (MDM) pre-market product release guidance for years, but enforcement will officially start on October 1st, 2023. Nearly a year ago, the latest Cybersecurity in Medical Devices guidance was published, calling for things like threat modeling, cybersecurity testing, and labeling devices with cybersecurity risks (akin to a window sticker on a new car).
These requirements have been sought by the FDA for years; however, not until December 2022 were they enacted into law, as previous attempts to include the pre-market requirements (known as the Protecting and Transforming Cyber Health Care (PATCH) Act) were left off bill after bill. The FDA finally got its wish and included all previously documented requirements for new submissions into their final guiding edict, "Cybersecurity in Medical Devices: Refuse to Accept Policy for Cyber Devices and Related Systems."
Document and Mitigate Threats to Medical Devices
For over two decades, we’ve been conducting software and system threat models on medical devices, robotics & a plethora of smart home devices. We understand the IoT ecosystem well and focus our efforts on high-risk areas that attackers love to target, like bypassing authentication controls and tampering with data.
The good news for MDMs is that nothing in this document (nor the long-standing cybersecurity requirements previously recommended by the FDA) is new to the cybersecurity or IoT industries. They memorialize good practices that many products have been built and managed with for years.
The Root of Insecurity – Software
At the root of insecure medical devices and the FDA guidance is insecure software – both homegrown and third-party components. Standards such as PCI (DSS & SSF), NIST 800-218, and others have already created software-specific mandates highlighting "best practices" to adopt organization-wide. Even open-source and non-profit organizations like OWASP and CSA (Cloud Security Alliance) have a secure medical device deployment standard.
Insecure software continues to find its way into all of these regulations because software runs the world – specific sectors, like healthcare, need to catch up in securing it. Software and its interconnected nature is the primary attack vector into medical devices. It doesn't require physical access to the devices, and software is, and has always been, horrendously challenging to secure.
The Cavalry Has Been Waiting
A longtime friend of mine, Josh Corman, started an organization called I Am The Cavalry years ago after coming to the sobering realization that there wasn't a concerted effort (anywhere) focused on the intersection of digital security, public safety, and human life. Josh was instrumental in getting the FDA guidance for MDMs to include the fundamental cybersecurity requirements they do. He also led efforts to include SBOMs in medical devices. In May 2022, he testified before the U.S. Senate Committee on Health, Education, Labor, and Pensions (HELP) on the current state of cybersecurity in the healthcare sector (the healthcare-specific clips have been compiled here for your viewing pleasure). On January 19th, 2016, I Am The Cavalry published an open letter to the Healthcare Stakeholder Communities urging them to pledge to the "Hippocratic Oath for Connected Medical Devices." You'll see many similarities in that oath to what ended up in the FDA guidance.
For many years, the healthcare industry associated cybersecurity with privacy, i.e., HIPAA covers confidential information. And when considering safety, the industry only focused on the accepted use case, e.g., a scalpel is safe if it's used as intended by the surgeon. Cybersecurity is all about the misuse and unintended behavior. So just the term safety separate from the term cyber caused a huge cognitive gap. Combining these into "cyber safety" helped the industry finally look at the blind spot they'd been not seeing for years.
The Light at the End of the Tunnel
Like most modern digital products, medical devices are assembled from many third-party parts (like a car), including open-source software, vendor-supplied hardware & software, and connectivity like Bluetooth & Internet Protocol (IP.) The fundamental difference between a connected medical device and a non-medical IoT device is the element of human safety and patient data.
For those that build, operate, and defend medical devices, cybersecurity resilience (and the ability to comply with the new requirements) focuses on the people, processes, and technology involved. Sounds simple, right? It is, but it requires commitment and diligence.
I recommend starting with a skill gap analysis to determine current capabilities vs. needed competency to secure the types of technologies medical devices are built from/upon. Follow this by reviewing the process by which your product is built, considering how security is incorporated at each step (starting with initial requirements and, most importantly, identifying dangerous practices. Once you have a decent handle on required security skills and process steps, the places where you can introduce tooling become self-evident.
Let's break down the new requirements into three fundamental security approaches:
- Security Risk Management
- Threat Modeling
An incredibly undervalued and useful tool. The process is simple: imagine threats to your system, document how those threats might be carried out successfully, and build defenses to thwart the threats. As new threats emerge or attack surface elements are discovered, update your threat model. That's it! The FDA will accept threat models in almost any form to start. - Software Bill of Materials (SBOM)
This is the back-of-the-soup-can label. What ingredients did the manufacturer put in there? No need to give away your secret recipe; remember, these are just the ingredients, not the step-by-step process of how to make something specific. Software Composition Analysis (SCA) products can help here. - Unpatched/Known Vulnerabilities
This is a natural follow-on to SCA, which tells you which of your software components have known vulnerabilities. You can update them before submission or include them in the required list of known cybersecurity risks in section VI "Cybersecurity Transparency." Of course, if you knowingly ship a vulnerability, there could be liability implications. I'll leave that for the attorneys to decide.
- Threat Modeling
- Security Architecture
This is your foundation - security design and operating principles such as authentication, authorization, cryptography, and event logging - to name a few. Why does this need to be in place? Because many medical devices don't require users to sign on, they don't protect patient and medical data by encrypting it or storing any anomalous activity. Nothing to invent here; use the many cloud or native options at your disposal to implement authorization/authentication, data protection, and logging. - Security Testing
Security Testing shouldn't be where you catch the majority of issues. Activities like threat modeling and security design reviews are better suited for that and can arguably have a higher impact. Instead, testing should be validation that you've done things correctly. Once again, software testing, validating encryption at rest and in motion, and software composition analysis can be implemented manually or automatically (ideally both).
Products that touch any element of "safety of life" will continue to be more regulated, similar to the automotive industry (which is battling with SBOM and cybersecurity transparency). Standards, regulations, and security assurance measures have been required in many industries for years. For MDMs, now is the time to build a scalable program that reduces cybersecurity risks and ensures you are set up for success in current and future mandates.
About Ed Adams, CEO
Ed Adams is a software quality and security expert with over 20 years of experience in the field. He served as a member of the Security Innovation Board of Directors since 2002 and as CEO since 2003. Ed has held senior management positions at Rational Software, Lionbridge, Ipswitch, and MathSoft. He was also an engineer for the US Army and Foster-Miller earlier in his career.
Ed is a Ponemon Institute Research Fellow, Privacy by Design Ambassador by the Information & Privacy Commissioner of Canada, Forbes Technology Council Member, and recipient of multiple SC Magazine’s Reboot Leadership Awards. He sits on the board of Cyversity, a non-profit committed to advancing minorities in the field of cyber security, and is a BoSTEM Advisory Committee member.
