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

Part 3 of a 4 Part Blog Series

This blog covers phase three – Engineer – of the planning and roll out of a Clinical Zero Trust (CZT) strategy. This is where the rubber hits the road, so to speak, as we define the actual security controls that we want to implement to mitigate the risks to a hospital’s physical and digital systems.:

To set the context, let me remind you this is the third in a series of four blogs that delve into what it really takes to establish and implement a successful CZT strategy. The first blog defined CZT and outlined the five phases that health systems embark on during their journey to creating a sustainable CZT stance. Those phases include: Identify, Map, Engineer, Monitor, and Automate. 

The second blog covered what is involved in the Identify and Map stages, and this one will focus on what is going to be easy as well as what is going to be hard about engineering CZT policies that effectively protect the clinical setting. (If you’re sensing a cadence, you already know the fourth and last blog will review the Monitor and Automate stages!)

What We’re Trying to Accomplish in the Engineer Stage

The goal of this stage is to define the policies and actions that can be implemented to protect the integrity and flow of each care protocol. As we’ve noted before, CZT is not about safeguarding access to data and devices, but the delivery of care.

The goal is to insert controls to defend the smallest “surface area” possible. These are the physical boundaries to the digital flows that you identified and mapped in phases one and two. You are basically keeping intact the combination of devices and processes that need to operate unimpeded and uninterrupted, and inserting security at the boundaries to mitigate risks and ensure you are doing no harm.

Example of What a CZT Policy Covers

Take an IntelliVue MP60 (patient monitor). A CZT policy that protects the integrity of the service that a bedside patient monitor delivers would include:

• Allow DHCP bi-directional communications and access to the local DNS (actually almost every device will need this);

• Allow it to talk to the local nurses’ call station(s) (via an IP address(es) or DNS address, depending on topology);

• Allow it to use the Philips Data Export protocol for outbound communications only (Layer 7); everything else should be denied – it can’t talk to anything else or receive communications from anything else.

What’s Going to be Easy

The easier part of developing policies centers around the fact that cyber physical systems are deterministic. These devices almost always act the same way. A patient monitor will always send data on a certain port to a certain place at a certain time, and it will use the same protocols and speak to the same hosts (e.g., external control systems, nurses’ stations). In essence, the way they work and behave is predictable.

This means once you have visibility (phase 1) into what the device is, you can probably determine what it should be doing. That could make engineering a process and creating a policy/rule to set boundaries and constrain its activity fairly easy. Of course, we know that nothing is as easy as it should be…

What’s Going to be More Difficult

We can’t say it enough: clinical settings are anything but simple or static. The hard part of developing effective CZT policies is accounting for the continuous changes in the environment and understanding all the complexity and inter-dependencies of all the people and devices required by different care and business protocols.

For the devices that never move, it’s fairly easy to scope a policy that can protect all the operational processes that the device is involved in. For example, MRIs typically don’t move, so it’s much easier to determine the scope of the communications and interactions that need to be allowed. Devices that move all over the place, however, like a patient monitor, are going to be much more difficult to craft a policy for.

This gets us back to mapping (phase 2). If you have mapped your environment well, effectively documented the physical workflows and care protocols, and tied them to the cyber flows, you should have all the potential steps, devices, and dependencies you need to consider. This allows you to create a policy, like the example we described above for the IntelliVue monitor.

When that IntelliVue monitor is moved to another floor, however, the policy will likely need to change. For starters it will probably need to talk to different DNS servers and different control stations/nurses’ stations. It may also need to be applied by different enforcement points, which can create additional complications.

In your environment you probably have a mix of switches, NACs and firewalls you are using as control points. Each enforces policies that are written differently, and each may have a different control structure. If you have to write policies based on the lowest common denominator for all your control points, you will lose all the impact of your CZT policy. For example, you don’t want to have to write a policy that operates at Layer 4 - allow port 2575, TCP, UDP. You want to be precise, which means operating at layer 7, where you can specify the allowed protocols (HL7).

This means you need a way to accommodate device movement and apply policy accordingly, so it can change as you are running down the hall if need be. One way to accomplish this is to tie policies to MAC addresses to ensure your controls can recognize the device and apply the right policy. Often you need a solution, like Medigate, that can fill out the missing pieces that control points have on devices, so you aren’t forced to apply generic, homogenized policies that do little to mitigate risk.

Recommendations

The primary recommendation for this Engineering phase of your CZT Strategy is to investigate your control point before you enforce policies to understand the limitations of the solutions you have or are looking to buy. You can look at:

• If enforcement points really have the ability to do Layer 7 controls. You can check the protocol support list for every healthcare protocol you are using in your clinical network to see what they are able to recognize and enforce policy on (e.g., WACP, used by Welch Allyn’s vital signs monitor).

• Whether you can move a policy with a device, particularly across domains. Are there any limits on the device type or location due to the way the vendor architects and implements controls?

Not to be too self-serving, but Medigate can help you address some of these issues, assisting in the development of policies that can be applied across the ecosystem. We can help translate policies for the available control points in your environment, e.g., NAC and firewalls, to ensure you can implement precise controls.

Watch for upcoming blogs on phases 4 and 5. Also, for more general information, you can check out Medigate’s white paper on Clinical Zero Trust.