A house of divided brands: Uncovering SASE and SSE

The underlying technologies behind SASE and SSE must be made to work together if they are to secure the enterprise.

While alphabet soup is a staple of cybersecurity, if each acronym is tied to a clear use case the resulting thesaurus can actually be helpful. It gets tricky when vendors try to combine technologies that don’t really work together.

As times change and increasingly complex IT environments create new use cases, we’ve seen a corresponding increase in acronyms -- IAM (Identity and Access Management), CIAM (which puts Consumers first), EPP (Endpoint Protection Platform) and XDR (Extended Protection and Response) are among the more popular today. But as this lexicon expands, vendors have begun lumping together groups of disparate technologies and marketing them as a "Zero Trust" solution. The trouble is that not all these acronyms were built to work together, and a patchwork quilt of solutions can create confusion leading to poor user experiences, more security incidents and even network downtime.

Organizations may have a use case for IAM, XDR, CIAM, etc., but if they buy a mosaic of technologies that don’t fit together it isn’t worth it. Effective cybersecurity needs to be simple and contextually aware, enabling practitioners at all levels to make intelligent and proactive decisions in real-time to stay in front of security threats. Organizations are aiming to implement zero-trust strategies, but it’s been tough because while vendors may market Zero Trust solutions, actual Zero Trust strategies depend upon disparate products working together seamlessly. If all you are offering is a house of brands, your customers’ Zero Trust initiatives will fail.

You may buy something that demos well, but doesn’t actually work in reality.

This happens a lot.

Let’s look at two categories that define the roles of securing access -- Secure Access Service Edge (SASE, pronounced "sassy") and Security Service Edge (SSE) -- and how they work with one another.

Making Sense of SASE and SSE

SASE and SSE are both Gartner-defined frameworks that address secure enterprise access between business-critical assets and the end-users who engage with those resources.

SASE, defined initially by Gartner to converge network and Security-as-a-Service (SaaS) capabilities, came first. By bringing the two together in a cloud-delivered ecosystem, it can be applied to branch-office, remote worker and on-premises use cases. SASE incorporates four core technologies (each bringing its own acronyms into the mix, of course): Software-Defined Wide Area Network (SD-WAN), Secure Web Gateway (SWG), Cloud Access Security Broker (CASB) and Next Generation Firewall (NGFW). 

Gartner then defined SSE as a subset of SASE, focusing on the consolidation and delivery of secure services (including access to the web and cloud-based apps), but without the network components involved. SSE includes the same core technologies as SASE, except for SD-WAN, which many organizations didn’t really see as part of the other technologies. SSE is intended to address the increasingly distributed environments resulting from the growing use of cloud and edge computing, remote work and the adoption of Infrastructure-as-a-Service (IaaS) and SaaS. It’s typically delivered via the cloud, though it may also have on-prem or agent-based components.

It's important to note, both of these frameworks support Zero-Trust Network Access (ZTNA).

Solutions That Weren’t Made Together, Don’t Play Together

SASE and SSE may share a clear goal -- ensuring secure access -- but they typically consist of technologies from different companies that have been acquired and stitched together. It’s far from a simple solution.

Zscaler, for example, uses a completely separate console for managing private access. Symantec’s SWG and CASB may both exist under the Symantec umbrella, but they’re two separate companies, as are Forcepoint’s SSE offerings, which are pieced together through acquisitions. This ends up being more like a house of brands than a fleet of integrated technologies designed to work harmoniously together.

The three technologies SSE needs to operate make sense on paper, but they’re always an integration, not a single solution. Sales teams require significant training on how to "make it work", but if it's too complicated for internal teams to understand, can a customer make it work on their own?

Customers cycle through this process because the use cases make sense, but this Frankenstein solution falls to the administrator to implement. These technologies just weren’t made to work together -- it’s an overwhelming task. Oftentimes, the licenses go unused, and people end up not getting what they paid for.

Integrating these technologies to produce a seamless, first-class admin and user experience can be done if you have the right focus -- meeting the needs of the buyer.

Buyers' Needs Come First

Vendor success stems from buyer success -- how well can a vendor deliver a solution that effectively solves the use-cases. Ease of implementation is essential, especially as IT management grows more complex, and reliance on more tools increases.

Similarly, vendors shouldn’t produce technology simply to fit a category, nor should buyers purchase technology solely because it fits a category, especially when the solutions aren’t right for them. Rebranding a legacy technology with a new name and shiny new acronym does more harm than good. 

Instead, buyers should look for solutions tailored to their specific needs, regardless of acronyms. Vendors should strive to deliver that without compromise.

For example:

• SWG. A SWG needs to be fully truly private, performant, highly reliable and have the ability to secure roaming devices, without reliance on outdated stopover data centers. This prevents employee challenges like loss of Internet or productivity. A SWG should replace the need for the physical legacy data center and instead should rely on device enforcement for core SWG functions.
• ZTNA. ZTNA, or Private Access, in which authorized users are granted access to internal non-public resources and applications, should be delivered invisibly to the end user. Limiting access to authorized internal applications prevents scanning or traversing the network. Following this philosophy provides easier access with increased security.

It’s a Strategy, not a Solution

Acronyms, like the categories they apply to, are useful for learning about the areas they address, but learning and implementing are two different things. Buyers shouldn’t use technologies that weren’t designed to work together just because they are marketed together under a convenient brand umbrella. Vendors should build with a mindset outside of silos and one-off solutions for a single customer -- instead, they should focus on a first-class user experience that delivers exactly what’s required for buyers to secure their organizations.

Image credit: mc_stockphoto.hotmail.com/depositphotos.com

Kunal Agarwal is Founder and CEO of dope.security.