Micro-segmentation defined by Clinical Process for a Healthcare ZTA

This article is inspired by a conversation with a friend about using clinical workflow definitions to help measure system vulnerabilities listed here. It was well received and made useful points about how to organize vulnerability assessment and management work by looking at the work (Tier 2 in the RMF) not just the technology to see where blind spots may exist. I decided to also use workflow to inform Zero Trust Architecture (ZTA) definitions. You'll see some repeated information here but the purpose of the reuse is different from before, I think you'll agree.

There are several manuals available that prescribe how to define a ZTA as the design has been around and evolving for more than ten years. NIST SP 800-207 is now a primary reference and authority in both the public and private sectors. The Five-Step Process for ZTA Implementation includes

• Define the Protect Surface,
• Map the Transaction Flows,
• Build a ZTA,
• Create a Zero Trust Policy, and
• Monitor and Maintain the Network.

Since zero trust is an ongoing process of development, a maturity model's structure provides the most accurate means of monitoring progress. With several shared industry best practices as a point of reference, the draft CISA Zero Trust Maturity Model frames development in this way.

A Health System (AHS) is the strawman healthcare business we'll describe the process. AHS's network of 25 clinics, six urgent care centers, and one hospital has provided healthcare services to the St. Louis, MO metropolitan area. The organization provides inpatient and outpatient services, emergency care, pharmacy services, and health and wellness programs from its headquarters in St. Louis Park, MO. AHS runs an integrated healthcare delivery network.

In this make-believe health system, it was "believed" to have been the victim of a ransomware attack, which is a type of cyber-attack in which attackers encrypt the victim's data and demand a ransom to be paid in exchange for the decryption key. The attackers are believed to have used the Ryuk ransomware, which is a type of ransomware that is often used in targeted attacks against large organizations.

AHS staff, in late 2008, realized that they needed a more efficient medical record system to improve efficiency and security. They were able to install the EPIC medical management and electronic medical record system. AHS replaced its EMR system with the EMR system from Epic supported by IBM Power Systems servers. However, due to budget constraints, they didn’t fully upgrade network infrastructure or their sparse security architecture.

Given a ZTA implementation, it is useful to describe an IT support system workflow in AHS. In the following flows, AHS IT Workflow to support the Clinical process includes a series of patient care tasks by various systems and in a sequence that accomplishes a defined step in patient care. This step becomes the basis for defining network micro segmentation – a key step in creating the ZTA – as well as basic protection surfaces, and team members. The simple and very limited IT patient care workflow is shown in three phases: Patient Intake, Patient Examination and treatment, and Checkout. These systems are characterized in Table 1, AHS Patient Care supports systems.

Functions provide a simple and limited view of the functions, technologies, and object components that in part comprise the clinic-level patient care system architecture and is a task-oriented expansion of Table 2. The functional table lists a set of data management applications or capabilities that supports patient care tasks or activities. The rows represent individual applications or functions associated with a software component, the organizational description and security attribute, and finally the business process category. There are two different business process categories of Clinic level Patient Exam/Encounter Management and Patient Intake Access represented. The Operation of Function column represents a work task.

AHS Care Workflow Definitions for ZTA

A process support view of system functional capabilities is presented in Figures 1-3, Figure 1: AHS Clinic Patient Check-in System Flow, Figure 2, AHS Clinic Patient Exam System Flow, and Figure 3, AHS Clinic Patient Checkout System Flow. Each of these simple systems flows requires overlaying security controls to manage, for example, patient kiosk access (Access Controls), network configuration (Access management, TLS/VPN tunnel network traffic protection, and device and user authentication), registration system tablets or workstations (OS patching requirements for wireless devices, software application configuration for vulnerable components).

Figure 1 illustrates workflow tasks and technology sequences and includes a variety of data-gathering tasks for some of the stakeholders and other users as shown in Table 3, Information and Stakeholder.

In Figure 2, care asset requirements change given the voluminous data sets needed for both reference, patient comparative outcomes, patient care documentation and record management, and lab order message traffic. All or part of these may be a local server or remote cloud resident - requiring secure network tunneling. "Again, each element of the IT assets will require vulnerability analysis to understand the Patient Exam workflow risk."

In Figure 3, Clinic Patient Checkout System Flow, the check-in systems may be used with the addition of financial information requiring additional documentation and potential bank or credit card information in addition to PII and PHI. Medical devices may be deployed in this segment. The segment may include a subset of patient information or may operate through a patient’s home network to reach back to hospitals' health systems for data recording. Patient lab orders or referrals may also be issued during this phase. Medical devices have poorly documented threat analysis. In a care context, such undocumented vulnerabilities may open attack surfaces to a clinical information system (e.g., unencrypted data transmissions, and others). 

The IT assets include the applications, operating system, and network encryption, and devices. Each element of the IT assets will require vulnerability analysis to understand the Patient Intake workflow risk. To achieve this implementation, elements that support ZTA are required. The core elements include:

• A policy engine that makes the final judgment on whether to allow, deny, or revoke access to a resource for a certain subject. The policy engine computes trust scores/confidence levels as well as final access choices.
• The policy administrator is in charge of initiating and concluding the transaction between a subject and a resource. It creates any session-specific authentication as well as any authentication token or credential that a client uses to access an enterprise resource. It is inextricably linked to the policy engine and relies on its decision to accept or prohibit a session.
• The policy enforcement point is in charge of connecting a subject to an enterprise resource, as well as monitoring and finally terminating the connection.

Care Workflow Analysis to Identify Network Architectures

Micro-segmentation of the network, frequently down to individual hosts, is required for a comprehensive zero-trust deployment driven by the care process to place firewall borders in the proper places. Health organizations that want to switch to a ZTA could find it challenging to microsegment historical systems that are connected to their current network. Where it is hard to integrate policy enforcement into a legacy application itself, it is suggested that policy enforcement instead take place at the next best site to support historical systems.

Care Workflow Analysis to Identify Attack Surfaces and ZTA

Given a specific Tier Two workflow aggregation of AHS care systems, it is possible to model workflow-related risk and build a context-specific transition plan. Tier two process dependencies establish process boundaries around systems with vulnerabilities so that a process segment can be assessed for remediation and transition to improved security characteristics, and performance. In the three example diagrams above, the workflow tasks can be evaluated for the protection of components but also the protection of the workflow segments.

Tier two-level analysis also means that the architecture of cyber defense systems can be tuned to workflow-related asset threat activity analysis. For example, a hospital's SIEM system (such as QRadar) can be configured to cluster alerts related to assets in a specific workflow segment. Assets in inpatient critical care contexts be prioritized for higher-level alerting of intrusion detection systems – such as SourceFire. Information Assurance analysis benefits from a Tier Two documentation focus. Risk analysis with vulnerability assessment tools such as Tenable Security Center would provide analysis for segment-related risk documentation so that POA&M priorities could be workflow segment asset and architecture-specific.

AHS ZTA Project

AHS identified protected surfaces to prepare to implement a ZTA. The most important Data, Assets, Applications, and Services (DAAS), which stand for the most essential components of AHS's operation, are contained on the defined protect surfaces. Its key protection surfaces, Access, and Patient care, are relatively small in comparison to the entire AHS possible attack surface. Protecting the AHS DAAS is the core of the ZTA project requirements. The project doesn’t address the transfer of the existing EPIC EHR transition to the cloud. After identifying the protected surface, AHS must analyze both the ingress and egress network flows about the protected surface. Understanding who the users are, what applications they use, and how they connect is the only way to establish and enforce a policy that ensures secure data access. This interdependence analysis of the DAAS, infrastructure, services, and users will reveal where AHS must implement controls, resulting in the definition of multiple micro-perimeters for each DAAS at each clinic site. It’s necessary to develop a template that can be used uniformly at all of the clinic sites while recognizing different physical configurations of a clinic and volumes of patient flow rates.

These perimeters are synonymous with the protective surface as possible and will follow it logically wherever it goes. AHS can effectively create micro-perimeters to ensure that only known allowed traffic or legitimate applications have access to the protected surface by deploying a segmentation gateway(s). A network component known as a segmentation gateway is either hardware or software that allows for the application layer's granular enforcement of access control (Layer 7). The segmentation gateway serves as the Policy Enforcement Point (PEP) with a policy based on the Kipling Method, which generates a Zero Trust policy based on who, what, when, where, why, and how. The Zero Trust policy establishes who is permitted to cross a perimeter at any given time, prohibiting access by unauthorized users and the exfiltration of confidential information. After AHS has developed a Zero Trust policy around the protected surface, the AHS security architecture team and systems administration team must continue to monitor and maintain it in real-time, improving the protected surface, considering any unaccounted-for interdependencies, and finding methods to make the policy better. Finally, the basic definition of ZTA includes elements that allow for flexibility, and changes in technology and workflow, which are presented in Table 5, Seven Pillars of ZTA.

Phases of AHS ZTA Project

Three phases of the AHS ZTA project include:

• Preparation and Needs Gathering: The project team defines the project scope, objectives, and requirements using a Waterfall approach. This includes determining which specific security measures, such as multi-factor authentication and network segmentation, will be implemented as part of the zero-trust architecture.
• Design and Development: After defining the project requirements, the team can transition to an Agile approach for the design and development phase. This enables the team to work in sprints and make changes based on feedback from stakeholders and unanticipated roadblocks in communications and configuration. During this phase, the team will work on developing and testing the solutions identified during the planning phase.
• Implementation and Deployment: The security solutions are integrated into the existing healthcare IT systems during the implementation and deployment phase. This phase is critical, and the team can ensure it by using a Waterfall approach. As compatible ZTA technologies become available, all steps or only steps 2 and 3 could be repeated. Post-deployment configuration management would keep the solution secure.

Implementation Design Patterns

To achieve a compatible and interoperable ZTA solution for AHS, the following components are elements of the solution presented in Table 5, ZTA Pillars and Solutions. 

Clinic Design Pattern

Local clinic deployment is fundamental to the AHS ZTA project as the key processes of patient access registration, patient examination and treatment, and patient release/checkout are replicated at all the clinics in AHS. The key components are presented in Tables 7 and 8, Clinic Vendors, Components, and Costs. The costs have not been validated but do represent published or referenced values. Figure 7, Clinic Deployment Pattern illustrates clinic networks, interconnections, and components and presents the initial pattern of computer and system installation, setup, and configuration.

In the initial pilot, the AHS clinic users range from small to midsize medical facilities and have from 5 to 20 PC users on average though a few of the clinics have more than a hundred PC users.  The number of PC users in a clinic can fluctuate quickly depending on several variables, including the volume of patients served, the number of staff members, and the usage of technology in patient care. Additionally, dependent on the standards used to define a "PC user," different sources may offer varying estimates for the number of PC users in a medical clinic. For the initial clinic sizing, 20 PC users are the initial deployment pattern size. Once the initial clinic pattern baseline design is established, the baseline will be scaled to meet the sizing requirements of each site. The software and hardware element in Tables 7 and 8 describe the software, service, and hardware components of the clinic pattern. 

The clinic authentication process uses the PKI infrastructure of a business to issue smartcards onto the YubiKey. Smartcard integrations are natively supported by Cisco AnyConnect. The interactions are presented in Figures 4 and 5, Authentication Sequence.

Figure 9, Clinic deployment pattern represents the initial interconnect structure with reporting and cyber analysis and protection functions identified as described in Table 5 above. Physical devices such as the various networking system and the Dell thin clients (hosting preinstalled Carbon Black agents) will send events to the Splunk SIEM. Cyber activity, such as authentication, DNS resolutions, and system monitoring will be analyzed by SecureX, Secure Workload, Umbrella, and email monitored by FireEye MX. Windows 11 clients that support various users will operate inside Horizon View as well as all other Cisco cyber analytic tools. In the design phase of the projected implementation, various systems will be configured to determine longer-term sizing, timing, and compliance configurations to develop a secure, scalable, and repeatable baseline pattern that be deployed throughout the AHS clinic system.  

EPIC/AWS Design Interconnect Pattern

Local clinic deployment is fundamental to the AHS ZTA project as the key processes of patient access registration, patient examination and treatment, and patient release/checkout are replicated at all the clinics in AHS. The key components are presented in Table 7, EPIC/AWS Cloud Implementation. Figure 8, Clinic Deployment Pattern illustrates clinic networks, interconnections, and components and presents the initial pattern of computer and system installation, setup, and configuration.

In the initial pilot, the AHS clinic users range from small to midsize medical facilities and have from 5 to 20 PC users on average though a few of the clinics have more than a hundred PC users. The number of PC users in a clinic can fluctuate quickly depending on several variables, including the volume of patients served, the number of staff members, and the usage of technology in patient care. Once the initial clinic pattern baseline design is established, the baseline will be scaled to meet the sizing requirements of each site. The software and hardware element in Tables 10 and 11 describe the software, and services of the EPIC/AWS pattern.

The EPIC/AWS authentication process uses the EPIC/Active Directory bridge to continue user authentication to EPIC ERH initiate at the clinic using YubiKey MFA. The interactions are presented in Figure 14 and Table 15, EPIC/AWS Authentication Sequence.

Implementation of various staging elements of EPIC is operating in Amazon Workspaces, a managed, secure cloud server solution that enables AHS to provision and use cloud-based Windows and Linux systems, to link a local VMware Horizon View VDI to the Windows 11 VMs to the production EPIC application environment on AWS confidentially. Either the Amazon Workspaces client application or the Amazon Workspaces Application Manager (WAM) can be used to link the local Horizon View environment to EPIC Amazon Workspaces. By doing this, AHS will shield local Horizon View VDI from the public internet and safely access the EPIC/AWS application environment. To create a secure connection between the local clinic network, VMware VDI, and EPIC/AWS resources, AHS will use Amazon Virtual Private Network (VPN) connected through a Cisco Firepower/VPN firewall.

To stream EPIC applications logs to the Splunk SIEM through the AWS VPN gateway a Splunk HTTP event collector must be configured to receive the AWS CloudWatch logs and CloudTrail using S3 storage buckets. Initially, an event collector token will be required but longer-term analysis may make this token optional. CloudFormation and CloudTrails using an S3 data storage bucket will be used to trigger the movement of various logs. The configuration must be tested for the timely forwarding of events. The S3 buckets used by CloudTrails must be sized over time to determine ongoing production utilization.