nexus_clinical-eng-p2.jpg
Cyber Resilience
Healthcare

Managing Clinical Engineering Supply Chain Risk, Part 2

Adam Zoller
/
Nov 8, 2023

This is part 2 of Providence CISO Adam Zoller's series on managing the cybersecurity of clinical engineering third-party relationships. Read part 1 here.

In part 2 of this two-part series, I wrote about the foundational practices you should be familiar with when it comes to managing clinical engineering and third-party relationships. We’ve found success foremost after bringing clinical engineering under our IT organization. This goes a long way toward aligning vendors with your cybersecurity goals versus in situations where biomedical device engineering is aligned to organizations outside IT, or directly to an individual hospital.

Cybersecurity must also be part and parcel of procurement processes, and security language must be prominent in Master Service Agreements with third-party vendors, as well as in Business Associate Agreements, which are specific to healthcare organizations. By setting the expectations, for your teams and external parties that cybersecurity is integral to purchasing decisions, you can enforce security standards at the point of maximum leverage. 

Our job as security leaders in healthcare—any industry, really—is ultimately to enable the business to operate safely and securely, and ensure patient safety is never compromised. As more of us are connecting our businesses and processes online, complete confidence in supply chain relationships is paramount. This means we must understand every facet of these relationships and the risk they may introduce. 

In part 2, we will cover some of the technical resources—and human capabilities—required to ensure security leaders oversee healthy device and process ecosystems.


Take the Long View of a Supplier’s Standing

Many healthcare devices are designed to be in your IT ecosystem for 10-to-20 years. Sometimes these companies are acquired or go out of business—along with the support needed to keep the devices updated and secure. 

One potential option is to include a software escrow requiring the vendor to escrow their source code for the device so you can access it if they do end up going defunct. 

So during the purchasing process it is important to look at the vendor’s history and future financial prospects to ensure they are stable. One potential option is to include a software escrow requiring the vendor to escrow their source code for the device so you can access it if they do end up going defunct. 

Don’t Depend on Vendor Remote Access Solutions

Many vendors need to manage their devices within our ecosystem and require a secure connection to remote into our environment. Rather than just using their VPN solution, we have developed our own solution that is configured to our security specifications. We’ve also actively decommissioned more than 1,000 VPN tunnels over the past two years–tunnels that were implemented with the best of intentions but no longer meet our security requirements. 

Regularly Assess Device, Application Risks

Even after you have worked with a vendor and implemented a new device or application, it is important to regularly reassess them. These risk reassessments, particularly when there are contract modifications or material changes to the functionality/connectivity of a device or application, allow your cybersecurity team to ensure new risks are not being created in your IT environment.

Beyond material changes, it is a good policy to periodically reassess your vendors, devices, and applications. This can be conducted annually or biannually, and you’ll most likely need to prioritize based on potential risks and your resources. These reassessments allow you to catch items that may have been missed initially or additional security risks that may have been inherited into your environment by decisions made after that initial contract was signed.

Implement Technical Controls

You can have all the right policies in place, but sometimes things slip through the cracks. Therefore, it is important to have technical controls in place to give you visibility to all devices within your network so you can be aware of new capabilities deployed into your environment. As part of these controls, you also want to be able to limit who can access or deploy devices and applications. 

Furthermore, you should always have a plan for any IoT device connecting to your network that is not managed directly by your organization. You should fingerprint that device, either directly or through network traffic analysis, and then have in place the capability to virtually isolate it through network access, control technology, or automated access control lists.

Make it a Team Effort

It is also important to create a culture of security throughout your organization, so everyone knows not only what to do when they see a phishing email but also knows the procurement security process for onboarding a new device. 

One bonus of this is that at large organizations the process may reveal a previously approved solution—another hospital or facility may have already gone through the security review process for a similar device, saving time in getting the needed capability, reducing your risks, and potentially giving your organization improved bargaining power with the vendor. 

Conclusion

Healthcare organizations often rely heavily on vendors, suppliers, and other third-party service providers. However, they can also potentially introduce security risks into an environment. By being intentional and process-oriented using the tips above, healthcare cybersecurity leaders can lessen these threats while still allowing clinicians to deliver great patient care. 

Cyber Resilience
Healthcare
Adam Zoller
Chief Information Security Officer

Adam Zoller is the Chief Information Security Officer for Providence, a national, not-for-profit healthcare system with more than 50 hospitals, 1,000 clinics, and locally driven programs administered by more than 120,000 caregivers.

Stay in the know Get the Nexus Connect Newsletter
You might also like… Read more
Latest on Nexus Podcast