The U.S. Food and Drug Administration (FDA) has, for the second time in two years, issued recommendations to improve the security of connected medical devices. Not mandates – recommendations.
Which immediately raises the question: Will anything that is non-binding put enough pressure on manufacturers to spend the time and money it will take to improve device security?
That, as is frequently said, remains to be seen.
The FDA issued what it called “guidance” on the “postmarket management of cybersecurity for medical devices,” at the end of last year.
This follows “premarket” guidance that the agency issued two years earlier.
And while there is no legal requirement to implement them, some experts say they will still have the power to force change, noting that just because they are not mandates doesn’t mean they can’t have significant legal impact. All it would take to confirm that is to talk with a lawyer about the implications of “best-practice” recommendations in a lawsuit over harm to a patient from a device that was hacked because of poor security.
But then, there is Bruce Schneier, CTO of Resilient Systems and a privacy and encryption expert, who wondered in a blog post shortly after the postmarket guidance was published what was the point.
Schneier, who has called for government regulation of the entire Internet of Things (IoT) industry, wrote of the guidelines that there was, “nothing particularly new or interesting; it reads like standard security advice: write secure software, patch bugs, and so on. Note that these are ‘non-binding recommendations,’ so I'm really not sure why they bothered.”
But that got some immediate blowback in his reader comment section. “Doug,” said he had been in the device industry for 30 years, and that while the law regulating medical devices would not change, “the interpretation and enforcement will.
“By knowing what the FDA is thinking, we can adapt our design, validation, and manufacturing efforts to meet these expectations. Guidance documents drive much of what we do,” he wrote.
The agency itself, in a statement to CSO, said the guidance, while nonbinding, is an interpretation of regulations, which are binding. It said the failure to follow the agency's Quality Systems Regulation (QSR) “adulterates” devices, and can result in their “seizure or injunction.”
Several experts agreed that the guidance is worthwhile, and should push manufacturers in the right direction. But none of them thinks that it is time, or will soon be time, for users of such devices to relax. Obviously the stakes are high – a hack of an implantable or other connected device can cause much more harm than the theft of data or identity. It could kill.
And that risk, while there are no reports yet of deaths caused by it, is real. Medical devices have been rigorously designed to work properly for years. But most have not been designed with cybersecurity in mind, and many of them remain insecure to the point of potential catastrophe, as an audit of a heath organization showed in 2014 – things like, “lack of authentication …; weak passwords or default and hardcoded vendor passwords like ‘admin’ or ‘1234’; and embedded web servers and administrative interfaces that make it easy to identify and manipulate devices once an attacker finds them on a network.”
Andrew Ostashen, cofounder and principle security engineer at Vulsec, said he was at a hospital when a neonatal system, “went offline from discovery scan through an assessment due to the fact the organization was not aware where the device was configured in the network.”
That, he said, meant that hackers would be able to take the same system offline if they got inside the organization. In this case, “luckily the device was not in use at the time of the assessment. Otherwise, this could have been catastrophic,” he said.
And while physical harm to patients is clearly the most crucial risk to mitigate, there is also the risk of attackers hijacking a device in order to get inside a healthcare organization’s network.
TrapX Labs, a cybersecurity defense vendor, in a breach report at the end of last year, said hijacked medical devices are being used as a back door to hospital networks.
“Unfortunately, hospitals do not seem to be able to detect MEDJACK or remediate it,” said Moshe Ben-Simon, cofounder and vice president of services in a press release.
So, how far will the recent FDA guidance move the security needle? It wouldn’t have to move much to make a difference.
As Schneier noted, the new guidance does not break major new ground. It covers what most experts call good risk management and security “hygiene.” The FDA said in its statement that its recommendations are “encompassed" by the QSR, and which include requirements for for handling complaints, audit standards, corrective and preventive action, software validation and risk analysis and servicing.
The agency also calls for manufacturers to, “apply the NIST (National Institute of Standards and Technology) voluntary cybersecurity framework, which includes the core principles of ‘Identify, Protect, Detect, Respond and Recover.’”
But the overall focus, which calls for manufacturers to maintain the security of devices throughout their entire life cycle is significant since, as has been widely reported, those devices tend to have a development cycle of five years or more, and then useful lives of 10 to 20 years.
So following the recommendation obviously means designing in from the start the capability to patch and update vulnerabilities throughout the life cycle.
The FDA also addresses what has been one complaint of manufacturers – some critics call it an excuse – that if they update a device, they have to go through a certification process again.
The new guidance makes it clear that routine patches and updates don’t need to be reported or reviewed by the FDA. Vulnerabilities don’t need to be reported unless they cause deaths or other adverse events, or can’t be patched within 60 days. Manufacturers are, however, required to notify users, make changes that lower risk and to be a member of an ISAO, to which they must report the vulnerability and what they did to fix it.
Ted Harrington, executive partner at Independent Security Evaluators, noted that the long development cycle of such devices is primarily focused on performance and safety of their mechanical elements, not the software.
“The software itself can and should be evolved throughout the approval process, and must have an update mechanism to account for the evolutions in attack techniques, discovery of previously unknown flaws in operating systems and communication protocols, and other performance enhancements,” he said.
Of course, even a routine security update process needs security built in. Stephanie Domas, lead medical security engineer at Batelle DeviceSecure Services, said, “updating mechanisms by their nature take in new code, in some format, and save it to the device to execute. This makes them enticing targets for malicious actors – there have been several occasions where software updaters were hijacked for nefarious purposes.”
The FDA also recommended that all stakeholders in the industry join Information Sharing Analysis Organizations (ISAO) to promote the sharing of threat information within the private sector and with government as well.
It said ISAOs, with adequate privacy provisions in place, can help, “detect, mitigate or recover from the effects of cyber threats …”
That last item drew some criticism from Dr. Kevin Fu, CEO of Virta Labs and an associate professor at the University of Michigan, who recommended “caution and skepticism” regarding ISAOs in a letter last April on a draft of the guidelines.
“The sharing of data is not useful if the data are not high quality,” he wrote, citing one case where a report of a vulnerability in one server prompted a hospital to use an even less secure server.
Regarding the overall concept of government involvement in setting security standards for medical devices, there is some debate. Shawn Merdinger, an independent security researcher, said the market can be a more potent force for improving security than government regulation.
He pointed to the move last fall by short-seller investment firm Muddy Waters to publicize research by MedSec Holdings that found flaws in pacemakers and defibrillators made by St. Jude Medical Inc., which drove the company’s stock price down.
That collaboration was sharply criticized in some of the IT media, and St. Jude sued both Muddy Waters and MedSec, but Merdinger noted that, “the bottom line at this point appears to be that St. Jude is issuing patches, ICS-CERT is issuing advisories, and nobody has been arrested or otherwise shut down on the business side.”
The point, he said, is that if the stock price of a company is threatened, “that means executive bonuses and shareholder value is impacted. Once you start taking away peoples' boat payments, it's a whole new ballgame.”
And Harrington said he is not a fan of government regulation in cyber security for several reasons. “It takes too long to develop, is outdated by the time it becomes enacted, is too riddled with compromise and it attempts to apply a uniform security model to organizations that are innovating and thus by definition are not uniform,” he said.
But, he does not think the FDA’s guidance is useless. He said it can, “help align the various stakeholders – from device manufacturers, hospitals, patients, and the government – as to what is important. It provides a common language around which the discussion of security can be centered.”
Ostashen said government should play a role – a more aggressive role. “The FDA must set up regulations as strict as those for HIPAA (Health Information Portability Accountability Act, which mandates the protection of personal health information),” he said, adding that he sees cyber liability insurers refusing to pay for damages if they believe an organization was negligent for not following best practices.
“Medical device manufacturers need to be held accountable for being negligent,” he said. “Yes, the development of these devices can take five years, but secure architecture and development must be a conscious thought at the inception of the product.”
Overall, Domas said she applauds the FDA for, “taking the issue of security in medical devices seriously.” She noted that the agency has been heavily involved in medical conferences and guidance working groups.
“They have been soliciting feedback and buy in from the whole medical ecosystem, including medical manufacturers, hospitals, and security researchers,” she said.
Harrington said while it will be a long time before, “end users can be fully relaxed and confident in the security posture of medical devices, I am optimistic that this will improve over time.”
And the FDA said, “we are starting to see a change in mindset among all stakeholders–manufacturers are realizing the importance of implementing comprehensive cybersecurity controls throughout a product’s lifespan.”