The FDA’s cybersecurity bill of materials has major implications – both good and bad – for healthcare provider organizations’ IT and security teams.
While it may seem like a no-brainer to allow manufacturers access to update their own firmware in medical devices to improve cybersecurity, opening the door to devices introduces a conflicting set of challenges.
The draft bill of materials guidance is aimed at having manufacturers disclose other vendors’ software they may be using in addition to their own software/firmware. The intent is to give the IT security staff more context on the device software.
(On a related note, the FDA has issued a safety communication – aimed at healthcare organizations, IT professionals, device manufacturers and patients – warning of the cybersecurity vulnerabilities known as URGENT/11. The risk, FDA officials said in the communication, is that URGENT/11, if exploited by a remote attacker, could pose safety and security risks for connected medical devices and hospital networks.)
Setting up risk mitigation controls
The draft bill of materials will help provide end users relevant information around vulnerabilities and tip them off that it may take a few weeks for a patch to be issued. It will allow end users to set up risk mitigation controls on these devices until the vendor can provide a patch.
“However, organizations are often unaware that the software/firmware they are purchasing has software or code from another manufacturer,” said Wayne Dorris, business development manager for cybersecurity at Axis Communications, a security technology vendor. “For example, at Axis Communications, we use Linux as an operating system for most of our devices. If a Linux vulnerability impacts Axis, our job is to issue a patch as a firmware update.”
“CIOs and CISOs need to be open to segmenting these devices from a different approach.”
Wayne Dorris, Axis Communications
Linux is responsible for reporting that vulnerability to the Common Vulnerabilities and Exposure (CVE) report. The issue then becomes that Axis users aren’t necessarily aware of vulnerabilities in Linux software because it either doesn’t affect the product they are using or they haven’t checked Linux’s CVE report.
This bill is shining a light on that blind spot and encouraging users to pay attention to the CVEs from a product manufacturer perspective as well as its software vendors, Dorris said.
Some major IT challenges
“Yet, the bill has posed some major IT challenges specific to the medical industry,” he noted. “The bill requires that the manufacturer disclose all the software partners involved in medical devices when the device application is submitted to the FDA for approval. But the long FDA approval process often results in devices or solutions being dropped for better options, rendering the early disclosure of software partners useless.”
Challenges also arise since the manufacturer responsible for updating firmware/software for a device is not always physically present at each hospital they work with. Because of this, updating is handled remotely, possibly opening a door for an attacker.
The bill, while seemingly positive for the cyber health of a device, actually creates more opportunity for a cyber breach, Dorris explained. CIOs and CISOs will need to shift their cybersecurity approach to maintain a secure network, while still opening the virtual door to manufacturers to make the relevant updates, he advised.
“Past approaches, such as CA certificates and VPNs, are functional, but not at the scale of network medical devices in the hospital and can be costly from an implementation and maintenance standpoint,” he said. “IT security departments are already understaffed and overwhelmed with their current workload, which poses the question, ‘Who will keep up the Access Control List and manage the revoke and expiration list on the CA Certificates?’”
New approaches may be needed
CIOs and CISOs should try new approaches like Zero Trust Networks, Layer 2 over Layer 3 encryption, and hardware root of trust to address a problem at this scale, he advised.
The biggest concern with listing software dependencies is the competition in the medical device manufacturing community, Dorris cautioned.
“There is a lot of sensitivity around software partner disclosures early in the process for fear a competitor may choose the same vendor or buyout the vendor to make their own device more viable,” he said. “A better option would be for the disclosure to come after the approval – or directly to the end customers purchasing the device.”
Since manufacturers will need remote access of each device, it opens new entry points for cyberattacks. This would be as if someone locked up a building but left all the windows open. After all, the more entry points available, the more likely an organization will experience threats. It will take a lot of planning to secure each connection and circumvent attackers from getting their hands-on patient data.
A different approach to segmenting
“CIOs and CISOs need to be open to segmenting these devices from a different approach,” Dorris advised. “To avoid unwanted breaches, sealing devices in their own cryptographic tunnel may be necessary. Network security vendors with their own unique hardware root of trust, zero trust networks, and layer 2 over layer 3 encryption capabilities can be a solution.”
Overall, the way vulnerabilities are managed will need to change. Many organizations are in Common Vulnerabilities and Exposure overload and just focus on the critical and major vulnerabilities that come up on a scan, Dorris explained. Whereas, threat intelligence can help provide context and threat hunting can provide additional benefits, he concluded.
Twitter: @SiwickiHealthIT
Email the writer: [email protected]
Healthcare IT News is a HIMSS Media publication.
Source: Read Full Article