|
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:
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:
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
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:
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. |
Sorensen
|
RSS Feed