How to go about managing the vulnerabilities in your environment
Knowing something is out there is one thing; doing something about it is something entirely different. As we’ve mentioned in previous blogs (e.g., “Taking Your Risk Management to New Heights,” and “Accurately Assessing Device Risks”), figuring out what the risks are within your environment is no simple task. The myriad of proprietary operating systems, protocols, and workflows used by all the medical and IoMT devices found only in clinical networks presents a number of challenges to any healthcare delivery organization trying to protect the integrity and availability of their operations and patient care. But, assuming, you have a platform, such as Medigate, that can marry relevant cybersecurity and healthcare expertise to understand where the risks exist in your environment, you then need to figure out what you want to do about them.
Reminder That All Risk is Relative
Every organization accepts some level of risk. The key is figuring out what is acceptable and what is not. This requires bringing together your cybersecurity, IT/network, biomed/clinical engineering, and business teams to agree on what is necessary and what is not within the environment (a.k.a. what you can live with, and what you cannot). The goal is to create a framework that lays out how you want to manage the vulnerabilities and threats discovered in the network.
It is important to note that what may be considered a risk in a typical IT network, may be deemed acceptable in a clinical network, particularly if the device is relied upon to deliver care. For example, most companies don’t allow devices with unsupported operating systems (OSes) to connect to their general IT networks. Period. But HDOs may make any number of exceptions to this rule, based on the criticality, capital expense, and non-trivial nature of replacing the medical device in question (e.g., CAT scanners, MRIs, robot surgical machines, etc.).
Managing Vulnerabilities in Medical Devices Takes Special Consideration
Because of the unique nature of clinical settings, it is highly likely that the appropriate response for some risks is to do nothing at all, at least for now. For example, a new, low-level vulnerability within the console of one of your MRI machines, which is isolated on its own network and only accessed by a handful of practitioners, may be deemed acceptable and relegated to being addressed when the machine goes through its regular maintenance.
For others risks, a more rapid response and immediate remediation may be called for. For example, if a manufacturer issues a critical alert (and patch) on a device that could impact your ability to deliver high quality care, you will probably escalate the urgency of applying the fix. The point is, that different risks, based on their criticality, will require different responses.
As long as your management of those risks is agreed upon, documented, and followed, you should be able to maintain risks as an acceptable level in your environment. The key is to be able to:
Efficiently map the risk (vulnerability) across your inventory to pinpoint all the devices that are potentially affected. This takes the real-time granular visibility we talk so much about, which is capable of providing insights into the make, model, OSes, protocols, embedded software, etc. of every device.
Determine when it is safe to apply the update/patch. This takes the ability to monitor the ongoing connectivity of devices to identify when the device is not in use or not connected to anything that could impact the delivery of care. (Note, this can also help with figuring out when it is safe to scan for vulnerabilities in the first place – for more on this, you can check out how we are working with Rapid7 to manage vulnerabilities.)
Identify who will apply the update/patch. This takes identifying and coordinating with the organizational owners of the impacted devices, who are often the ones that will need to take responsibility for addressing the risks. Sometimes this will include working with the manufacturer of the device to ensure it can be safely applied (without affecting operations or voiding the warranty).
Quickly locate each and every device so that when it is time to apply the fix, no one is wasting valuable time roaming the halls trying to find the devices. This takes being able to tie a device to a specific location, for example via the VLAN they are connecting to, or even through RFID technology.
Mitigation is Another Matter
Sometimes the best way to manage risk, particularly if the root cause cannot be addressed (e.g., a patch isn’t available or can’t be applied, or a protocol can’t be banned from being used), is to take steps to minimize the impact a successful exploit could have on the organization. The problem with health systems, is that mitigating steps can’t be taken just anywhere.
No one wants to do something that ends up doing more harm than good, but that’s a very real possibility within clinical networks. As a result, when building out a mitigation strategy, healthcare delivery organizations must look at all the compensating controls at their disposal and choose the best ones for each scenario. The controls can range from air-gapping and segmenting to quarantining and blocking, depending on the criticality of the device and the severity of the threat. The goal is to address vulnerabilities and reduce risks throughout the environment, in a way that enables, versus interferes with or disrupts, the organization’s care and operations.
For more information on how to create a comprehensive vulnerability management strategy that helps you maintain a stance that aligns with your tolerance for risk, please check out our white paper and this Rapid7 integration document.
