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.
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.
Relatório: Gartner – 2021 Strategic Roadmap for SASE Convergence
Blog: Understanding Security Service Edge and SASE
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.
Principle #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 dangerously begin trading off security controls for network speed and reliability. One might think that this is as simple as moving the security controls to the cloud. It’s not as simple as that. 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 that we can ensure a smooth and efficient path from the end user to their destination, and back again.
Learn More: What is a CASB?
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 percent of your security spend is for on-premises-focused security, but 50 percent of your apps and 90 percent 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 principles listed above, that the last principle 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 is not on our network, and 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 Netskope 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. If you want to learn more about Netskope’s security capabilities and how they work into a SASE architecture, check out our rundown of the Netskope Security Cloud.
Guide: Desenvolvendo uma Arquitetura SASE para Leigos
Ao enviar este formulário, você concorda com nossos Termos de Uso e reconhece a nossa Declaração de Privacidade.