Does SASE equal SSE plus SD-WAN? This question, arising from a recent email I got, shows to me how far we’ve diverted from reality here. Only one of these acronyms actually has a fairly firm definition, and even it has significant variations in implementation. The other two are media/analyst inventions, so what do we gain by trying to relate them to each other? Nothing much, but we might see a justification for looking into the whole question of network-edge.
You might see this as “S-confusion” because all the acronyms start with “S”. SD-WAN stands for “software-defined wide-area network”, SASE stands for “Secure Access Service Edge” and SSE for “Security Service Edge”. It’s SD-WAN that’s a clear product or technology name; SASE and SSE are more models than they are products, except maybe the product of analyst-think. The relationship between SASE and SSE is sort-of-explicit; the latter is presented as a subset of the former.
The original concept, SASE, was all about integrating network and security services in such a way as to be cloud-deliverable or at least cloud-friendly. However, that seems to have gone by the wayside in the specification/definition creep we see these days. In its place is a vision of the integration of security and network features in a single element, which might be an appliance or a software instance, on premises or in the cloud or network.
SSE is generally the security piece of SASE. If you subscribe to the original analyst definition, that means that it’s security-features as a cloud service set. If you subscribe to the evolving market de facto definition, it means a single place/device/software-instance where all security features are presented.
The justification for either of the two is related to, and as slippery as, the cloud connection. Analyst-speak says that the majority of new workloads will be in the cloud this year and forever more, so it makes sense to stick everything there. The truth is a lot more complicated, but to cut to the chase, the important point is that the cloud has become the de facto front-end for most applications. The rest of the application is still likely running in the data center, and will do so for quite some time, maybe forever. Remember IBM’s surprise success and the “hybrid cloud” connection? But the front-end mission of the cloud is enough for our discussion.
If applications connect to the user via the cloud, then it may make sense to have most of the application security features be part of the cloud. The same could be said for network features. However, the cloud association is IMHO not the justification for either concept, that honor goes to the nature of the user of the applications.
Imagine Case One, which is a bunch of employees in some office location. Eventually, I agree that these employees will end up using a cloud front-end component to access their applications, even though they likely went directly to the applications in the data center via their VPN before. Most tweaks in the user interface seem to be shifting to the cloud as part of a general tendency to build a flexible gateway in the cloud for every type of user. These workers, behaving like traditional branch employees, could likely be better supported in terms of either security or network connectivity using a piece of CPE connected to whatever their wide-area service was—a VPN in the traditional case.
Now imagine Case Three, which is a variable set of customers, partners, suppliers, and so forth. To presume that this group would be able/willing to acquire security/networking CPE is outlandish. They will surely be connected to a cloud front-end, and for this group a cloud instance of security/network services would be imminently sensible.
Missed Case Two, you think? No, I saved it because it falls between the two. For Case Two, imagine a mobile worker, a WFH worker, a “hybrid work” worker, or whatever you think represents a group of people who access sometimes from a fixed location and sometimes from on the road or from various locations. COVID validated this group, and the timing of the emergence of SASE and SSE coincides roughly with COVID (SASE was introduced by an analyst firm in 2019 and SSE came along after COVID). If Case Two has the effect of getting a lot of those Case One people out of the office, then CPE-based strategies become the exception, and a cloud-centric approach makes sense overall. Since that’s not yet happened, and since there are ways of connecting WFH and even mobile workers back to their home branch locations, the more general market definition of SASE and SSE seem fine.
What about SD-WAN as an element of SASE and companion to SSE? SD-WAN can add significantly to security, depending on how it’s implemented. Any virtual network technology is likely at least somewhat more secure than an open network, and if the SD-WAN is session-aware and can control connectivity (128 Technology, bought by Juniper, offers this) then arguably SD-WAN is a major security improvement. Is it enough in itself?
Probably not. More and more threats these days come from within a company, meaning that malware has compromised a computer and made it into a bad actor. Presumably it’s got some local connection permissions, and so there’s a risk it might use them to break into stuff or simply to break it. However, unless what that bad-actor system tries to do is totally within the normal session connectivity policies of the SD-WAN, the attempts at evil will leave a footprint and perhaps generate a signal.
Does “SSE” add what’s needed to get to SASE utopia? Obviously that depends. The presumption that SSE will address our cases depends not only on its implementation, but on what can be done from the connection edge under any circumstances. As I noted in my blog yesterday, security is a potential application for AI, because AI could look at network traffic holistically and detect patterns that might indicate a breach. That can’t be done by looking at one user interface from the outside.
SD-WAN implementations that offer connection control are a major positive step in network and application security. AI augmentation of that is almost certainly going to do more for security than gluing on some “SSE” element. In the end, all that may do is make “Ss” of us all.