Security Service Edge: 4 Core Tenets for Your SASE Journey

The security service edge (SSE) is an important concept for understanding the journey to secure access service edge (SASE) architecture. Gartner created the term SSE to refer to the evolving security stack changes needed to successfully achieve a SASE architecture. SSE includes 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.

We love our acronyms in tech, and I see the eyes roll and hear the sighs when we introduce yet another one. But let's zoom out a little bit and understand what needs to happen with SSE beyond the discussion of core technology requirements, and examine its relevance to the bigger stories around SASE and zero trust.

In an earlier era of security, the most important security inspection points were firewalls, on-premises Web proxies, sandboxes, security information and event management (SIEM) systems, and endpoint security tools. 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 data are BYOD, legacy control points don't provide a comprehensive picture of what's happening with our data.

To analyze how SSE solves what security must do in this newer world of keeping data safe in the cloud, several tenets guide our discussion.

Tenet #1: Security Must Follow the Data
We now have lots of traffic that a traditional Web proxy or firewall can't understand or 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 nonnegotiably 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.

Tenet #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.

Tenet #3: Security Must Be Able to Understand the Context of 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 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 geolocation and time of day, and present threats. All of this is part of understanding, in real time, the context with which they're attempting to access data.

Tenet #4: Security Can't Slow Down the Network
The user needs to get their data fast, and the network has to be reliable. If security is slowing down access or operability, productivity suffers and teams will begin trading off security controls for network speed and reliability. One might think keeping security fast is as simple as moving the security controls to the cloud — but it's not that simple. Ultimately the cloud ends up traversing a dirty place called the Internet, and that can cause a whole slew of issues in routing and exposure. This is where private networks come into play; they can ensure a smooth and efficient path from end user to destination, and back again.

SSE Is All About Getting Leverage Back
Because of all these needs, your traditional perimeter has disappeared, and you have to move your inspection point. SSE provides that inspection point — or rather many distributed inspection points that get as close as possible to where and how data is accessed, whether it's in the cloud or a private application.

This has profound implications for how you design security and infrastructure, and why we now need SSE and SASE to help us get organized. Think of it this way: If 90% of your security spend is for on-premises-focused security, but 50% of your apps and 90% of your users are off-premises, your security is already being stretched like a rubber band. You're trying to pull security from the on-premises model into all of these other things it wasn't designed for, creating tension for the business and leading to an eventual snap that breaks your security. That won't work.

You will also note that the last tenet listed above references the network. Too often, we've historically held network conversations to address security problems, and that was because we often assumed that our data was on our network and that the network was safe. But now our data is not on our network, and even our users are not on our network. This doesn't obviate the need for network security or marginalize the importance of things like access control. It just means that some of the lines are blurring, and we need to account for that.

With SSE, your Internet inspection points are in place, you're consolidating your cloud and Web and data inspection capabilities, and, crucially, all of those inspection capabilities are firing off atomically — all at the same time, not sequentially or one at a time.