SASE vs SSE – Is SASE One “A” Better?

One of the problems with acronym-defined industry “go to’s” in IT, is that they can easily be misconstrued and/or a myriad variations on a theme emerge from the original – thereby confusing the original message and meaning.

For example, I talked recently in this ‘ere blog about how many vendors playing in the SASE market appeared to have completely forgotten about the importance of the second “S” – the service element. Without that, it simply isn’t “sassy”. But another variable that does appear to have confused many people (and possibly dolphins, who knows?) is Gartner’s follow-up to SASE, approximately a couple of years later, when it deliberately left out the “A” to create a new category – SSE (Secure Service Edge). I mean, who needs secure access 😊 – So why is SSE relevant and what are the actual differences?

First, with SSE, Gartner has very much concreted the “service” element; as a simple definition, it is a subset of its longer (and older) sibling with a more limited scope of network security convergence – SWG, CASB (and DLP) and ZTNA – combined as a single, cloud-native service. And, yes, it does provide secure access to t’Interweb – SaaS-based applications, as well as specific internal apps – but does not directly address secure access overall to include WAN resources. So, family favourites such as SD-WAN, NGFWs and the somewhat fundamental network backbone are excluded from SSEs mission statement.

It would therefore be easy to think, well – since general WAN access and the network backbone are as fundamental to end user data delivery as oxygen is to my brain – what is the point in SSE? The answer is that the implications of going full-fat SASE from day one terrified a lot of ops guys (and vendors too). While infrastructure convergence is a given, it’s that choice of step by step versus full-on, wall to wall change, that SSE is offering timid IT departments. So, if you start with the SSE element of the security transformation, then bring in the convergence of the SD-WAN layer, at a later date, it creates an easier path for change in many people’s minds (and budgets).

However, talking of budgets, the most important factor, if starting down the SSE route, is to ensure that you actually CAN readily add in the bigger picture access element without having to rebuild from scratch. In this sense, it’s not unlike the scene from networks of the 90s, where IT departments were trying to rationalise their networks, introducing elements such as collapsed backbones, then realising that the solution they had chosen had fundamental scaling issues, resulting in forklift truck upgrades and starting all over again. Yes, the hardware vendors loved this – well, at least the ones who got in there with conquest sales – but the IT directors were less than impressed… Then again, I DO know someone who got sacked for buying IBM, to paraphrase that classic quote from the days of floppy disk drives. Mentioning no names, Adrian.

In other words, plan carefully and choose carefully. It would be very easy to blindly adhere to the most limited definition of SSE, in order to tick your “to do” box entry, without appreciating the need for complete visibility of the operation, for example. If you can’t see the landscape as you change it, then how can you successfully make further changes later in the procedure? Back to forklift upgrades, albeit probably virtual these days. Equally, there is little point in ignoring an optimised delivery mechanism until that delivery of apps and data grinds to a halt – then what do you do? Anyone who has read anything I’ve published over the past three decades will know that – as a Yorkshireman – optimisation (saving money) is a fundamental mantra of mine. SASE (and SSE) are all about optimisation and minimalisation in terms of how many different balls you have to juggle (I almost put vendors’ balls, but I appreciate this might read inappropriately) in order to secure your networking landscape and reduce the attack surface in one solution. One solution…

“But aren’t you simply describing SASE there” I hear you say. Well, no – going SSE initially, given the provisos described above, means you can keep your existing network and commence transformation of the security operations then, at the appropriate time, go full-fat SASE, connecting all sites, the entire, far-flung workforce and cloudy resource into a single operation – think optimised delivery, management, security and reduced TCO. The trick is in making sure that your SSE solution provider can readily deliver that full on transformation to SASE. No more forklift upgrades, virtual or otherwise…