What Is SASE? Secure Access Service Edge Explained
Secure Access Service Edge, or SASE, is a term coined by Gartner that combines multiple network and security technologies into a single offering. The goal is to offer secure network services from anywhere the user connects.
We have to deal with multiple technologies that don’t necessarily work together as we think about how distributed our workloads and users are. This means multiple security policies and inefficient designs that are costly and don’t scale. With the increase of work-from-home users, there’s a huge demand for secure direct access to the cloud without having the central bottleneck and latency of VPN.
SASE attempts to solve this problem by combining security as a service with the network as a service. Gartner has laid out three levels for SASE: Core, recommended, and optional.
The SASE core levels include SD-WAN, SWG, FWaaS, CASB, and ZTNA. Recommended includes Sandbox, Browser Isolation, WAF, NAC, and NextGen AV (EDR/EPP). SASE Optional includes Wireless LAN and VPN for customers that still need those services. Here we discuss how these technologies come together and how vendors work together to bring you SAS.
Before we can dive into how SASE works, we need to understand the problem it’s trying to solve. [FACT: Work from home] A report by Gartner found that 74% of CFO’s intend to shift more employees to work from home, even after the pandemic had subsided.
The average employee in a small organization uses 8 SaaS applications as part of their business workflow. Yet, they also need access to internal resources like a softphone, file share, and other services. The traditional approach was to have users VPN into a central location where policy and inspection are applied. This creates higher latency for the user, more expensive circuits for the organization, and bigger inspection devices to handle the traffic.
Secure Web Gateway and FWaaS vendors like zScalers handled this problem by distributing the inspection engines to regional POP locations and partnering with SaaS vendors to apply security right in the cloud environment itself.
But what about when the user connects back to their corporate network? How can I leverage the advantages of SD-WAN while still have a single security policy for my users? It used to be that traffic would stay inside a traditional network
Consider a typical user working from home that occasionally also has to come into the office.
- They have applications like Office 365 that should go out directly to the internet
- They may also have applications that live in a public cloud, like AWS
- And may have applications in a private cloud that’s part of their workflow.
SASE is designed with the end-user flow in mind, and it starts with the idea of Zero Trust Network Access. Zero trust network access means that we don’t care where that user is connecting from, as long as they can verify their identification and device.
In a true ZTN, a trusted user with the appropriate access can only connect to the specific resources they are trying to access and nothing more. While there’s no specific technology necessary for Zero Trust, SDP is quickly becoming the favorite.
With SDP, an application request sets up a TLS tunnel on a per-application basis. An SDP controller sets up and tears down these 1-to-1 tunnels and uses an SDP gateway to control access.
For more information, check out my video, ‘Accomplishing Zero Trust using SDP.’ What’s important to note is that not all vendors use SDP to accomplish Zero Trust security
Zero Trust Network Access (ZTNA) is a concept to control who has access to specific resources on your network or in the cloud. The technology itself, either SDP or something else, can live on a desktop client or at network enforcement points like at the branch location or HQ. And since SASE is all about providing network and security services wherever the user is, the endpoint client is the vehicle to get our data where it needs to go. The client provides the ZTNA, along with the connectivity.
That means when a user needs access to a SaaS application like Office 365 from their home; their client recognizes the user is off-net and routes them to the nearest inspection point for security and hands it off to the application. The same logic applies when the user needs to access an internal resource hosted in a private network. They connect with the nearest inspection point, which then routes them back to the private network.
The security services like Firewalling, AV, Web Filtering, and IPS – are all happening in the cloud by the SWG provider. The SWG provider acts like the SDP gateway that allows connections to and from various resources depending on the vendor.
In the traditional VPN network, users were connecting to one central location with big security devices doing the inspection. With SASE, those inspection devices are distributed through various regions, saving the circuit size and the security device.
Most of what we’re talking about thus far is not new to you if you’re familiar with zScaler or other cloud web gateways. But what about when remote users connect back to the office? Does it make sense for users to connect to the cloud, or should they leverage SD-WAN to make the best decision? This is where SASE starts to make sense conceptually – by merging the advantages of SD-WAN and Secure Web Gateways to provide single solutions that work together.
SD-WAN plays a pivotal role in the SASE framework by service chaining the security inspection to a secure web gateway.
Now, when I have a remote user come into the office – I still authenticate them with ZTNA, but I can let my SD-WAN appliance make the best steering decision to get to its resources. That means protected VoIP calls with FEC and packet duplication; I can do QoS to prioritize traffic, latency optimization, caching, and all the other SD-WAN features we have.
We see now in the SASE market more and more SD-WAN vendors partnering with SWG vendors like zScaler to offload security. Local security inspection is always a better choice if you have the ability; needless to say, if your SD-WAN vendor doesn’t do local security – traffic is then routed out to the cloud for inspection. That said, your goal should be to leverage a solution where you only have to make a change once – and have that be consistent no matter where they connect.
Any good SASE solution should have the ability to have different off-network and on-network policies. When users get behind their corporate network, SD-WAN should be making the steering decisions. When they pack up and go home – their client should connect to the nearest POP and still leverage the same policies and security inspections behind the corporate network.
The last item in the SASE Core framework is Cloud Access Security Broker or CASB. According to a report by ESG, CISO’s reported SaaS as the top security issue in the cloud.
And with nearly every modern enterprise using some form of SaaS application for business workflows, CASB is becoming as important to your secure cloud applications as the firewall is to your network.
In the context of SASE, the Cloud Access Security Broker integrates into a single solution. This means visibility into where your SaaS applications are being used, centralizing your security policies, and even quarantining users if necessary when suspicious behavior is detected.
This involves your SASE solution to have CASB integrated into the management plan as much as possible. In some cases, it is combined with the SD-WAN or firewall to police at the network layer.
To summarize, it starts with Zero Trust Network Access – this authentication and authorization mechanism allows the user to access a resource no matter where they are. If they’re off-network, their client connects to the nearest SWG POP, where security services inspect traffic and route them to their destination.
If they’re behind a corporate network, SD-WAN steers them where they go and offload security inspection to the same secure web gateway for inspection if the SD-WAN appliance does not have built-in security.