The evolution of security service edge products parallels the steps organizations are taking to become more cloud-centric as they adapt to a work-from-anywhere framework. Indeed, the evolution and emergence of SSE from the broader concept of Secure Access Service Edge makes a lot of sense.
Gartner, in introducing SSE in 2021, outlined some clear and practical reasons to separate the WAN edge side of SASE from the security edge side. For one, security and network ops are usually overseen by different teams. For another, network hardware represents a "sunk cost" that may require years before full value is achieved.
Taken together, these factors mean enterprise security and networking considerations associated with the (re)engineering of how users access services can occur on different timetables. This makes it more compelling, from both a philosophical and architectural perspective, to evaluate the security side of SASE separately from the network. Splitting them makes things easier to plan for, budget and ultimately implement.
Separating SSE and SASE -- theoretically and from a market segmentation perspective -- doesn't answer every practical question, however. In fact, it can potentially make things harder. Consider today's SASE marketplace: Vendors actively market a wide array of products -- with different features and up and down the maturity spectrum -- under the SASE umbrella. We see a similar trend emerging with SSE, and as a result, buyers are confronting a confusingly jumbled landscape. How do you evaluate SSE products to determine if they're right for your organization? What specific steps can you take to best position yourself to make the right choice and to navigate the benefits and challenges?
Let's explore some ways to evaluate security service edge products properly.
SSE products occupy a large marketplace
The most important thing to recognize is that, at least conceptually, SSE encompasses a broad sweep of potential functionalities. This might appear counterintuitive, especially since Gartner's 2022 Magic Quadrant for SSE segmented products into three distinct capabilities:
secure web gateway
zero-trust network access
cloud access security broker
The challenge is that each of these capabilities can be implemented and approached in a variety of ways. In addition, individual SSE vendors and product lines can and do offer other features beyond these three.
This makes it more compelling, from both a philosophical and architectural perspective, to evaluate the security side of SASE separately from the network. Splitting them makes things easier to plan for, budget and ultimately implement.
Consider zero trust. As most practitioners know, zero trust incorporates a host of capabilities, among them:
identity, including multifactor authentication and enhanced access controls;
network controls, such as segmentation strategies, filtering and alerting; and
endpoint hardening via antimalware and configuration enforcement.
And that's not even counting features such as remote browser isolation and firewall as a service, which Gartner noted as capabilities that also fall under the range of SSE.
What this means in practice is that it is incumbent on the buyer to drive discussions with vendors and not the other way around. Be an informed buyer to ensure what you buy corresponds with what your company needs.
Draw up a usable plan
The first step in SSE adoption is to outline a plan that includes a defined set of security goals and a strategy governing how to achieve them. This will help determine whether an SSE model fits into your security architecture. Think through your security model, evaluate how it's evolving and decide if your environment is undergoing the specific challenges that SSE and SASE address.
If your organization is like many others, it faces an increased need to support work from anywhere, is becoming increasingly externalized and is making more use of cloud. This is exactly the scenario that SSE -- and its ability to migrate security policy enforcement to a location closer to the end user -- supports.
Bu,t if your organization is not doing those things, is doing something else or has unique business or architectural needs that are higher priority, it will need to evaluate SSE products through a different lens.
Next, ensure analysis extends all the way down to the specific vendor, product and feature set being assessed. Your company's security model will dictate which features are required and the implementation strategies necessary to plug them into existing infrastructure.
Putting ducks in a row
Do your homework. Make an architectural plan, share information with stakeholders and identify -- and, ideally, document -- the capabilities expected from prospective suppliers before setting the first vendor meeting.
If you have not already done so, create a vision that captures the features your security architecture must deliver in a post-COVID-19, post-SaaS and remote-centric world. Involve stakeholders, using either a defined standard, such as The Open Group Architecture Framework, or something less formal.
The important part is that your plan and vision accomplish the following:
align to your security goals;
receive support from technical and business stakeholders;
support business goals and reduce risk; and
incorporate the existing technical foundation.
It doesn't need to be perfect, but it is helpful if your plan is specific enough to detail the security services required at the edge and the policy enforcement elements and controls necessary to satisfy your goals.
Next, determine which vendors offer the specific services you require. The research you've conducted evaluating SSE products will keep you from limiting your thinking as you talk to vendors about products and implementation strategies. Understand your specific challenges first, and use that knowledge to guide you to the vendors best suited to solving those challenges.
