Today, the Cloud Security Alliance has published the "Cloud Security Alliance Medical Device Incident Response Playbook." The playbook is written by Christopher Frenz, assistant vice president of IT security at Mount Sinai South Nassau in New York, and Brian Russell, head of the Cloud Security Alliance's Internet of Things working group.

The playbook details medical device incident-response best practices according to the various levels of clinical impact that could be incurred if a device is removed from the patient and/or network. The guidance is designed for hospital and health system CISOs, CIOs, and other health IT and cybersecurity leaders.

Prior to publication of the playbook, Healthcare IT News sat down with coauthor Frenz to get a preview of the security publication and talk about medical device security.

Q. The playbook discusses more than just the response process, it also discusses how healthcare organizations can prepare the team, gather tools, assign responsibilities and more, in preparation for an incident response. Please elaborate on these elements of the playbook.

A. Preparation for an incident is a key part of incident response and something that every organization needs to focus on. When dealing with a cybersecurity incident, your ability to detect and contain the incident in a timely manner are going to be major factors in determining how damaging the incident is to organizational operations.

Having an incident response plan is an important step, but organizations also need to ensure they have all of the proper resources required to effectively carry out that plan. It's nice to say, on paper, that you will detect the incident or isolate a device on the network, but if those are key steps in your plan, it is also imperative that you have the technology in place to actually perform those steps and that staff are properly trained to perform those steps.

One of the critical issues facing healthcare security today is that many hospitals still lack security staff and resources, which will negatively impact their ability to respond to a cyberattack. The guidance created seeks not only to lay out a representative process that organizations can use as a starting point to develop their own medical device incident response plans, but tries to lay out the minimum resources that hospitals will require in order to successfully carry out an effective medical device incident response.

It also is critical that organizations seeking to be prepared remember that having a plan is one thing, but that taking the time to actually test the plan also is a critical preparedness step. Conducting tabletop exercises or simulations of an incident [is a great way] of ensuring the plan adequately addresses all needed steps – and that there are no deficiencies in tools or staff training that will result in the failure of the response plan.

It's also a great way to periodically check that the processes and all dependencies are working perfectly. You don't want to wait for a ransomware attack to happen to discover the data you were religiously backing up can't be restored because the backup tapes you were using had gone bad, or because of some other unexpected issue that was going on undetected. Testing helps to expose those issues.

Q. I understand you have tried to tie incident response back with the device acquisition process, as well, meaning gathering data regarding the device and its operational context, so that the data is available to the appropriate incident-response personnel when it's needed. Why is this important?

A. Having a security review be part of the acquisition process is a well-established security best practice and one that is of growing importance to the healthcare industry. I am a big proponent of hospitals requesting MDS2 sheets and SBOMs as a part of their security review process as a security assessment should work to identify the various controls a device supports, best practices for securely deploying the device, and the software components that make up the device, among other factors.

The more you know about the various devices on your network, the better your ability to design an effective control set for defending those devices. Moreover, in an incident response process, having an up-to-date asset inventory with this information will prove invaluable.

For example, if a threat is found on our network that impacts an infusion pump via a vulnerability in a particular version of a software component used by that pump, a common incident response process would likely include putting additional protections around other vulnerable devices or checking other vulnerable devices for signs of compromise.

While vendor make and model similarities may be one way of achieving this, relying on this type of approach alone may not provide a complete picture of the scope and scale of the issue. The make and model approach may get us to perform IR on all similar infusion pumps, but could easily leave us blind to the fact that we have a CT machine and a set of respirators that also use the same software component and are also targets for potential compromise. The more knowledge you have about the devices on your network, the more comprehensive and robust your incident response will be.

Considering security as part of the acquisition process is also important because it allows for discussions and the introduction of contractual language around ongoing vendor support. Healthcare organizations can and should factor in decisions like patch-support timelines, vendor ability and willingness to assist in device forensics, willingness to disclose vulnerabilities, ability to install endpoint security tools, and other factors into their purchasing decisions.

Q. You have said that medical device incident response is not a one-size-fits-all process and different incident response processes for different medical devices pose different patient-safety issues. What must healthcare provider organization CISOs and CIOs know here?

A. One of the key focuses of the guidance is that it does not treat all medical devices as equal and acknowledges that medical devices play various roles in patient care. The guidance considers the patient safety and clinical-workflow impacts of disconnecting the device from the network – and the impacts of disconnecting the device from the patient – and uses that as the basis of a tiered approach to medical device incident response.

For example, a wireless blood pressure cuff likely presents no issues if it is removed from the patient or the network, and pulling the device off the network and swapping it out may be an appropriate response. The same cannot be said for the central station in a telemetry-monitoring setup whereby pulling the device offline will require possible changes to nursing workflows and nursing staffing levels.

Likewise, implantable devices may not easily be disconnected from a patient without introducing a patient safety risk. The guidance seeks to get healthcare organizations thinking about the different clinical impacts posed by disconnecting various classes of devices from both networks and patients – and provides guidance on how IR workflows can be modified to minimize the risk posed to patients.

The guidance also highlights the need for clinical leadership and not just the security team to play a role in the incident response process. Cybersecurity is a key component of maintaining patient safety, and organizations need to ensure that any incident response they perform does not adversely impact patient care.

Q. Your playbook guidance tries to highlight that, in a healthcare environment, patient safety and cybersecurity are increasingly interrelated, and that cybersecurity decisions can have a direct impact on patient safety. What is the goal of your guidance here? Routine testing is a great way to make plan improvements, test the requisite technology, improve response times, and ensure that staff can successfully recall how to properly perform actions they may not otherwise perform on a routine basis.

A. Cybersecurity is a key component of patient safety in a modern hospital. If we look at all of the ransomware attacks that have hit hospitals and brought down clinical systems it becomes easy to imagine all of the delays to patient care that this can contribute to. Anything that can cause a delay in patient care has the potential to contribute to an adverse patient outcome.

This means that, as cybersecurity professionals, we need to begin to make clinically informed decisions about how we allocate control resources and about what we put our emphasis on protecting. We should be ensuring that the devices and systems that would have the greatest impact on patient care and clinical workflows, if they were to become unavailable, are the systems that we prioritize in protecting.

Likewise, as illustrated by the tiered risk approach to medical device incident response laid out in the guidance, patient safety and clinical workflow impacts need to be factored into the healthcare incident response process. You can't go and unplug someone's respirator – malware infected or not – without having a plan for dealing with the patient care issues that will cause.

While that example may be a bit on the extreme side, it clearly illustrates that during healthcare incident response, patient safety issues and cybersecurity issues can easily become intertwined and that security and clinical leaderships need to be partners in the process. Healthcare cybersecurity can no longer be viewed as just an IT problem.

Twitter: @SiwickiHealthIT
Email the writer: bsiwicki@himss.org
Healthcare IT News is a HIMSS Media publication.