Don’t be confused by false choices: It’s not SD WAN vs. SASE, but SD WAN and SASE.
Many IT vendors are like the proverbial hardware store that only sells one kind of tool: when all you have is a hammer, every problem looks like a nail. Such vendors compulsively frame issues in ways that inevitably paint their product or service as the ideal solution, typically gliding over technical and categorical nuances and related products as they present a distorted view of an issue. We see this type of marketing deception in the remote networking business as companies focused on SASE pit their product as a successor or superior alternative to SD WAN, implicitly setting up a false dichotomy between the two. The question isn’t whether organisations should deploy SD WAN or SASE, but when and how to deploy each.
Table of Contents
Each technology in its place
The canonical definition of SASE includes five functions, four of which provide security, with the fifth supplying network connectivity. Given that SASE focuses on securing the edge — indeed, “edge” is part of the acronym — the networking piece is typically delivered via SD WAN using whatever physical circuits are available at a particular location, however, SD WAN isn’t required. For example, if an organisation isn’t concerned about home-based or hybrid employees (WFH) and has adequate MPLS coverage to its remote locations, the security features of SASE can be applied without an SD WAN. Indeed, an advantage of Forrester’s SASE alternative, Zero Trust Edge model is that it doesn’t conflate remote security with SD WAN and emphasises the security elements of SASE.
- Secure Access Service Edge (SASE) is SSE + SD-WAN (Access).
SD WAN and SASE shouldn’t be considered competitive alternatives, but rather complementary and largely independent sets of capabilities that are best combined to create highly reliable, scalable, performant and secure remote connectivity solutions. SD WAN provides the network foundation that SASE builds upon with network, content and identity security services.
As I detailed in an earlier article, SD WAN uses an SDN architecture that disaggregates network control from transported data.
“By interposing an abstraction layer between physical and logical networks, an SD WAN platform can combine multiple physical links into a single virtual network and micro-manage packet flow over each to improve both aggregate and application-specific performance, availability and security.”
SD WAN is capable of delivering an SDP architecture with underlay and overlay combined into a single cloud-based solution.
SD WAN works with 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.
However, don’t let SASE evangelists convince you that SD WAN doesn’t provide security. Indeed, the initial selling point of SD WAN was its delivery of enterprise-grade security (read, equivalent to MPLS) on any physical network link. Another key SD WAN benefit is the centralised management of network and endpoint configuration, management, traffic policies and monitoring, which results from splitting the network control and data planes.
Typical SD WAN security features include:
- Link encryption using DTLS (with AES-GCM certificate exchange and authentication) or IPSec (with IKE key exchange).
- Zero-touch automated configuration of remote devices (CPE) to ensure a secure initial setup.
- Support for inserting virtual network services (VNFs) such as NGFW and content filters into the link topology. Indeed, service insertion and chaining is how many SASE products hook into an existing SD WAN, however, many enterprise implementations already included virtual firewalls.
- Network microsegmentation using virtual networks and firewalls to partition WAN traffic by application, security level or other criteria. Micro segmentation also allows SD WANs to enforce simple content control policies using user-, group- and application-specific routing and/or firewall rules.
Most SD WAN products expose APIs that allow programmatic setup and configuration and some include packaged modules that automate the integration of SD WAN networks with select cloud services and applications. For example, the Palo Alto Prisma CloudBlades Platform allows packaging all necessary integration steps into a single software package that:
- Configures and programs the app-flow engine on the Prisma Instant-On-Network (ION) lightweight branch CPE.
- Establishes connectivity to cloud private networks (VPCs, cloud gateways)
- Sets up authentication and telemetry.
- Enforces network and application segmentation policies such as blocking branches from connecting to each other.
- Integrates with ITSM SaaS products such as ServiceNow to automate incident management and simplify troubleshooting.
Such software appliances significantly reduce the overhead of network integration and demonstrate the advantages of a cloud-resident SD WAN control plane.
In sum, SD WAN provides the network security basics that satisfy many enterprise needs and go far beyond the features provided by traditional client or site VPNs.
SASE builds on a network foundation If SD WAN enabled the widespread proliferation of remote worksites and WFH, SASE can be viewed as bolstering it with a suite of network, data and user security features. Instead of seeing SASE as an innovative replacement for SD WAN, it’s more instructive to think of it as an evolutionary improvement that layers security atop an SD WAN foundation. Vendors claiming that SD WAN only provides network connectivity and that SASE is required to provide edge network security are either intentionally oversimplifying or disingenuous.
As we detailed in our earlier article on products and vendors, SASE adds four security features to an SD WAN substrate:
- Next-generation firewall-as-a-service (FWaaS), which as we detailed above, has already been incorporated by many SD WAN users via NFV and virtual firewall appliances.
- Secure Web Gateway (SWG) to monitor and filter web traffic
- Cloud Access Security Broker (CASB) to extend SWG by providing application-level network visibility and policy enforcement.
- Zero-trust network access (ZTNA) replaces access security using client VPNs with application- and session-specific authentication using granular policies based on the initiating device, initiating user and target application or service. ZTNA is the biggest change to conventional remote access security and requires an enterprise directory that delivers user and device credentials (typically certificate-based), a certificate authority (CA), SSO service and device access proxy.
Although packaged cloud services might be the best SASE delivery vehicle for most situations, it’s not required. Some organisations might choose to operate private SASE infrastructure or contract with an MSP offering SASE as part of their network infrastructure. Indeed, Gartner, which coined the term “SASE”, sees cloud-based SASE adoption increasing at a glacial pace,
“By 2024, 30% of enterprises will adopt cloud-delivered SWG, CASB, ZTNA and branch office firewall as a service (FWaaS) capabilities from the same vendor, up from less than 5% in 2020.”
The adoption of SASE components is rising to meet the demands of user security.
Instead, many organisations will likely provide SD WAN and edge security using a mix of cloud network services, self-managed hardware appliances and virtualised software on industry-standard servers. As Gartner indicates in its blog, the best case for cloud services is at small branches and home offices, particularly those with obsolete network hardware needing an upgrade.
Cloud delivery isn’t exclusive to SASE
Unfortunately for those trying to understand and compare products and technologies, some vendors and analysts conflate SASE with cloud delivery, implying that the as-a-service model provides a unique advantage over (in their estimation) passé SD WAN products. Indeed, cloud-based SASE providers suggest that the cloud is the only viable option for edge security. However, as we pointed out in an earlier roundup of SASE vendors, cloud delivery is a feature, not an intrinsic element of the product category.
The problem comes when vendors use a faulty claim that SASE is unique as a cloud-based networking service and proceed to declare SD WAN obsolete. Indeed, these cloud maximalists further assert that cloud provisioning is the only viable operating model for remote access networking. Although cloud hosting is our preferred operating model for SASE, it’s not required and some products support cloud, on-premises or hybrid deployments.
We agree with the maximalists that cloud service delivery of edge networking and security makes the most sense in an era of exploding SaaS usage in the majority of enterprises with online applications displacing on-premises software, but disagree that cloud delivery is the only option. As we wrote, In a SaaS-centric enterprise environment with a significant share of WFH employees, centralizing security enforcement on data center appliances is costly and inefficient.
“With WFH employees and remote contractors reliant on cloud services, it makes little sense tunnelling their network traffic to privately-operated SASE infrastructure only to route it back out to the Internet. Far better to direct employee traffic to a globally distributed SASE service that is often hosted in the same hyperscale data centres used by the major SaaS applications.”
Realtime cloud SASE is available from globally distributed gateways.
However, as I mentioned above, cloud deployment isn’t limited to SASE, but is also an effective way to deliver basic SD WAN service. Indeed, NaaS vendors like Aryaka, Adaptiv Networks (formerly TeloIP), Masergy and others have long provided SD WAN-as-a-service by centralizing the control plane on cloud infrastructure and using a private core network and globally-distributed POPs.
This leads to another critique of some SASE marketing, namely that it is “an appliance-based architecture” that requires “proprietary appliances to add 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 execute control plane decisions to direct flows to the optimal physical link. The mistake is conflating SD-WAN CPE, which is typically a small, low-power appliance physically indistinguishable from a cable modem, with a full-featured branch office router like a Cisco ISR or Juniper SRX.
Don’t confuse features with the delivery model
SASE is not the successor to SD-WAN, but rather its teammate, adding security features to a software defined WAN substrate. However, like human teammates, each is usable independently: SD-WAN does not require SASE and SASE features can be used on traditional networks. Likewise, as software artifacts, both SD-WAN and SASE can be deployed on any VM or container environment, whether that’s as a cloud service (NaaS), on cloud IaaS, as self-managed software on private systems or a mix. The following is a graphical representation illustrating the various abstraction layers and their relationship.
The advantage of SASE as a product category with a defined bundle of features has the advantage of offering organisations a complete, integrated security suite that covers most situations and eliminates the problems of cobbling together point products. Unfortunately, as seasoned IT veterans have seen countless times,’big bang’ packaged products, most organizations prefer to introduce new applications or services gradually and incrementally. Here, SD-WAN is better attuned to corporate change management in that it allows incorporation of basic features like NGFW, WAF (web application firewall) and SWG as needed in a WAN.
Unfortunately, the majority of significant security improvement with SASE, the zero-trust authentication model, is the most disruptive and thus will take time to introduce. Hence, typical organisations would benefit from exploiting the more easily deployed SASE features (NGFW, SWG, etc.) as incremental additions to an SD-WAN while selectively introducing ZTNA for high-risk/high-value applications and users.
Rather than pitting SASE and SD-WAN against each other, vendors and IT networking teams are better off treating them as complementary capabilities. Don’t let the perfect be the enemy of the good. Ignore NSASE maximalists that see cloud-based SASE suites as the only way of building secure remote networks.
