Michael Barbella, Managing Editor11.10.22
It’s been a difficult year for the Spoth family.
Doctors in January diagnosed son Gavin with type 1 diabetes, a chronic condition that robs the pancreas of its insulin-making ability. Such a life-altering prognosis can be unsettling, worrisome, and even a bit frightening for those afflicted, especially children, who may be confused by their body’s betrayal.
Confusion was just one of the emotions coursing through the Spoth household after Gavin’s diagnosis. Despondency, anxiety, and astoundment were present too while the boy and his family gradually forged a treatment strategy based on the latest blood glucose measuring/monitoring technology.
Those feelings, however, eventually gave way to anger and frustration over (perceived) subpar diabetes management software and patient data security risks. “One thing that is abundantly clear over our first few months post-diagnosis is that, while the medical technology is for the most part wonderful and works the overwhelming majority of the time, the software behind that technology is highly lacking,” Eric Spoth told the U.S. Food and Drug Administration (FDA) in written testimony this past summer. “Integration with existing operating systems and devices is shoddy at best, if attempts are made by the companies at all. While the systems themselves are seemingly stable, we quickly realized we needed better integration with hardware than these companies provide.”
In his testimony, Spoth lauded the benefits of third-party software, noting these systems are easily integrated with current smart devices and thus allow for continuous blood glucose monitoring. Limiting access to these systems, he warned, will restrict consumer choice and potentially create software tech monopolies. He also advised against prohibiting diabetes patients from accessing their personal data.
“I am conscious of the cybersecurity concerns here, but there really should be a middle ground for those who use these systems not for administering insulin, but for collecting readings as part of an entire approach to care,” Spoth testified. “These systems are often better than these companies can offer and a lot of people rely on them so please I beg you try to be light-handed with your regulations.”
Spoth’s testimony was among the deluge of feedback the FDA received after releasing an updated medical device cybersecurity draft guidance in April. Most comments (1,870 total) came from diabetes patients and/or their caregivers concerned the revised regulations would considerably limit their ability to access their medical devices and (blood glucose) data.
“Do not lock patients out of their own medical data, or out of control of their own medical devices. That should be of paramount importance in every cybersecurity policy—companies cannot be allowed to hold patients hostage by holding vital data and treatment options in walled gardens where the company’s rules are more important than the patient’s health,” William Ray wrote in his comments to the FDA. “As a Type 1 diabetic, I rely on continuous glucose monitoring data to make adjustments to my insulin, and I rely on an insulin pump to manage delivery of that insulin in accordance to the adjustments I need. If I don’t continuously balance and rebalance those numbers, I will die. But as the rules stand today, I cannot connect those devices, I cannot automate routine adjustments, and I can’t even view all my data in one place because those devices will not work together. The American consumer deserves access to their own data. We deserve control of our own healthcare. Whatever cybersecurity options are discussed, it needs to be absolutely guaranteed that patients have total control over digital access, and not just the corporations who sell the devices.”
The FDA’s guidance proposes a total product lifecycle approach to device cybersecurity, recommending that security controls be baked into product design, addressed in premarket submissions, aligned with quality system regulations, and applied to older legacy equipment. The revised regulations would replace a 4-year-old document that updated FDA’s 2014 cybersecurity guidance.
The agency’s total lifecycle strategy aims to extend responsibility for software cybersecurity beyond specified departments to all divisions within a medtech organization. The guidance encourages device manufacturers to create and adopt a Secure Product Development Framework (SPDF), which the FDA describes as a set of processes that help reduce the number and severity of vulnerabilities throughout the product lifecycle. The guidance recommends that SPDFs encompass manufacturers’ risk management initiatives, security architecture for all devices, and cybersecurity testing details.
“The increasingly interconnected nature of medical devices has demonstrated the importance of addressing cybersecurity risks associated with device connectivity in device design because of the effects on safety and effectiveness. Cybersecurity risks that are introduced by threats directly to the medical device or to the larger medical device system can be reasonably controlled through using an SPDF,” the FDA guidance states. “The primary goal of using an SPDF is to manufacture and maintain safe and effective devices. The benefit of following an SPDF is that a device is more likely to be secure by design, such that the device is designed from the outset to be secure within its system and/or network of use.”
The SPDF is one of several notable changes included in the updated draft guidance. Another removes risk tiers (creating a process where documentation scales naturally with increasing cybersecurity risk) while a third adds Investigational Device Exemptions to the document’s overall scope. In addition, the guidance further clarifies the requirements for premarket submission documents.
One of the guidance’s key alterations, however, is the switch from a more comprehensive Cybersecurity Bill of Materials (CBOM) to a Software Bill of Materials (SBOM), which aligns the new directive with President Biden’s May 2021 executive order to bolster America’s cybersecurity posture. The FDA replaced the CBOM to alleviate some of the burden on device manufacturers, since most cybersecurity concerns lie within the software.
According to the guidance, the SBOM should provide various details of a product’s embedded software, including its name, version, manufacturer, level of support, end-of-support date, and any known vulnerabilities. The SBOM must be regularly updated to reflect any software changes, and it should support both 21 CFR 820.30 (Design History File) and 21 CFR 820.181 (Design Master Record) documentation.
Although industry representatives generally welcomed the addition of an SBOM, many were critical of its provisions. The Medical Device Manufacturers Association (MDMA), for instance, took issue with some terminology—specifically, the use of “any known vulnerabilities” and “end-of-support date.”
“We are concerned that ‘any known vulnerabilities’ may be overly burdensome [and] too broad...an improvement would be ‘Vulnerabilities that affect the product and represent a new or increased safety risk,’” MDMA president/CEO Mark B. Leahy wrote in a July 7 letter to the FDA. “Alternately, we recommend [the] item be removed entirely from the SBOM and instead FDA should rely on known defects to capture this information, recognizing that vulnerabilities will likely become out of date quickly and too much information could clutter the more important vulnerabilities. Additionally, the software component’s ‘end-of-support’ date is frequently unknown and can change due to acquisitions.”
Microsoft recommended that SBOMs be “top-down rather than bottom-up” and Connected Health Initiative suggested the SBOMs stay consistent with industry standards and the National Telecommunications and Information Administration specification of minimum SBOM elements.
Microsoft also advised the FDA to address the ways in which medical device manufacturers can use cloud services to conform to guidance expectations in multiple areas—including but not limited to security risk management, security architecture, cybersecurity testing, and cybersecurity transparency.
“The FDA correctly recognizes that medical device security is a shared responsibility among stakeholders throughout the use environment of the medical device system. The guidance, however, never explicitly identifies cloud service providers as potential key stakeholders despite [the] cloud’s explosive growth in recent years,” Kevin Reifsteck, director for Critical Infrastructure Protection, Customer Security and Trust, Corporate, External and Legal Affairs at Microsoft, wrote in a July 7 submission to the FDA. “Before issuing its final guidance, however, we recommend the FDA consider revising the document to explicitly address the use of cloud computing and incorporate more internationally recognized cybersecurity standards and best practices. We believe that making these revisions will strengthen medical device security, lower barriers to medical device innovation, and help reduce the cost of device development over the long-term.”
In the eight years since finalizing its first cybersecurity guidance, the FDA has progressively reinforced its efforts to fend off digital miscreants. It has developed an “internal playbook” to help agency staff address cybersecurity threats, signed memoranda of understanding with multiple stakeholders to create sharing analysis organizations, and last year, named its first-ever cybersecurity director.
Yet the threat persists, seemingly immune to any remedy the FDA or industry dishes out. The problem, in fact, appeared to snowball in 2022, with healthcare-related breaches spiking during the spring; Baxter International, BD, Fresenius Kabi, and Medtronic acknowledging security vulnerabilities in several of their products, and America’s second-largest hospital chain, CommonSpirit Health, falling victim to a massive ransomware attack.
Adding fuel to the growing conflagration was the Federal Bureau of Investigation’s (FBI) mid-September warning about the safety risks posed by unpatched and legacy medical devices. A notification from the FBI’s Cyber Division said the agency identified “an increasing number of vulnerabilities” from unpatched medical devices running on outdated software and products lacking adequate security features. The vulnerabilities exist in insulin pumps, intracardiac defibrillators, mobile cardiac telemetry, pacemakers, and intrathecal pain pumps. “Malign actors who compromise these devices can direct them to give inaccurate readings, administer drug overdoses, or otherwise endanger patient health,” the notification read.
In its warning, the FBI noted that 53% of connected medical devices and other Internet of Things (IoT) hospital equipment have known vulnerabilities. Moreover, roughly one-third of healthcare IoT devices have an identified critical risk, which could potentially implicate devices’ technical operation and functions.
To reduce the possibility of a cyberattack, the FBI recommends health systems take various steps to better identify vulnerabilities and actively secure medical devices. The steps include endpoint protection (antivirus software), identity and access management (changing default passwords), asset management (using inventory results to identify critical medical devices), vulnerability management (routine vulnerability scans), and training (teaching employees to identify and report possible threats).
“Medical devices have known vulnerabilities that impact various machines used for healthcare purposes...” the FBI notification warned. “Cyber threat actors exploiting medical device vulnerabilities adversely impact healthcare facilities’ operational functions, patient safety, data confidentiality, and data integrity.”
And that’s just the tip of the iceberg.
Doctors in January diagnosed son Gavin with type 1 diabetes, a chronic condition that robs the pancreas of its insulin-making ability. Such a life-altering prognosis can be unsettling, worrisome, and even a bit frightening for those afflicted, especially children, who may be confused by their body’s betrayal.
Confusion was just one of the emotions coursing through the Spoth household after Gavin’s diagnosis. Despondency, anxiety, and astoundment were present too while the boy and his family gradually forged a treatment strategy based on the latest blood glucose measuring/monitoring technology.
Those feelings, however, eventually gave way to anger and frustration over (perceived) subpar diabetes management software and patient data security risks. “One thing that is abundantly clear over our first few months post-diagnosis is that, while the medical technology is for the most part wonderful and works the overwhelming majority of the time, the software behind that technology is highly lacking,” Eric Spoth told the U.S. Food and Drug Administration (FDA) in written testimony this past summer. “Integration with existing operating systems and devices is shoddy at best, if attempts are made by the companies at all. While the systems themselves are seemingly stable, we quickly realized we needed better integration with hardware than these companies provide.”
In his testimony, Spoth lauded the benefits of third-party software, noting these systems are easily integrated with current smart devices and thus allow for continuous blood glucose monitoring. Limiting access to these systems, he warned, will restrict consumer choice and potentially create software tech monopolies. He also advised against prohibiting diabetes patients from accessing their personal data.
“I am conscious of the cybersecurity concerns here, but there really should be a middle ground for those who use these systems not for administering insulin, but for collecting readings as part of an entire approach to care,” Spoth testified. “These systems are often better than these companies can offer and a lot of people rely on them so please I beg you try to be light-handed with your regulations.”
Spoth’s testimony was among the deluge of feedback the FDA received after releasing an updated medical device cybersecurity draft guidance in April. Most comments (1,870 total) came from diabetes patients and/or their caregivers concerned the revised regulations would considerably limit their ability to access their medical devices and (blood glucose) data.
“Do not lock patients out of their own medical data, or out of control of their own medical devices. That should be of paramount importance in every cybersecurity policy—companies cannot be allowed to hold patients hostage by holding vital data and treatment options in walled gardens where the company’s rules are more important than the patient’s health,” William Ray wrote in his comments to the FDA. “As a Type 1 diabetic, I rely on continuous glucose monitoring data to make adjustments to my insulin, and I rely on an insulin pump to manage delivery of that insulin in accordance to the adjustments I need. If I don’t continuously balance and rebalance those numbers, I will die. But as the rules stand today, I cannot connect those devices, I cannot automate routine adjustments, and I can’t even view all my data in one place because those devices will not work together. The American consumer deserves access to their own data. We deserve control of our own healthcare. Whatever cybersecurity options are discussed, it needs to be absolutely guaranteed that patients have total control over digital access, and not just the corporations who sell the devices.”
The FDA’s guidance proposes a total product lifecycle approach to device cybersecurity, recommending that security controls be baked into product design, addressed in premarket submissions, aligned with quality system regulations, and applied to older legacy equipment. The revised regulations would replace a 4-year-old document that updated FDA’s 2014 cybersecurity guidance.
The agency’s total lifecycle strategy aims to extend responsibility for software cybersecurity beyond specified departments to all divisions within a medtech organization. The guidance encourages device manufacturers to create and adopt a Secure Product Development Framework (SPDF), which the FDA describes as a set of processes that help reduce the number and severity of vulnerabilities throughout the product lifecycle. The guidance recommends that SPDFs encompass manufacturers’ risk management initiatives, security architecture for all devices, and cybersecurity testing details.
“The increasingly interconnected nature of medical devices has demonstrated the importance of addressing cybersecurity risks associated with device connectivity in device design because of the effects on safety and effectiveness. Cybersecurity risks that are introduced by threats directly to the medical device or to the larger medical device system can be reasonably controlled through using an SPDF,” the FDA guidance states. “The primary goal of using an SPDF is to manufacture and maintain safe and effective devices. The benefit of following an SPDF is that a device is more likely to be secure by design, such that the device is designed from the outset to be secure within its system and/or network of use.”
The SPDF is one of several notable changes included in the updated draft guidance. Another removes risk tiers (creating a process where documentation scales naturally with increasing cybersecurity risk) while a third adds Investigational Device Exemptions to the document’s overall scope. In addition, the guidance further clarifies the requirements for premarket submission documents.
One of the guidance’s key alterations, however, is the switch from a more comprehensive Cybersecurity Bill of Materials (CBOM) to a Software Bill of Materials (SBOM), which aligns the new directive with President Biden’s May 2021 executive order to bolster America’s cybersecurity posture. The FDA replaced the CBOM to alleviate some of the burden on device manufacturers, since most cybersecurity concerns lie within the software.
According to the guidance, the SBOM should provide various details of a product’s embedded software, including its name, version, manufacturer, level of support, end-of-support date, and any known vulnerabilities. The SBOM must be regularly updated to reflect any software changes, and it should support both 21 CFR 820.30 (Design History File) and 21 CFR 820.181 (Design Master Record) documentation.
Although industry representatives generally welcomed the addition of an SBOM, many were critical of its provisions. The Medical Device Manufacturers Association (MDMA), for instance, took issue with some terminology—specifically, the use of “any known vulnerabilities” and “end-of-support date.”
“We are concerned that ‘any known vulnerabilities’ may be overly burdensome [and] too broad...an improvement would be ‘Vulnerabilities that affect the product and represent a new or increased safety risk,’” MDMA president/CEO Mark B. Leahy wrote in a July 7 letter to the FDA. “Alternately, we recommend [the] item be removed entirely from the SBOM and instead FDA should rely on known defects to capture this information, recognizing that vulnerabilities will likely become out of date quickly and too much information could clutter the more important vulnerabilities. Additionally, the software component’s ‘end-of-support’ date is frequently unknown and can change due to acquisitions.”
Microsoft recommended that SBOMs be “top-down rather than bottom-up” and Connected Health Initiative suggested the SBOMs stay consistent with industry standards and the National Telecommunications and Information Administration specification of minimum SBOM elements.
Microsoft also advised the FDA to address the ways in which medical device manufacturers can use cloud services to conform to guidance expectations in multiple areas—including but not limited to security risk management, security architecture, cybersecurity testing, and cybersecurity transparency.
“The FDA correctly recognizes that medical device security is a shared responsibility among stakeholders throughout the use environment of the medical device system. The guidance, however, never explicitly identifies cloud service providers as potential key stakeholders despite [the] cloud’s explosive growth in recent years,” Kevin Reifsteck, director for Critical Infrastructure Protection, Customer Security and Trust, Corporate, External and Legal Affairs at Microsoft, wrote in a July 7 submission to the FDA. “Before issuing its final guidance, however, we recommend the FDA consider revising the document to explicitly address the use of cloud computing and incorporate more internationally recognized cybersecurity standards and best practices. We believe that making these revisions will strengthen medical device security, lower barriers to medical device innovation, and help reduce the cost of device development over the long-term.”
In the eight years since finalizing its first cybersecurity guidance, the FDA has progressively reinforced its efforts to fend off digital miscreants. It has developed an “internal playbook” to help agency staff address cybersecurity threats, signed memoranda of understanding with multiple stakeholders to create sharing analysis organizations, and last year, named its first-ever cybersecurity director.
Yet the threat persists, seemingly immune to any remedy the FDA or industry dishes out. The problem, in fact, appeared to snowball in 2022, with healthcare-related breaches spiking during the spring; Baxter International, BD, Fresenius Kabi, and Medtronic acknowledging security vulnerabilities in several of their products, and America’s second-largest hospital chain, CommonSpirit Health, falling victim to a massive ransomware attack.
Adding fuel to the growing conflagration was the Federal Bureau of Investigation’s (FBI) mid-September warning about the safety risks posed by unpatched and legacy medical devices. A notification from the FBI’s Cyber Division said the agency identified “an increasing number of vulnerabilities” from unpatched medical devices running on outdated software and products lacking adequate security features. The vulnerabilities exist in insulin pumps, intracardiac defibrillators, mobile cardiac telemetry, pacemakers, and intrathecal pain pumps. “Malign actors who compromise these devices can direct them to give inaccurate readings, administer drug overdoses, or otherwise endanger patient health,” the notification read.
In its warning, the FBI noted that 53% of connected medical devices and other Internet of Things (IoT) hospital equipment have known vulnerabilities. Moreover, roughly one-third of healthcare IoT devices have an identified critical risk, which could potentially implicate devices’ technical operation and functions.
To reduce the possibility of a cyberattack, the FBI recommends health systems take various steps to better identify vulnerabilities and actively secure medical devices. The steps include endpoint protection (antivirus software), identity and access management (changing default passwords), asset management (using inventory results to identify critical medical devices), vulnerability management (routine vulnerability scans), and training (teaching employees to identify and report possible threats).
“Medical devices have known vulnerabilities that impact various machines used for healthcare purposes...” the FBI notification warned. “Cyber threat actors exploiting medical device vulnerabilities adversely impact healthcare facilities’ operational functions, patient safety, data confidentiality, and data integrity.”
And that’s just the tip of the iceberg.