What is Security Service Edge (SSE)?
The Security Service Edge (SSE) is an important concept for understanding the journey to Secure Access Service Edge (SASE) architecture. SSE is a term defined by Gartner referring to the evolving security stack needed to successfully achieve a SASE convergence, including technology capabilities such as Cloud Access Security Broker (CASB), Secure Web Gateway (SWG), Firewall-as-a-Service, and Zero Trust Network Access (ZTNA) that are core requirements for that stack.
What’s the difference between SASE and SSE?
But let’s zoom out a little bit and understand what needs to happen with SSE beyond the discussion of core technology requirements. We love our acronyms in tech, and we see the eyes roll and hear the sighs when we meet with customers and partners and are asked to describe Netskope’s position regarding yet another acronym—SSE—and its relevance to the bigger stories around SASE and Zero Trust. We like to steer this SSE conversation into a useful discussion of what SSE will allow us to do, when properly implemented.
What are the four core principles of SSE?
- Security must follow the data
- Security must be able to decode cloud traffic
- Security must be able to understand the context surrounding data access
- Security can’t slow down the network
In an earlier era of security, firewalls, on-premises web proxies, sandboxes, SIEMs, and endpoint security tools were the most important security inspection points. But as we all know, more and more data is beyond the enterprise firewall, which can’t understand cloud traffic anyway. If you couple that with the fact that more endpoints connecting to the web, corporate resources, and accessing data are BYOD, well, our important, but legacy control points three important control points aren’t exactly reliable for a comprehensive picture of what’s happening with our data.
If we usefully organize how SSE solves what security must do in this newer world of keeping data safe in the cloud, several principles guide our discussion.
Principle #1: Security must follow the data
We now have lots of traffic that a traditional web proxy or firewall can’t understand, and can’t really even see. We have users who are now everywhere, apps that are in multiple clouds, and data being accessed from anywhere. Given this, you have to have a security inspection point that follows data everywhere it goes. And if that inspection point non-negotiably needs to follow the data, that means the inspection point needs to be in the cloud so that its benefits can be delivered to users and delivered to the apps.
Principle #2: Security must be able to decode cloud traffic
Decoding cloud traffic means security must be able to see and interpret API JSON traffic, which web proxies and firewalls can’t do.
Principle #3: Security must be able to understand the context surrounding data access
We must go beyond merely controlling who has access to information and move toward continuous, real-time access and policy controls that adapt on an ongoing basis based on a number of factors, including the users themselves, the devices they’re operating, the apps they’re accessing, activity, app instance (company vs personal), data sensitivity, environmental signals like geo-location and time of day, and the threats that are present. All of this is part of understanding, in real-time, the context with which they’re attempting to access data.
