Security Service Edge and Your SASE Journey

February 21, 2022

• 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.
• When you couple this with the fact that more endpoints connecting to the web, corporate resources and accessing data are BYOD, well, our important, but legacy control points aren’t exactly reliable for a comprehensive picture of what’s happening with our data.
• Netskope’s Jason Clark outlines several key tenets for organizing Security Service Edge (SSE) to keep data safe in the cloud.

Security service edge (SSE) describes the security stack requirements needed to evolve a secure access service edge (SASE) architecture, including technology capabilities such as cloud access security broker (CASB), secure web gateway (SWG), firewall as-a-service and Zero Trust Network Access (ZTNA), which are core requirements for the stack.

We love our acronyms in tech, and I see the eyes roll and hear the sighs when we meet with customers and partners and are asked to describe our position regarding yet another acronym — SSE — and its relevance to the bigger stories around SASE and Zero Trust. We like to steer this conversation into a useful discussion about what SSE will allow us to do when properly implemented.

Core Tenets of SSE

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 this with the fact that more endpoints connecting to the web, corporate resources and accessing data are BYOD, well, our important, but legacy control points aren’t exactly reliable for a comprehensive picture of what’s happening with our data.

Several important tenets guide our discussion of how to usefully organize SSE to keep data safe in the cloud.

Tenet #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 everywhere, apps that are in multiple clouds and data being accessed from anywhere. Given this, you need a security inspection point that follows data everywhere it goes. And if that inspection point 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 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.

Tenet #4: Security Can’t Slow Down the Network
Users need to get their data fast and the network has to be reliable. If security is slowing down access or operability, productivity suffers and teams dangerously begin trading off security controls for network speed and reliability. One might think this is as simple as moving the security controls to the cloud, but it isn’t. Ultimately the cloud ends up traversing a dirty place — called the internet — that can cause a whole slew of issues in routing and exposure. This is where private networks come into play so we 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 requirements, 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 of that rubber band, breaking your security. That won’t work.

You will also notice, in the four tenets listed above, that the last tenet references the network. Too often, we’ve historically had network conversations to address security problems, and that was because we often assumed that our data was on our network and that network was safe. But now our data isn’t on our network and our users aren’t 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.

We’ll go into these tenets and specific needs for SSE in ongoing Netskope blogs, podcasts, and video. I invite you to learn more about our SSE capabilities and SASE platform. Please also connect with me on LinkedIn, and let me know where your head is when it comes to SSE and SASE. The more we unpack what goes into these terms, the more we can make real, practical decisions about our people, processes and technology.