It feels like only yesterday when we first heard about SASE. The proposition of consuming network and security services from the cloud was attractive and resonated with the market. It’s no surprise that internet service providers (ISPs) started exploring how they could offer a set of SASE services. Fast forward to today and we all are watching how Security Service Edge (SSE) as a new product category is being received by enterprises. Gartner recently announced the first-ever Magic Quadrant for SSE and ISP product management teams are discussing what SSE means for their business. Is it another competitive threat being delivered from cloud providers? Or is it an opportunity to introduce a new service to the market? Or, oh wait, what does this mean for the Managed SASE service that I just launched?
As you probably know by now, SSE is one-half of the SASE framework. It is the brain that integrates a specific set of security services such as cloud access security broker (CASB), secure web gateway (SWG), zero-trust network access (ZTNA), remote browser isolation (RBI), and a cloud firewall (CFW). The other half of SASE is made up of WAN Edge Services—SD-WAN, application optimization, connectivity, and all other things around networking. Simply speaking, SSE + WAN Edge Services = SASE.
Why service providers are well-positioned for a SASE framework
Simple logic leads us to the conclusion that if a service provider offers managed SASE, it should have SSE capabilities as a part of it. But the devil, as always, is in the details. Gartner, who coined the terms SASE and SSE, outlines the following properties of the future-proof SASE strategy based on SSE:
- Consistent policy enforcement, regardless of location
- Consolidated policy control plane
- Sensitive-data visibility and control
So, if you already offer a managed SASE service, now is a good time to benchmark your capabilities against these requirements to make sure your service goes beyond just offering separated products and meets the latest demands.
But what if you don’t have a SASE offering, however, you see market demand? Your sales department talks about customer inquiries around SASE. Your marketing department shares exciting forecasts of how the SASE market size will grow during the next five years. And as a service design authority, you stand in front of the whiteboard and ask yourself: how do I offer a compelling service? How do I use my company strengths—broad and mature connectivity services—to stay ahead of the game?
The good news is that service providers are very well positioned to bring the SASE framework to life by offering a comprehensive service. Instead of offering a patchwork of various solutions addressing niche use cases, you can use the wide reach of your network and your expertise in serving large markets to introduce a consistent service that follows the spirit of SASE—connect ANY user with ANY cloud service and guarantee data protection. You can cover all types of access technologies and provide the same level of visibility and policy management with a contractually enforced SLA. Using SD-WAN terminology, by controlling both “underlay” and “overlay” of customer connectivity you are able to offer a better SLA and solve any issues faster.
How service providers can integrate SSE capabilities into SASE
Trying to reduce time to market, you might consider positioning your current WAN Edge Services capabilities as SSE. Your current SD-WAN offering is likely to have some security capabilities, such as (Next Generation) Firewall or UTM, however, make no mistake—those capabilities alone would not qualify as SSE.
SSE goes far beyond point firewall capabilities, offering more security controls for a wider set of use cases. The combination of CASB and SWG enables building a singular policy to control cloud and web traffic for any application and any user. Remote browser isolation and zero-trust network access become a part of this policy, leveraging data context gathered by CASB/SWG. All these services are tightly integrated within SSE around the concept of data protection.
So, how do you roll out an SSE service? What customer segments do you plan to address? Are you going to use different solutions for different customer types? What technology stack should be used? Can SSE be implemented using NFV principles as a service chain of network and security VNFs or CNFs? Should it run in a public cloud, private cloud, or in a hybrid model, relying on something like AWS Outpost, Azure Stack, or Google Anthos? Or maybe it’s worth looking into existing SSE solutions and consider integrating them into your product line?
To help you answer these questions, let’s review the end-user expectations from SSE that will influence your decision process:
- Single console, single set of policies, single data lake for logs. The idea of SSE came from a market consolidation of SWG, CASB, and ZTNA components. The last thing your users want is to manage multiple products using multiple consoles and APIs. Moreover, as a service provider, you probably don’t want your operations to replicate the same policies between multiple tools, driving internal operational costs higher.
- Visibility of cloud activities that is easy to understand. Your customers would appreciate intuitive dashboards that help understand risk areas and where they should focus their attention. Which applications are used? Do employees share company data using personal SaaS instances (such as Gmail or Office365)? Where is my sensitive data? Are there any signs of risky behavior across my users? Being able to answer these questions demonstrates how you can deliver very complex capabilities in a user-friendly way.
- No performance impact with all security controls enabled. By consuming security services from a cloud provider your customers expect consistent performance, no matter where they are. To guarantee this a service provider needs to consider from which points of presence (PoP) security services will be delivered and how the PoP location impacts the addressable market. At the same time, within each PoP, performance should not depend on the type of security controls that you enable. “Single-pass” architectures should be preferred over “service chains” where user traffic passes a stack of multiple security functions in a serial way.
- Cost. According to various forecasts (1,2,3) SASE market will reach between 5 and 8 billion US dollars during the next five years and is likely going to attract a lot of players. To stay competitive, it is paramount for a service provider to find the right pricing point for the service and keep the internal costs under control. Perhaps the most important decision here is whether you are going to build out the infrastructure to deliver SSE services or partner with an existing cloud security provider. While building out your own SSE capabilities makes total sense in the long run (especially if you have already invested into NFV infrastructure), consider the following “known unknowns” that might drive your costs higher:
- VNF and CNF (network functions) license costs are usually underestimated. Common cases are single-tenant network functions and backup service chains provisioned for each customer, which requires deploying more network functions than you might have thought initially.
- The costs associated with developing NFV orchestration (VNFM and NFVO) are also underestimated. Maintenance of multiple network functions from different vendors requires diverse protocols and frameworks and usually results in a mix of APIs, logging, SNMP, streaming telemetry, and so on. It gets even more complicated if you plan to implement auto-scaling and self-healing procedures.
And then there are “unknown unknowns”, such as possible scalability limitations and unstable performance, all driving your costs higher and higher. In this case, offering SASE using your existing network capabilities and partnering with an SSE provider helps you to have fixed costs and build a more predictable business model.
Seems complex, right? Well, this is just the tip of the iceberg. However, we at Netskope are strongly convinced that SSE as a part of SASE is not a