In March, the FDA announced that a new policy rolling out could cause acceptance issues for Medical Device manufacturers and their creations.
- News: FDA requires medical devices be secured against cyberattacks | CNN Business
- FDA guidance issued on March 30 Cybersecurity in Medical Devices: Refuse to Accept Policy for Cyber Devices and Related Systems Under Section 524B of the FDC Act (fda.gov)
The policy requires that all new medical device applicants must now submit a plan on how to “monitor, identify, and address” cybersecurity issues. Applicants must also create a process that provides “reasonable assurance” that the device in question is protected. Finally, applicants will need to make security updates and patches available both on a regular schedule and in critical situations. Applicants must also provide the FDA with “a software bill of materials,” including any open-source or other software their devices use.
The new security requirements came into effect as part of the sweeping $1.7 trillion federal omnibus spending bill signed by President Joe Biden in December. As part of the new law, the FDA must also update its medical device cybersecurity guidance at least every two years.
So, what does this mean for Medical Device manufacturers? It says a lot, but the underlying message is this: If there are cybersecurity flaws in medical devices that can impact patient safety or hospital safety, or have other serious cybersecurity implications, the device will not be sold until the flaws are remedied. This may mean delays costing millions, as well as possibly necessitating re-submission of the Premarket Notification 510(k) submission package for the device in question.
For companies that follow the FDA’s recommended UL2900 series of recommended cybersecurity controls for connected medical devices, most of the paperwork portions including the software bill of materials should already be generated as artifacts in a form that should be presentable to the FDA.
If not, these documents would need to be generated at record speed before the device is presented for a 510(k) submission to the FDA. According to the FDA website, “A 510(k) is a premarket submission made to FDA to demonstrate that the device to be marketed is as safe and effective, that is, substantially equivalent, to a legally marketed device (section 513(i)(1)(A) FD&C Act). Submitters must compare their device to one or more similar legally marketed devices and make and support their substantial equivalence claims.”[1]
That brings us to more interesting artifacts better aligned with my expertise: penetration test artifacts that must be submitted to the FDA. This is where things may get more difficult for device manufacturers, depending on how they align their tests.
The goal of a penetration test against a medical device is to emulate a threat — whether it be state sponsored or “script kiddie” — that can cause patient harm, patient care issues, interrupt treatment or cause service disruptions within the hospital or medical treatment center. The primary concern here is for the patient, the person for whom this device was created — as well as ensuring that patient safety is not impacted by threat actors.
This type of assessment is an in-depth process that involves looking at multiple aspects of device security such as hardware, software, peripherals and other types of input/output systems. Each of these aspects needs to be fuzzed, analyzed, and tested for flaws that could affect patient care as well as issues that could compromise the computing systems they reside on. Many common vulnerabilities and exposures (CVEs) that I have located with regards to medical devices pertain to bypassing the kiosked applications that run on these devices to gain unauthorized access to the underlying operating systems. Getting to the point of bypassing the kiosk took hours, sometimes days to discover a chain of flaws that would allow me to successfully bypass these controls.
Also included is deconstructing the device to look for alternate ports such as JTAG, UART or other unprotected ports, additional USB ports, accessible hard drives and sometimes lockpicking, depending on the security controls (if any) that exist on the case. Then comes forensics and post-exploitation movements, payload detonation, pivoting and operating system adjustments that can affect patient care. Added onto my post exploitation routine is reverse engineering proprietary binaries and programs to locate sensitive keys to validate if encryption uses statically set or dynamically created encryption keys.
Again, the process is very time consuming, and emulating state-sponsored threat actors takes patience and the willingness to fail, overcome those failures, and succeed in your end goal. When the job is done, these systems are that much more protected against incursion. Ensuring that the device to be tested receives a very deep inspection of the true attack surface is crucial, especially when the device is being marketed to the Department of Defense or other government entities.
After we conclude tests with our customers, I like to ask them a few questions about prior assessments they may have had done before we worked with them. Often, our team finds multiple flaws that can be addressed before threat actors can leverage them. That’s why I ask customers about their assessment experience, and most importantly, why they think critical and high severity flaws detected by our team were missed in previous assessments.
I do this to get a feel for the tools used, methods tested, and what coverage of the device the previous tester felt was complete. With several large device manufacturers, we’ve been told that their prior “penetration test,” if can be called that, was not really anything more than a run of a Windows or Linux enumeration script such as Winpeas. Based on discussions with at least one contact at the FDA, running this type of script is not considered a penetration test.
The takeaway is this: if this is the type of test that a security vendor is proposing for your next adversarial medical device assessment, please compare our offerings and contact us for a full assessment of your device the way an Adversary would attempt to gain access.
I applaud the FDA for implementing these cybersecurity regulations. This change has been long overdue for medical devices to keep up with the pace of threat advancement. Today, the FDA has in place something that is tangible, more meaningful, and that has potential to have a real impact on ensuring that medical devices are secure.
Many devices in the field still suffer from flaws due to the additions of new technologies like ethernet and wireless internet. Previously, these were completely isolated systems in which only physical threats could affect these systems — that is, until companies decided to network them (or connect them to other online systems). Oftentimes, the lack of security comes from the additions of new networked technologies on top of legacy hardware and software that are deprecated, such as outdated operating systems or poorly designed IoT network stacks. As such, the “bolted on” security controls for many of these devices have been less than adequate, resulting in exposure of patients and medical providers to all types of security risks.
The chief thing these new regulations accomplish is accountability. Whereas compliance was once voluntary, new mandatory requirements — and potentially costly fines as punishment for failure to comply — have made that laxity a thing of the past.
For information on how you can better protect your assets and networks as well as produce safer, more protected medical devices, contact Secureworks and learn how to get started with a robust security testing program.