SD-WAN deployments feed SASE network and security convergence SASE vs. SD-WAN: What's the difference?
Tip

How SASE convergence affects organizational silos

Most enterprises have siloed departments, but SASE's convergence of network and security functions is disrupting those constructs and driving the need for more team communication.

Secure access service edge architecture drives the convergence of networking and security functions at the edge. But successful SASE implementation requires communication, integrated devices and holistic planning.

Before SASE emerged, enterprises were largely interested in software-defined WAN for their edge locations. SD-WAN created an opportunity to displace carrier-led architectures and keep established vendors from having a lock on the enterprise WAN business. However, direct internet access (DIA) and broadband connectivity at remote locations created a management issue regarding the security requirements at these edge locations.

Enterprise-grade security uses a stack of functions, often deployed as a literal stack of devices. While this strategy can be cost-effective in centralized instances, a branch or remote office design requires a different model. For performance reasons, enterprises desired to split access between secure tunnels to services and DIA for applications such as Microsoft 365.

This is where SASE started.

SD-WAN addressed scale but complicated security

Intelligent routing using SD-WAN technology solves many scale and performance issues for enterprises but doesn't resolve the issue of complex security. If anything, SD-WAN can complicate the problem.

Most early SD-WAN users chose to leave security as a separate process. As a result, branch users would ride the SD-WAN connection to a data center -- just like they did with MPLS -- where the enterprise demilitarized zone, or DMZ, permitted internet access. So, a DIA- or broadband-connected branch would transit the internet to get to the internet.

The two following approaches emerged in an attempt to improve the SD-WAN security situation. In both cases, the security and networking teams operate entirely independently of each other.

1. Colocation hubs

This model creates new security stacks that the security team operates. These hubs are distributed geographically to improve client performance but maintain complete separation on an approved security stack.

An example of this architecture is the Equinix Performance Hub reference architecture, in which clients can aggregate SD-WAN traffic and establish enterprise-grade security stacks that permit internet, SaaS and cloud connectivity.

2. Security as a service

Zscaler pioneered the security-as-a-service model, in which the branch has secure tunnels to the enterprise data centers and separate tunnels to Zscaler data centers. Netskope also started with this model.

The barriers to SASE are primarily organizational and driven by the divided nature of IT teams.

Organizational silo issues

IT departments in large enterprises grew over time and, out of necessity, resulted in organizational cultures that created separate silos for networking, servers, desktops and security. In the world before SD-WAN, security equipment was centralized at data centers and managed by a separate team.

As a result, the barriers to SASE are primarily organizational and driven by the divided nature of IT teams. A successful SASE implementation requires enterprises to look holistically at remote customer premises equipment (CPE) and its network and security functions.

For example, a security operations team member might need read access to a router and write access to a firewall. Conversely, a network troubleshooter might need write access to a router but need read access to the intrusion prevention system and firewall. Organizations with these silos live by ITIL separations and provide tiered access to infrastructure devices.

But situations arise in which enterprise teams do not share device management -- even where security and networking functionalities have fully separated management interfaces. This is where logic and reality collide.

SASE evolution and vendor updates

Gartner has evolved its categorization of SASE architecture and functionality into two subentities:

  1. WAN edge services.
  2. Security service edge (SSE).

Security teams often pursue best-in-class approaches to the security stack. But the feedback has been that multivendor approaches in SASE, especially with SSE, need to be revised. While many vendors want to be one-stop shops, the overall best practice is that a single vendor should represent the SSE function. Why is this? WAN edge functions are usually performed at the edge, while many SSE functions must occur in the cloud. As a result, splitting functions within SSE often means inefficient traffic between SSE providers, leading to significant latency.

Screenshot of Gartner® categorization of SASE functions
Gartner® detailed view of SASE functions in two categories: WAN edge and SSE

Meanwhile, there has been vendor consolidation in response to the evolution of SASE. Vendors like Cisco, HPE, Fortinet, Palo Alto Networks and Versa Networks have moved to create single-vendor SASE offerings that combine network and security functions.

Separately, Netskope and Zscaler already offered consolidated SSE functions, although Netskope bought the SD-WAN vendor Infiot to enter the single-vendor SASE space.

In addition, a new class of vendors is emerging that offers end-to-end SASE services. These vendors include Cato Networks and Cloudflare, which converge SD-WAN and network security into global, cloud-native services.

What to consider about SASE-SSE operational convergence

An organizational construct with rigid silos written in stone probably won't look at a native SASE or SSE offering, but it should. The cost benefits of integrated offerings are huge, offering fewer devices, fewer vendor contracts and less maintenance.

Enterprises should evaluate whether a SASE or SSE platform supports the four following aspects:

  1. An integrated universal CPE (uCPE) device that can perform all local networking and security functions.
  2. A single-pass process for all networking and security functions, whether in the uCPE or the cloud.
  3. A cloud or content delivery network offering to provide the SASE model's centralized functions, such as DNS and cloud access security broker.
  4. Role-based access control that enables the separation of management and operations for networking and security functions.

Network and security teams know their organization's appetite for change and desire for cost reductions. Have potential vendors answer these questions, and the options will emerge.

Editor's note: This article was updated to reflect industry changes and improve the reader experience.

John Cavanaugh is vice president at the office of the CTO at BlueAlly and leads a team of consultants focused on designing secure infrastructure.

Next Steps

Explore SASE products to cut through the truth vs. hype

Dig Deeper on Network security