SD-WAN vs. SASE? No!

The canonical definition of SASE includes five functions, four of which provide security and the fifth provides network connectivity, the network portion of which is usually implemented using SD-WAN, but it does not necessarily have to be SD-WAN. For example, if the enterprise does not focus on remote work and its remote locations have sufficient MPLS coverage, then the security functions of SASE can be applied without SD-WAN. One advantage of Forrester's SASE alternative, the zero-trust edge model, is that it does not merge remote security with SD-WAN, but emphasizes the security elements of SASE.

[[439688]]

SD-WAN and SASE should not be viewed as alternatives to each other, but rather as complementary and largely independent capabilities that combine to create a highly reliable, scalable, high-performance, and secure remote connectivity solution. SD-WAN provides the network foundation for SASE through network, content, and identity security services.

SD-WAN is the application of SDN technology to the wide area network, separating network control from data transmission. By inserting an abstraction layer between the physical and logical networks, the SD-WAN platform can combine multiple physical links into a virtual network and micro-manage the data packet flow on each virtual network to improve aggregation and application performance, availability and security.

SD-WAN is able to deliver the SDP architecture, combining underlay and overlay into a cloud-based solution. SD-WAN is suitable for any type of wired or wireless Internet connection, and provides channel bonding, redundancy, load balancing, and dynamic path selection based on network congestion and quality. In addition, SD-WAN also provides security (SASE supporters often promote themselves with security). In fact, the original selling point of SD-WAN is that it provides enterprise-level security (equivalent to MPLS) on any physical network link. Another advantage of SD-WAN is that the control plane is separated from the data plane, which can centrally manage network and endpoint configuration, management, traffic policy, and monitoring.

Typical SD-WAN security features include:

1) Use DTLS (using AES-GCM certificate exchange and authentication) or IPSec (using IKE key exchange) for link encryption.

2) Zero-touch auto-configuration of remote devices (CPE) to ensure secure initial setup.

3) Support the insertion of virtual network services (VNFs), such as NGFW and content filters, into the link topology.

4) Network micro-segmentation uses virtual networks and firewalls to divide WAN traffic by application, security level, or other criteria. Micro-segmentation also allows SD-WAN to enforce simple content control policies using routing/firewall rules specific to users, groups, and applications.

Source: Palo Alto Networks; The CloudBlades Platform

In summary, SD-WAN provides a network security foundation that meets enterprise needs and goes far beyond the capabilities provided by traditional client or site VPNs.

SASE is built on the network foundation, and if SD-WAN enables the proliferation of remote work and WFH, then SASE can be seen as supporting it through a set of network, data, and user security capabilities. Rather than viewing SASE as an innovative alternative to SD-WAN, it is better to view it as an evolutionary improvement in layering security on top of SD-WAN. Some vendors claim that SD-WAN only provides network connectivity and SASE is needed to provide edge network security, which is either a deliberate oversimplification or a blind marketing of SASE.

SASE adds four security capabilities to SD-WAN:

1) Next-generation Firewall as a Service (FWaaS): Currently integrated by many SD-WAN users through NFV and virtual firewall appliances.

2) SWG (Secure Web Gateway): used to monitor and filter web traffic.

3) Cloud Access Security Broker (CASB): Extends SWG by providing application-level network visibility and policy enforcement.

4) Zero Trust Network Access (ZTNA): Uses granular policies based on the initiating device, initiating user, and target application or service, using application- and session-specific authentication, replacing access security using client-side virtual private networks. ZTNA is the biggest change to traditional remote access security, which requires user and device credentials (usually certificate-based), certificate authorities (CAs), SSO services, and device access agents.

While packaged cloud services may be the best SASE delivery vehicle in most cases, it is not a requirement. Some organizations may choose to operate a private SASE infrastructure or contract with an MSP that provides SASE as part of its network infrastructure. In fact, Gartner, which coined the term "SASE," believes that the adoption of cloud-based SASE is slowly growing.

Gartner says that by 2024, 30% of enterprises will adopt cloud-delivered SWG, CASB, ZTNA and branch firewall as a service (FWaaS) capabilities from the same vendor, up from less than 5% in 2020. To meet user security requirements, SASE components are increasingly being adopted.

Cloud delivery isn’t unique to SASE

Some vendors confuse SASE with cloud delivery to promote so-called "unique advantages" and create the illusion that SD-WAN is "obsolete."

The problem comes when vendors falsely claim that SASE is the only cloud-based network service. Although cloud hosting is our preferred SASE operating model, it is not required, and some products support cloud, on-premises, or hybrid deployments.

Edge networking and secure cloud service delivery make the most sense in an era when SaaS usage is exploding in most enterprises, with online applications replacing on-premises software, but cloud delivery is not the only option. For example, in a SaaS-centric enterprise environment with a large number of WFH employees, forcing security to be centralized on data center equipment is both expensive and inefficient.

Cloud deployment is not limited to SASE, it is also an effective way to deliver basic SD-WAN services. In fact, NaaS vendors such as Aryaka, Adaptiv Networks (formerly TeloIP), Masergy, etc. have long provided SD-WAN as a service by centralizing the control plane on cloud infrastructure and using private core networks and globally distributed POPs.

This brings up another issue, with vendors claiming SASE is an “appliance-based architecture” that requires “proprietary appliances for added security and remote support.” The reality is that any SD-WAN-based remote access solution requires some form of CPE to terminate two or more physical links, provide L2/L3 connectivity to the remote LAN, and perform control plane decisions to direct traffic to the best physical link. It is simply wrong to confuse SD-WAN CPE (typically a small, low-power device) with a full-featured branch office router such as a Cisco ISR or Juniper SRX.

Competition vs. Complementarity

SASE is not the successor of SD-WAN, but its teammate, adding security features to the software-defined WAN foundation. At the same time, each can also be used independently: SD-WAN does not require SASE, and SASE functions can also be used on traditional networks. Similarly, SD-WAN and SASE can be deployed in any VM or container environment, whether as a cloud service (NaaS), cloud IaaS or hybrid deployment.

The advantage of SASE is that it provides organizations with a complete, integrated security portfolio that covers most situations and eliminates the problem of piecing together point products. However, many organizations prefer to introduce new applications or services gradually and incrementally. In such cases, SD-WAN is more suitable for enterprise change management because it allows basic functions such as NGFW, WAF, and SWG to be integrated into the WAN as needed.

Most of the important security improvements of SASE (i.e. zero-trust authentication model) take time to introduce. Therefore, most organizations tend to add SASE functions such as NGFW, SWG, etc., which are easier to deploy, as incremental additions to SD-WAN, while selectively introducing ZTNA for high-risk/high-value applications and users.

Rather than pitting SASE and SD-WAN against each other, it’s better to view them as complementary capabilities.