Making Sense of SASE Trends

What do users and providers think about SASE?  Besides, perhaps, that they hate acronyms and the constant creation of “new categories” for the famous quadrant charts?  I usually try to get a feeling for this sort of question at the end of the year, because even where there’s no formal tech planning cycle at year’s end, there’s still a lot of anticipation.  The new budgets, after all, are coming.

Secure Access Service Edge is definitely draped with a healthy dose of hype.  Every vendor knows that it’s very difficult to sell anything into enterprise or service provider organizations without some editorial visibility to generate some sales interest.  Editorial mentions sell website visits, website visits sell sales calls, and sales calls sell products and services.  This direct (and cynical) connection makes it all too easy to miss some really important things that are starting to happen.  New terms, even without new concepts to back them up, generate media attention.  In the case of SASE, though, there’s a lot of reality that’s in danger of being buried in the hype.

What, first of all, is a “service edge?”  In traditional networking it used to be called the “dmarc”, short for “point of demarcation”, or the boundary between the operator service and business network infrastructure.  If you sell a service that doesn’t connect right to the user (which few business services do) then you have a problem of responsibility that can be solved only if you can point to a spot and say “my stuff starts here, and beyond that is your stuff”.

There’s still a lot of dmarc in SASE, but the SASE concept reflects the realization that connecting to the user is the real goal, whoever is responsible for it.  There’s a risk that by saying that carrier responsibility stops at a given point, an unwary buyer might think all responsibility stops there, and on-site or in-company networking is the wild west.  That’s particularly bad in a security sense, because nearly every business network today is connected to the Internet, and even non-Internet elements can be hacked.

SASE is a new kind of dmarc, a service portal that includes both traditional connection features and features that are required to make connected users and resources safe, prioritize traffic, optimize resources, and so forth.  The technical core of SASE is often SD-WAN, but it also includes web gateway security, cloud access security, firewall services, and other stuff.  It’s really this loose mixture that creates a lot of the hype and confusion on the topic.  We need to look at buyer views to get the truth.

One obvious truth is that SASE, which of course means Secure Access Service Edge, is largely about security as far as everyone is concerned.  Interestingly, though, there really isn’t a specific buyer view on how that comes about, on what makes SASE different from other kinds of service edges in technology terms.  They realize that edge security is important, but they’re hazy on how they’d get it.  Part of that may come back to the fact that SASE is functionally a bit of a hodgepodge of “product categories”, and part to the fact that the buyer has a goal but is still searching for how to fulfill it.

Beyond the obvious security point, what buyers say about SASE is that it’s comprehensive, it’s virtual, and it’s part of a harmonious vision of future services that we could call network-as-a-service or NaaS.  To understand what they mean, and what this means to the network space, we have to look at each of those terms.

“Comprehensive” is simple.  Enterprises want a secure access service edge strategy that works for all their edges, which means that it can’t be something that doesn’t handle branches, home workers, cloud hosting, data centers, or anything else that’s either a provider or consumer of services.  It’s this attribute that’s most often assigned to SD-WAN technology, but most SD-WANs aren’t secure.  In fact, security is the main thing buyers think separates SASE from SD-WAN.

The second piece, “virtual” is a bit harder to explain.  Buyers generally saw SASE more as an architecture or model that described a collection or distributed set of features, than as a single box that did everything.  They didn’t object to boxes where they needed a device, but they can’t put boxes inside the cloud and some aspects of SASE evolution seem to them to point to a more distributed model, which gets us to our next (and last) buyer point.

The third piece, a NaaS vision of the future of SASE, is more my characterization than a clear buyer-stated requirement, even though about a third of buyers will use the term at some point.  Most buyers will creep up on the NaaS notion in discussion, but not name it.  What they visualize is kind of what you could call a “cloud model”, where distributed pieces of stuff (the “virtual” part) are assembled by uniting the services these pieces create.  There’s a bit more, though.  That same third of buyers who think about NaaS are also seeing the role of SASE expand beyond security, and that may answer a lot of questions about what vendors seem to be thinking.

The clear goal, name notwithstanding, is to refine the notion of “services” by personalizing it to user and application needs.  Network as a service implies a level of customization, a means of setting enterprise priorities on user/application relationships and ensuring that the higher priorities get higher resource priorities.  In fact, prioritization or even explicit QoS is seen as part of SASE’s mission by almost all the users who recognize NaaS.  The “secure” piece is just a part of the issue of controlling information flows to ensure they meet business goals.

User-specific performance, whether it’s in priority form or in absolute QoS form, requires a way of identifying the user and what they’re doing.  In fact, what would be ideal is a framework where users and applications could both be grouped into categories that would allow for mass assignment of priority handling.  Location, home-versus-branch, role, and other factors are examples of user categories.  Many systems, including Microsoft’s Active Directory, provide a way of classifying users, but that doesn’t mean you’d be able to recognize their traffic.  It seems as though SASE evolution is going to have to lead to a place where user identification is supported at the traffic level.

That then raises a security question.  Do you base the “SA” in “SASE” on the current mechanism of intercept/blocking via firewall?  Permissive connection meets insurmountable object?  Or do you employ a zero-trust mechanism where only authorized connections are carried?  If you’re going to do explicit zero-trust security, it would make sense to have as much knowledge of both user and application as possible, so that you could infer default connection and priority settings based on what’s known about both users and the applications or sites they’re trying to access.

That raises the always-fun topic of support.  It’s always been true that to a user, “the network” was whatever wasn’t on their desk (or in their hand).  You could describe this view as a local-/distant-resource separation.  In our modern world, more and more of the experiences we’re seeking, the applications we’re running, involve distant resources.  This creates a growing problem with quality of experience management for the IT professionals who are generating what people are looking at.

A secure edge that can’t deliver applications with the appropriate levels of QoE isn’t an advance, according to a growing number of users.  In fact, over half of all buyers are concerned about the QoE impact of enhancing security.  They know they need security, but they need what they’re doing, running, viewing, to be supported, too.  If you take the security and priority/QoS stuff down to user/application granularity, the challenge of support explodes.

If users see IT as local/distant, then most of what they consider IT is out of sight, how does this impact vendors?  There seems to be a polarizing among network vendors, with most staying in their traditional lane and focusing on the transformation of the network as a connectivity framework.  The main outlier is Cisco, who may believe that by strengthening its position in cloud computing platforms, it can leverage the coming symbiotic relationship between network and cloud.

Juniper may be emerging as the most interesting player in this new game.  With their Netrounds and Mist acquisitions, they created an assurance-centric, operations-based, platform that combined with a Juniper edge to create the first “virtual SASE” model.  While the details of their handling of 128 Technology post-acquisition aren’t yet clear (because it isn’t closed yet), 128T has all the features needed to create a super-SASE solution when combined with Juniper’s other assets.  Could Juniper be thinking of a model of networking where the services themselves, and the experiences and applications the services connect with users, become the center of the network universe?  I think that may very well be what they have in mind, in which case they could become a true force in network evolution…if they get it right.

SASE is proof that the concept of dissecting unified missions into discontinuous product sets is good for analyst firms and vendors but bad for users.  The same forces that have acted to create SASE continue to operate, to add to the mission.  Might we end up with “Secure, Assured, Self-Managed, Access Service Edge”?  SASASE is a kind of catchy, musical, acronym, but I think we’re heading for “NaaS Service Edge” instead.

That might create an interesting market dynamic, because there are multiple paths to get to a NaaS.  An edge solution is logical because the edge can assemble functional pieces at the user connection point, but a deeper strategy could provide more efficiency, and introduce “cloud elements” of functionality more easily.  Whatever the pathway, it may be that the NaaS model is the real goal in the end, even for SASE.