Zero trust is a journey and, for many IT pros out there today, a lifelong one as they transform enterprise infrastructures that are sometimes just as old as they are. As the zero trust industry has matured over the last five years, transformation roadmaps are becoming more apparent, enabling enterprises to see realistic implementation plans mapped to their business objectives.
Though a zero trust architecture is bigger than the sum of its infrastructure, today I’m going to focus on the infrastructure transition required to start realizing the zero trust vision many enterprises have today.
A brief recap of SASE vs. SSE
Gartner and Forrester have been at the forefront of zero trust promotion, and have done well articulating what it is and why we need to change. Gartner originally coined the acronym SASE (secure access service edge), which bundled the network architecture and security frameworks together into a package meant to live at the edge of corporate networks, allowing organizations to take full, secure advantage of the cloud.
Later on, the industry realized the WAN edge was too nebulous and ever-changing to be pigeonholed like that (5G or Starlink, anyone?). The security services aspect of SASE was much less dynamic so, in response, the secure service edge (SSE) was dreamt up to distinguish it from the WAN edge in the SASE landscape.
The move helped reinforce my view that the WAN, as we know it today, will ultimately fade away as enterprises transition towards more complete zero trust architectures.
But how do we get there, and what does the enterprise get out of it?
The ideal zero trust infrastructure end-state
The ultimate goal for zero trust from an infrastructure perspective is to reduce or eliminate the attack surfaces endemic to traditional network design. I list three goals when working towards a zero trust architecture vision:
- Reduce the distance between the consumer and the SSE
- Reduce the distance between the destination resource and the SSE zero trust network access (ZTNA) broker
- Reduce the number of corporate assets, networks, and services that a user or workload can directly interrogate without passing through an SSE
In this context, distance is best described as the potential number of routed hops between the consumer and the destination service. The diagrams below illustrate traditional distances between consumers and destinations, whether they be internet-based or privately-hosted applications in the data center.
Legacy connectivity model for internet destinations
Legacy connectivity model for privately-hosted applications
This diagram illustrates the final conceptual connectivity vision between the consuming user or service and the destination resource.
The SSE with zero trust connectivity model
Outcomes for the enterprise include:
- Better SaaS and internet performance, leading to greater productivity and larger takeup of cloud-based services
- Simplified infrastructure design, leading to lower operational costs and greater reliability and flexibility
- Inherently more secure IT infrastructure due to reduced attack surfaces and little to no capacity for lateral movement
Stage 1 - Replace traditional VPN
First, implement the SSE stack of services to replace VPNs for remote users. This includes protected internet access (via a SWG) and ZTNA-type access for internal applications.
ZTNA connectors need to be placed close to the enterprise’s private applications, i.e. within the data centers or public cloud locations. These are used to broker traffic between the private application, the ZTNA service, and the end user.
Due to the similarity of remote VPN-style access, many organizations start here to “kick the tires” on zero trust.
This provides:
- A learning exercise for IT and the enterprise
- The chance to set up infrastructure for ZTNA access
- Better visibility into application usage
- A better remote user experience
Remote user SSE connectivity to the internet and private applications
Stage 2 - Implement local breakout with SSE
Next, implement the SSE at physical locations, minimizing the distance, or the logical hops, between it and the consumer.
- Implement local breakout at the branches/remote offices using a cloud-based SSE.
Results:- Reduced MPLS usage
- Improved performance for SaaS and other internet traffic
- Reduced reliance on centralized security stacks
- Replace existing branch security appliances with the cloud-based SSE.
Results:- Reduced operational overhead
- Flexible spending/reduced CAPEX
- A flexible infrastructure design where egress is not dependent on hardware outside of network equipment at the branch
Once the SWG is standardized for on-premise uses, enterprises can look at replacing legacy security stacks in on-premise data centers and cloud IaaS locations. By this point, we've achieved goal number one by reducing the distance between the consumers and the SSE, while making progress toward goal number three.
Direct internet access via the SSE
Stage 3 - Implement ZTNA application access for on-premise users
The focus of stage 3 is offering private application access exclusively through ZTNA while on the corporate network. There are two general strategies for achieving this: Transitioning user application access to ZTNA in-place, while on the same network, or moving users to a separate “guest WiFi”-type segment, adopting the same policies set up for remote users (or the VPN replacement scenario). Realistically, large enterprises will employ a combination of these strategies due to differing application use between different personas.
Ensure ZTNA connectors are placed in the data centers or IaaS locations housing applications to meet goal number two. Ensure your ZTNA service has points of presence (PoPs) near your applications to maximize performance.
Organizations can further progress toward goal number three by including infrastructure and security policies that reduce or eliminate access between devices on the same user subnet (treat it like Starbucks) and replacing services that rely upon server-to-client or client-to-client connectivity. A good example is an Active Directory group policy that enforces the Windows Firewall to always be set to “Public Network”, even when on a corporate network.
Results:
- A further reduction in MPLS usage or its complete replacement with commodity broadband
- A seamless user experience regardless of the location
- Additional progress toward goal number three
User-to-app segmentation should be happening in tandem with this stage and the rest of the zero trust journey. Enabling application visibility only to those who are entitled to use the applications reduces the potential blast radius of any user device compromise. Much of this work will be coordinated with the application owners and the identity and access management groups.
Stage 4 - Remove users from the corporate network
At this point, all three goals have been reached from a user’s perspective. There is no application access outside of the SSE infrastructure and you now have a reduced lateral movement threat when a user device is compromised.
The goal now is to remove the ability for users to connect directly to the corporate network. This generally takes the form of tearing out network equipment and/or blocking access with a network rule.
Results:
- A drastically reduced attack surface with little risk of lateral movement
- A reduction in WAN complexity
Direct internet access via the SSE
Stage 5 - Deconstructing the WAN
At this stage, Figure 6 above now also represents the goal for service traffic: shifting non-user services from traditional network routing to SSE or zero trust-based traffic patterns. Each location now begins to operate as an island in the sea of the internet. You are now well on the way to achieving all three goals from a service perspective.
As I’ve illustrated above, the path to a zero trust architecture based on SSE is a journey, not the flip of a switch. That’s a good thing! A change to an infrastructure security model that is based on identity lends itself to the wide-open networks common today and enables enterprises to change at their own pace.
What to read next
Security Service Edge (SSE) reflects a changing market: what you need to know
SSE solution series: why a global, scalable cloud platform matters