Part 3 of a 4 Part Blog Series
Originally published by Medigate www.medigate.io. Reposted with permission.
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 and 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!)
Phase 3: Engineer
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 (phase 1 and 2). 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 in a way that ensures you are doing no harm.
Example of What a CZT Policy Covers
Take an IntelliVue MX800. A CZT policy that protects the integrity of the service that 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 the topology); allow it to use the HL7 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 these devices 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 (phase 2). That could make engineering a process and creating a policy/rule to set boundaries and constrain its activity should be 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 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, and 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 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.
The primary recommendation for this phase is to investigate your control points before you enforce policies to understand the limitations of the solutions you have or are looking to buy. You can look at:
Watch out for upcoming blog on phases 4 and 5. For more general information, you can check out Medigate’s white paper on Clinical Zero Trust.