Zero trust element #3: Where is the connection going?

As discussed in this series, the first element of the Verify process concludes with the initial identity assessment. The second element requires understanding the resource being requested: the application. Along with the third element, these conditions will determine how applications are submitted to the Control and Enforce phases of the zero trust process (to be covered later).

Determining which initiator can connect to which destination service is ultimately an outcome of the Verify and Control phases of a zero trust solution. Zero trust services are not firewalls, which means they are neither pass-through nor static. Therefore, the implemented policy must be more than a simple definition.

Recall how legacy IT controls are implemented statically based on network controls–for example, using IP addresses and TCP port values. This is not only limiting and subject to misconfigurations, but also inefficient to set up and maintain.

Take two common apps you may need to access: one internal (like an ERP platform) and one external (like YouTube). These apps have substantial differences in function, form, location, etc. 

With a firewall, both apps are treated the same. Controls are applied universally until the path is selected, a decision that typically happens post-control and is reliant on the network.

Firewall-based architecture controls are constructed at layer 3 (network) of the OSI model. As such, they are not natively able to interpret beyond an IP address. This means any attempt to understand content beyond the IP-to-IP stateful control, such as the identity of individual users brokered from an IdP, requires bolted-on functions or infrastructure to manage identity values, associate traffic with this identity, and enforce required controls for these sessions.

This is impactful since cloud-hosted applications leverage IdP-based authentication and authorization, so features like single sign-on (SSO) are seamless when a user logs into a corporate Salesforce account or an internal SAP ecosystem.

Not understanding these authentication and authorization outcomes results in two distinct, negative impacts when using firewalls:

1. Users must authenticate twice with two different authorizations.
2. These identity values must be managed in two locations, with two different sets of identity controls to consider.

Conversely, deploying a zero trust solution natively based on layer 4-7 proxies allows for inline integration and understanding of identity in relation to users’ access requests. This means that, when access is requested with a true proxy-based zero trust solution, the control focuses on the identity and conditions of the initiator (values outlined in Element 1) plus the destination application, rather than solely an IP address. User-to-application segmentation is therefore not based on cumbersome network controls but rather by identity-aware policies.

This allows zero trust solutions to assess end-to-end (not solely network-based) context and apply controls for more granular categorization and access control. Applications are evaluated individually. The ERP app is recognized as an internal app utilized by few users, while YouTube is recognized as an external app available to anyone. Infrastructure, locations, and IP addresses related to YouTube are easily identifiable and should be actively updated within application context.

Ultimately, all services within a zero trust solution must not be trusted. Trust considerations have substantially shifted due to the dynamic nature of content and applications accessed. Least-privileged access in zero trust delivers multiple benefits:

• Applies correct controls to correct sources
• Obscures protected resources from unauthorized sources, reducing risk
• Reduces waste, e.g., Linux servers can’t connect to Windows patch systems
• Provides granular visibility and learning of flows per access request, not network IP-to-IP
• Consolidates access based on identity, not a network, allowing a network’s function and infrastructure to be optimized

Technology and architecture considerations

Determining the application category and policy begins after validating the initiator’s identity. Based on the initiator’s request, applications must be differentiated between:

• External or internal apps
• Known apps belonging to a predetermined category
• Unknown apps

Connectivity is not the goal of app determination. Rather, it’s the implementation of rules to decide what conditions will be considered within the Control and Enforce phases. 

External or internal apps

An external app is one with an inbound listening service that allows anyone on the internet to attempt to connect to it, like google.com or salesforce.com.

Internal apps are those hosted by the enterprise in their data center or in an IaaS/PaaS environment. They have an inbound listener, but are generally privately hosted behind network layer controls like firewalls and connected to internal trusted network paths. These apps exist in internal address spaces, e.g., server1.local, or on a private IP (RFC-1918) space.

Known apps belonging to a predetermined category

These are applications that the zero trust system already knows. They can be classified into one of three categories:

• Known good: Applications that are documented, assessed, and understood
• Known bad: Applications that are documented, reviewed, and determined to be malicious
• Known risky: Applications that are documented, reviewed, and are possibly risky depending on who accesses them

Unknown apps

These are applications that the zero trust system has newly discovered and has not yet categorized. They are considered untrustworthy and risky until proven otherwise. This ensures Control and Enforce policies scrutinize these apps at the highest level.

If unknown apps are external, i.e., consumable on the open internet, the zero trust solution should be able to quickly assess their risk level. This assessment concludes with a categorization of the site based on function (a video streaming site versus a sales tool). Internal apps must be flagged as newly identified, allowing the enterprise to determine which segment, app definition, policy, etc., best describe them. 

IT vs. IoT/OT workloads

Both sets of apps generally rely on similar infrastructure and technology: connected devices communicating on a shared network. However, there are major differences:

• Information technology (IT) apps deal solely with the processing of information for human users, e.g., email or video streams.
• IoT apps generally collect data from IP-enabled things and forward it to external IoT platforms for analysis.
• Operational technology (OT) apps control physical devices like industrial or access control systems.

OT is unique in that the hardware and software are designed to monitor and control specific physical environments, such as heating a space or slicing food. Typically, OT controls follow a standardized set of OT security controls depending on their function (e.g., IEC 62443 or the Purdue Model).

OT services can manage industrial control systems (ICS) and supervisory control and data acquisition (SCADA), which often require human oversight. IT-based technology solutions like zero trust are able to provide privileged remote access connectivity to OT platforms. This allows for fully isolated, clientless RDP/SSH as well as secure file/data transfers.

Web vs. non-web apps

While web-based apps are the majority of traffic, they are not the only traffic requiring categorization. Non-web apps might include categories enterprises map to certain functions, like “All file servers” as a group that contains all IP addresses, FQDNs, and domain names for all servers that host file servers running on port 445 (SMB).

Decoy apps

Policy definitions should include the ability to define alternate destinations for app access. This allows enterprises to define honeypot-like services that help identify and mitigate threats posed by compromised users. 

Zero trust progress report

In our example, identity and context have been verified for both John and Jane, and the next step is identifying where the connection request is headed, as well as the implications of that application connection. 

Download the Seven Elements of Highly Successful Zero Trust Architecture eBook and stay tuned for more installments of our accompanying commentary.