If you're tired of hearing about the "new normal" post-pandemic, hold on to your knickers because some of the outcomes from COVID's business impact are here to stay. Really, it's not a bad thing and we're long overdue for an overhaul of how we identify, authenticate, connect, and authorize access for users and devices.

Here's a quick down and dirty primer comparing the new Secure Access Service Edge (SASE) architecture to our traditional perimeter security methods.

Executive View of SASE Architecture

From the 10,000-foot view, the three most pertinent points are:

1. SASE is one solution offering that's part of a larger (or longer) zero trust security strategy. As you'll see in the graphic below, SASE enforces the underlying principle of a zero trust network by not extending implicit access to resources. Meaning, what a user or a device can do or access is explicitly defined in the SASE fabric.

2. SASE is more of a service set than a single product; it's cloud-based and 'follows' endpoints and users wherever they go, or in the case of work from home -- wherever they don't go. SASE vendors do this with a global cloud PoP network so endpoints connect to the cloud to access resources, vs. connecting to a traditional on-prem datacenter and then egressing.

3. SASE is likely to deliver on promises of increased simplicity and security with decreased cost, but there will be a certain amount of vendor lock-in as well as overlap with other products related to zero trust and endpoint security that the C-suite should prepare for.

Technical View of SASE Architecture

Since this is a C-level primer, I'm not going to dive too deeply in to the nuts and bolts, but I know the CISOs and CIOs I work with, and most of you love a little technical meat.

1. From an implementation standpoint, how SASE is implemented and what it can (or can't) do is dependent in large part on the vendor. Some SASE vendors came from cloud access server broker (CASB) and secure web gateway (SWG) pedigree; others from firewall and network security. Mileage and roadmaps will vary. How they handle guest (or un-managed devices) as well as users that happen to be on-prem may also vary.

2. SASE has myriad features (vendor-dependent), with support for zero trust networking being just one. Replacing legacy VPNs terminating to on-prem datacenters is a great way to enter the SASE world, and then continue adding features as you go.
   

Graphic: SASE Architecture vs Traditional Perimeter

For those of you who haven't worked with me yet, I love to draw and doodle. I don't know about you, but I'm very visual and find a picture really is worth more than a thousand words. And who has time to read a thousand words? Here are just a few highlights of the SASE graphic.

1. On left you see a traditional network security perimeter where we may (at best) have LAN-based connections (wired or wireless) with authentication and perhaps dynamic segmentation with VLANs or downloadable ACLs. For remote access, we see a traditional VPN model with similar features to the LAN connections.

2. On the right you see a typical SASE architecture with enforcement and decision layers plus SASE elements shown in yellow. One of the benefits of this SASE architecture is to abstract from physically-defined connections (those we control at layers 1-3) and instead apply granular context-based enforcement at layer 7 for both on-prem and in-cloud resources.