What Is SASE? — A Buyer’s Guide
Update: Gartner is now supporting the service chained products they once warned about.
What is SASE?
Secure Access Service Edge, known as SASE (and pronounced “sassy”) is a cloud-based network architecture that combines multiple network and security functions into a single service.
Secure access service edge (SASE) delivers converged network and security as a service capabilities, including SD-WAN, SWG, CASB, NGFW and zero trust network access (ZTNA). SASE supports branch office, remote worker and on-premises secure access use cases. SASE is primarily delivered as a service and enables zero trust access based on the identity of the device or entity, combined with real-time context and security and compliance policies.
Gartner glossary
SASE is important because work environments have changed. Now that remote work and cloud-hosted architecture is popular, the traditional method of network access is no longer secure. Since every device and access point is a potential avenue of cyber attack, SASE has become crucial for organizations to implement into their infrastructure.
This post is going to do the following:
- Discuss the problematic focus on SASE components
- Discuss SASE’s defined results
- Explore how organizations get to said results
Update: What’s changed?
We want to address that Gartner has changed their position on SASE solutions. While their original blog post may have been deleted due to a shift to Insights, it’s curious that they didn’t preserve the original blog posts. Furthermore, the original SASE introductory blog post warns against the products currently on Gartner’s list of single-vendor SASE offerings.
The Problematic Focus on Components
Keep in mind what Gartner also said in their original SASE introduction blog post:
“Be wary of vendors that propose to deliver services by linking a large number of features via VM service chaining, especially when the products come from a number of acquisitions or partnerships. This approach may speed time to market but will result in inconsistent services, poor manageability and high latency.”
Update: We used a WebArchive link because Gartner has deleted the original blog post.
If you take a look at each of the single-vendor SASE solutions, the providers have bundled up networking and access control components with service chaining. This is exactly what Gartner warned about. These products are daisy-chained services Frankenstein’d together into the semblance of a true SASE solution: “see, we have the arms and legs here, the torso here, and if you ignore the stitching, there’s the head right there!”
But SASE isn’t about the components — it’s an infrastructure set up to achieve intended results. This emphasis on the components causes practitioners to lose sight of why they wanted SASE for their organization in the first place: supporting the organization’s zero trust access needs based on identity, context, and policy.
These are the intended results. The components don’t actually matter so long as you achieve the results. If you have fewer components while achieving the same results, you’re efficient. If you implemented too many components to achieve the same results, you’ve produced waste by giving the organization more components to track and maintain. Too many organizations make the mistake of focusing on the components in their eagerness to implement SASE — and sometimes the solution they implement doesn’t even accomplish the results!
The above complaints will seem familiar to admins and ticket resolvers because too many vendors did exactly what Gartner cautioned. Throwing ingredients together doesn’t result in a good cake, and chaining multiple components doesn’t always make a good SASE solution either.
What are the components of SASE?
A common question, but too often asked for the wrong reasons. Don’t lose sight of why you’re implementing SASE — it’s not for the components! Instead, practitioners should focus on Gartner’s defined results and ask themselves: “Does adding this component improve one of the following SASE capabilities?”
- Identity of the entity
- Real time context
- Security and compliance policies
To evaluate whether implemented components enhance any of the three pillars of SASE, practitioners should focus on whether the component can accomplish the specific function required for the resources being protected. For example, a CASB component can enforce access policy based on identity for cloud services, which aligns with the identity pillar of SASE.
This approach of evaluating components based on their ability to achieve desired outcomes is more practical and useful for practitioners, as well as executives who are interested in seeing results. Rather than listing out all the different components included in a bundled service, practitioners should focus on demonstrating how their implemented solution components aligns with the three pillars of SASE.
By prioritizing a results-oriented approach, practitioners can avoid getting bogged down in details that may not be necessary for their specific implementation, such as whether or not a SD-WAN is needed. Ultimately, the SASE implementation checklist should focus on demonstrating how the implemented solution achieves the desired outcomes of the three pillars, rather than just listing out the components included in the bundled service.
What’s the difference?
Here’s an example. Your SASE implementation checklist should not look like:
| SASE Component | Do we have it? |
| Cloud Access Security Broker (CASB) | |
| Secure Web Gateway (SWG) | |
| Software Defined Wide Access Network (SD-WAN) | Note: talking to potential vendors |
| Virtual Private Networking (VPN) | |
| Firewall as a Service (FwaaS)/Next-Gen Firewall (NGFW) |
This is just a checklist of item components. It doesn’t answer “why did we need this?” Assembling the pieces and applying them to your infrastructure doesn’t necessarily accomplish SASE, and in many cases there’s too much overlap. These days, what type of second-rate CASB hasn’t muscled in on the NGFW market? If you have a CASB, do you even need the NGFW?
Wait, why are we asking this again? Oh right: results.
Your SASE implementation checklist should look more like:
| SASE Pillar | Which tool(s) are we using to achieve this? |
| Identity of the entity | [Tool name]: [Reason why it achieves the result] |
| Real time context | [Tool name]: [Reason why it achieves the result] |
| Security and compliance policies | [Tool name]: [Reason why it achieves the result] |
This is easier to explain to the organization. Moreover, if a tool doesn’t work you know exactly what pillar it was intended to fulfill, so you can look for the replacement with a focus on purpose, not component category.
This is called results-oriented evaluation.
Results-Oriented Evaluation
Many practitioners lose sight of why a tool is needed and then the executive/finance department is confused as to why all of this needed to be procured. That’s why you start with the results you’re targeting, so you can explain whether or not you’ve achieved SASE.
Just because a component “can” do all of the network security functions and WAN capabilities doesn’t mean it’s a SASE solution. Using Gartner’s own definition and results-oriented evaluation structure, we’ll trial-by-fire Pomerium: does Pomerium proxy fulfill the three pillars of SASE solution?
Identity of the entity
Gartner purposefully used the word “entity” and not “user” to encompass all the possible things making requests within a SASE infrastructure. Broadly, they fall under: user, device, and machine. These identities are important to establish before granting access to sensitive corporate data and resources.
Pomerium has all three:
- User Authentication (via IdP)
- Device Identity
- Machine Identity (via service accounts)
Identity always needs to be established for the rest of this to work, and far too many solutions stop at merely establishing identity when granting initial access.
Result — Identity Pillar: ✅
Real time context
The “real time” is easy; Gartner states that SASE solutions need “continuous monitoring of sessions for risk and trust levels.” Simply put, the access shouldn’t be merely granted and then the session untracked; it should be constantly monitored and access revoked if the session starts taking questionable actions.
Does Pomerium achieve real time continuous monitoring of sessions for risk and trust levels?
We’d argue we go beyond continuous monitoring with continuous verification. No, this isn’t semantics:
- Monitoring — hey, watch the kid inside the playground and make sure he doesn’t go on the slide
- Verification — hey, make sure that’s Bob inside the playground and make sure Bob doesn’t go on the slide
What about “context?”
As user credentials can be stolen, devices can be compromised, and session tokens can be pilfered, SASE infrastructure should be continuously monitoring (and verifying) access to ensure all the actions make sense. Perhaps the user’s status has changed, the user’s location seems questionable, or the requests themselves do not make sense in the context of the user’s normal workflow. Our users integrate Pomerium with external data sources to help their SASE infrastructure make context-aware access decisions in real time.
Result — Context Pillar: ✅
Security and compliance policies
After you know who it is (identity) and you can keep track of them (real time context), you make a decision: do you allow them to do that?
Policies are the rules and criteria upon which access is granted, denied, or revoked. It is the basis for decision-making:
- Bob can have ice cream on the weekends, but only if Bob finishes his chores. Example: Bob has finished his chores. — Ice cream request granted
- If Bob does not maintain his manners while eating ice cream, take away the ice cream. Example: Bob said: “[Expletive deleted], this ice cream good.” — Access to ice cream revoked
For many vendors and tools, this is probably the easiest pillar to achieve. Pomerium uses Pomerium Policy Language to get this done, allowing administrators to declare fine-grained access policies.
Then there’s compliance — for most companies, auditing and logging is a pain. You’ve written and set out policies, but were the policies followed correctly? Did it work? Why or why not? That’s why Pomerium includes request-based audit logs, leaving no question unanswered and satisfying all compliance mandates.
Result — Policy Pillar: ✅
Feel free to apply what we did to your SASE solution. Many of you will find overlapping components, so you’re overpaying. Some of you may find gaps, so your SASE solution is incomplete.
ROE Results…
So our users’ checklists look like this after they’ve implemented Pomerium:
| SASE Pillar | Which tool(s) are we using to achieve this? |
| Identity of the entity | Pomerium: Integrates with Okta and Google SSO |
| Real time context | Pomerium: Integrated with multiple internal tools for context |
| Security and compliance policies | Pomerium: Pomerium Policy Language, Pomerium audit logs |
There you have it.
Oh, and for those who want to get into the weeds, the components checklist looks like this:
| SASE component | Do we have it? |
| Cloud Access Security Broker (CASB) | , Pomerium |
| Secure Web Gateway (SWG) | , Pomerium |
| Software Defined Wide Access Network (SD-WAN) | No need, have Pomerium |
| Virtual Private Networking (VPN) | No need, have Pomerium |
| Firewall as a Service (FwaaS)/Next-Gen Firewall (NGFW) | , Pomerium |
Want to get deeper in the weeds for how Pomerium works in your SASE goals? Reach out to us and let’s talk.
Want Pomerium Core for all your other access needs?
If you just want to start implementing access control to sensitive resources today, Pomerium is an open-source context-aware proxy to secure access to applications and services. We have a Pomerium Best Practices for teams looking to take their SASE implementations to the next level.
Our users depend on Pomerium to secure zero trust, clientless access to their web applications everyday. You can check out our open-source Github Repository or give Pomerium a try today!
