SORENSEN CONSULTING
  • Home
  • Services
  • About
  • Contact
  • Sorensen Blog

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

4/19/2021

0 Comments

 
Part 4 of a 4 Part Blog Series
 
Originally published by Medigate www.medigate.io. Reposted with permission.
 
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 stages, while the third blog covered the Engineer stage. 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 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 a ton of different 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 compute 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. Note, that “If” can be very hard to achieve. The 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 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. 
  • Whether or not 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., 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 know what you want to do, you want to 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 different 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.

0 Comments

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

4/19/2021

0 Comments

 
​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. 
 
Recommendations
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:
  • 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., do they understand 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 throughout your environment.
 
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.
 
0 Comments

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

4/19/2021

0 Comments

 
0 Comments

Defining Clinical Zero Trust: What you need to be thinking about when implementing a zero trust strategy for healthcare

4/19/2021

1 Comment

 
1 Comment

    Sorensen
    ​BLOG

    Insights, musings and calls to action around the network.

    Picture
    Sarah Sorensen
    Marketing consultant, strategic advisor, and author.

    Archives

    April 2021
    January 2018
    April 2013
    April 2010
    December 2009
    November 2009
    October 2009
    September 2009
    July 2009

    RSS Feed

Proudly powered by Weebly
  • Home
  • Services
  • About
  • Contact
  • Sorensen Blog