Five Phases to Clinical Zero Trust: A Deeper Dive into Phase Four and Five

Part 4 of a 4 Part Blog Series

This blog concludes our series on how to start to think about and implement a successful Clinical Zero Trust (CZT) strategy. We will cover the easy and hard components of phase four and five – Monitor and Automate – of an organization’s journey to establish and maintain an effective CZT stance.

To recap, the first blog defined CZT and outlined the five phases organizations typically embark on when trying to create and implement CZT in their clinical setting. The second blog covered what is involved in the Identify and Map phases, while the third blog covered the Engineer phase. So, let’s take a look at these last two phases of a CZT lifecycle.

Phase 4: Monitor

What We’re Trying to Accomplish in the Monitor Stage

The last thing anyone wants to do in a clinical setting is introduce security that interrupts or creates a point of failure that adversely affects the delivery of care. The reality is that despite all your best efforts at Identifying, Mapping, and Engineering the network (Phase 1, 2, and 3, respectively) to create and optimize an effective CZT stance, you may have missed something.

The complexity and dynamic nature of clinical settings makes it highly likely that something went unaccounted for – a DNS server may have been missed because moving the IV pump to the floor below was never mapped, or a connection to a backend database may have been overlooked because the link to billing was forgotten. We are human, as such, we make mistakes. The problem is a mistake within a clinical setting can have significant, even life changing, consequences.

That’s why Monitoring before actually implementing the policies and actions you have Engineered is critical. It’s often how you figure out exactly what your security domains look like; it should help you understand exactly what is going to happen, so there are no surprises when you actually start enforcing.

The Unavoidable Medigate Mention

• Note, this phase is only possible with a tool, like Medigate, that can enable it. I don’t want to be promotional or sound self-serving, but there really is no other way. Without something that can monitor and understand all the protocols and communications occurring in your environment, in real-time, it is too time-consuming and labor-intensive to manually monitor and try to figure out what a policy will do.

It takes correlating the numerous digital outputs from all the different devices involved and mapping them, in real-time, to the physical operations. (Note, this is often why many organizations haven’t implemented a Zero Trust stance to date – they don’t want to deploy security controls that introduce risks to the operations, but they have no way to test to see what their proposed controls will do, so they stick with doing nothing.)

With the ability to Monitor, you have a way to gather the information you need about what the controls you want to implement will actually do to your environment. This will give you the confidence to establish and maintain a successful CZT strategy.

What’s Going to be Easy

The easy part of the monitoring phase (if you have a tool to help you) is identifying when something breaks. You can immediately see when a policy or action is going to disrupt or block something that will have unintended consequences for a procedure or care protocol. Once identified, it can be fairly easy to make the appropriate adjustments – e.g., ensure the server, communication, etc. is allowed - to avoid any problems.

Also easy, is identifying anomalies. Most security devices can tell you when something happens that is unusual or new. As we discussed earlier (in Phase 3), the majority of devices in clinical settings, where care is actually delivered, are deterministic. They are only meant to do certain functions. They are not like desktops or other consumer computer resources that are controlled by unpredictable humans. They have a specific set of capabilities and manufacturer intended behaviors.

If you know what those capabilities and behaviors are, then it is very easy to identify when a device starts doing something or communicating in a way that it shouldn’t. However, that “If” can be very hard to determine. Correct vs incorrect capabilities and behaviors of medical devices are not necessarily easy to know – it takes a deep understanding of clinical protocols, manufacturers, and workflows. But, for solutions that have invested the time and effort to acquire this knowledge, it is then very easy to identify when something is operating outside of what’s normal or doing something it shouldn’t be doing.

While monitoring for breaks or security risks within your CZT environment is going to be somewhat easy, with the right tools, it’s going to be significantly harder to monitor for policy deviation.

What’s Going to be More Difficult

The hard part of the monitoring phase is figuring out what you may have missed. It is much harder to figure out if you mapped the care protocols and built the policies to protect them correctly. You need to ensure your physical and digital flows and boundaries align. While digital flows can be easily tracked, it can be extremely difficult to track physical communications in the same way. Understanding what is happening as it happens in the clinical setting is made that much harder by the complexity and dynamic nature of the environment.

You need to make sure you have accounted for everything when you are building your policies because the stakes are high – you cannot be wrong. You will need to see:

• How does your environment handle a new device? You need to see what happens when something new enters your clinical settings, because you don’t want policies that break or interrupt life-saving measures. Take an IntelliVue patient monitor (sorry, I don’t mean to be always picking on IntelliVue, it really could be any device). If you have standardized on IntelliVue B, but an IntelliVue K is suddenly introduced, how does your environment handle it? You don’t want to block it because it’s the wrong version, but you do want to know about it. You can make sure your policies alert you to the introduction of a new device, so you can figure out what to do next (Phase 5). (For example, you will probably need to investigate whether this “K” device is a one-off thing or a deliberate move by practitioners that will require a more permanent policy going forward.)

• What happens when a device violates policy? You are going to have to understand what was violated and why – was it a security breach (e.g., hack, malware, etc.) or, more likely, did something happen that you simply didn’t expect? You will then have to adjust your policy to incorporate this outlier activity to ensure it is allowed to happen uninterrupted.

• Do you have any gaps in coverage? You may find that you don’t have visibility to certain segments in your network. You may learn that when a device moves to a different NAC or connects to a guest network it is no longer under policy. Once you understand what’s happening and why devices suddenly “disappear,” you can take action to bring them back into the fold and ensure coverage is consistent and complete.

Note: there may be some controls you decide to perpetually monitor because there are too many variables or changes in usage and conditions to predictably deploy them. This should not be seen as a failure – sometimes simply knowing and alerting on activity that is predictably unpredictable is all you need to do to keep it safe.

Recommendations

We recommend remaining in the Monitoring phase as long as you need to determine whether your policies and actions are correct. Only when you are absolutely certain they are should you move to implement.  Some tips and tricks:

• Every attribute is important when enforcing policy, so look for platforms and solutions that give you the flexibility to monitor cyber physical policies that incorporate network, digital, location parameters. For example, can they identify whether a device is connecting to the right things, is it the right version, did it move out of the right place? See if you can put the wrong device on the network (e.g., Model Ks instead of Bs in a certain area) – does the solution alert? This will help you understand if you have the right platform.

• Look at the breadth and scope of tools for your industry to find the ones that will be able to uniquely identify every medical protocol and device in your environment. Otherwise, you are going to have blindspots; and those blindspots make your environment vulnerable.

Phase 5: Automate

The Automate phase is where CZT is made real. This phase allows you to apply cyber controls to your care protocols and processes, via your enforcement points, and start to reap the benefits of a CZT stance. It covers the ongoing operationalization of your CZT strategy, helping you identify and then define what comes next.

What’s Going to be Easy

Saying you are going to automate is the easy part – that’s it. Actually doing it is very difficult.

What’s Going to be More Difficult

Assuming you have accurately Identified all your devices (Phase 1), Mapped them to all the appropriate cyber and physical flows (Phase 2), Engineered policies to effectively protect those flows (Phase 3), and then Monitored the enforcement of those policies to optimize the safe delivery of care (Phase 4), then you are ready to figure out what comes next.

Basically, you are going to define what the consequences of a policy violation are and then automate those responses. For example, do you want to create a ticket when a new device is detected on the network? Who does that ticket go to? What are the next steps? Or maybe you want to initiate a call to the nurses station associated with that security domain? Or push a rule to the firewall to stop the device from connecting to anything? Or take a more drastic measure and kick the device off the network entirely?

The options are endless – what you choose will probably depend on the data, device, and care protocol involved. The key is, once you determine what you want to do, you should automate that process, so it can be done quickly and efficiently. Operationalizing these processes will take integrations with all sorts of systems across your entire environment, from your ticketing and billing systems to your security devices and CMMS.

Look for those platforms that can facilitate connections across your ecosystem because you don’t want to have to use multiple tools to automate. The goal is not to just achieve security, but operational security – that’s what ultimately makes clinical zero trust so valuable to the business of healthcare.

Recommendations

You want to make things easier, not harder, so look for solutions that can help you automate by talking to all the different types of systems and equipment in your environment.  Note, vendor-agnostic platforms, which have expressly built their solution to integrate with other technologies, will probably be able to support your needs best. You want solutions that can offer broad vendor support across different types of platforms - operational, security, ticketing, tracking, location platforms – to try to maximize the value and minimize the complexity of maintaining your CZT stance.

For more general information, you can check out Medigate’s white paper on Clinical Zero Trust.