Menu
SASE or SSE? Don’t let hype distract from enterprise priorities

SASE or SSE? Don’t let hype distract from enterprise priorities

Not every vendor is equipped to deliver the full, idealised SASE platform of integrated networking and security services, and that’s ok – not every enterprise wants, needs, or can implement that level of convergence.

Credit: Jeremy Perkins

Secure access service edge (SASE) has generated a buzz over the last couple of years, particularly in light of the pandemic and its associated surge in remote employees.

But SASE hasn’t quite materialised in the way Gartner – which first coined the term in a 2019 white paper – initially expected. In particular, there’s been pushback around the idea that SASE should be delivered by a single vendor, as a single integrated cloud service at the network edge.

The SASE model combines network security functions with WAN capabilities, delivering the security elements in the cloud and using SD-WAN at the edge or in the cloud. Key security functions include secure web gateway (SWG), zero trust network access (ZTNA), firewall as a service (FWaaS), and cloud access security broker (CASB).

Some vendors in the SASE market, most notably Cato Networks and Versa Networks, profess to offer the closest version of a one-supplier-one-platform model.

That’s the purist view of SASE. Other vendors market what they do as SASE while relying on partnerships, acquiring companies, and developing separate solution components that together create a full-stack portfolio offering.

Lately, however, there’s been a shift in thinking about how to bundle security and networking.

Gartner itself has been instrumental in a roll-back from the idea of SASE to the less-broad secure service edge (SSE) bundle, which includes CASB, SWG, and ZTNA. Gartner introduced the SSE bundling option in its 2021 Strategic Roadmap for SASE Convergence

SSE is basically the security part of the combined security and network services that were supposed to be simultaneously cared for under the SASE model. Gartner’s roll-back to SSE is really just recognising what is happening in the market and perhaps giving a little more credence to the value of a best-of-breed approach.

I see SSE as the acceptance of market forces and the recognition that there’s significant complexity in trying to deliver a range of different services in an integrated way when needs are continually changing. Not every supplier wants to or is able to deliver the idealised SASE vision. And that’s ok. It doesn’t really matter.

There’s immense value in helping everyone conceptualise the components of a credible network and security environment to best provide robust services while protecting the business; kudos to Gartner here. 

But the speed at which suppliers are embracing SSE points to how far away many vendors were from true SASE. It also illustrates that trying to shape an industry with a conceptual model is ambitious at best and can lead to misplaced hype at worst.

Picking what is going to work best for the enterprise is easier said than done. One of the challenges in the SASE/SSE space is that solutions can provide subtle or not-so-subtle differences in what they offer. Robust technical and commercial analysis is critical if they’re trying to determine the most appropriate set of capabilities available for the best pricing with as few nasty surprises or cost risks as possible.

To help get started, here are five issues for customers to consider:

1. Understanding licensing, what capabilities are included or excluded, and the basis for payment is critical

For example, what period are users committing to? What kind of flexibility is there for volume changes (such as number of users)? Additionally, unlike the hardware they might have bought in days of old, they are much more exposed to price variations and rises with software. It’s important that they fully factor in licence costs when they’re scrutinising plans and negotiating with suppliers, as well as when they’re making comparative vendor assessments.

2. What is the level of contractual flexibility?

Or, perhaps more importantly, what are the key contractual constraints that might hurt the enterprise? Be sure to consider the “what if” scenarios related to key deal components and terms and conditions. For example: How will commitments work?

What price review is built in? What happens if my demand changes dramatically? What do we do if performance doesn’t live up to billing?

Good legal counsel, knowledgeable in this space, can be invaluable; there’s no substitute for rigorous legal, commercial, service and technical review to help ensure they get the best practice arrangements in place. 

At the same time, users should also be practical in their aspirations. For example, asking for limits of liabilities that no supplier would sensibly agree to in this world of ever-changing security threats, is a classic example that can unnecessarily delay contract close-down.

3. Implementation timeframes and supplier obligations are often overlooked or least not considered thoroughly

This can be a real gotcha for the unwary. The time, cost and scope of activities to implement a solution, if underestimated, can leave users scrambling to explain to executives why they’re not on time and budget for the project.

Worse, it might feasibly leave the business exposed to service and security challenges. Working through supplier obligations and the process for implementation, the add-ons, and the optional components can save a lot of anxiety and even conflict in the relationship as solutions are rolled out. It’s best if they actively include implementation details at the outset, starting with the request for proposal (RFP) or any request for information (RFI) work.

4. Day 2 support and management arrangements need to be front and center from the outset of any procurement

If they want to avoid painful (aka costly or service impacting) ownership or scope gaps, a well-constructed statement of work (SOW) is essential.

This must include cost overheads and mechanisms for tying down commitments and unambiguous responsibilities, both for the enterprise and the supplier. Again, laying down what’s required at the start of the sourcing effort is the basis for getting the SOW outcomes they need.

It is then about the hard work needed to translate the requirements into the supplier’s documented commitments as they go through the process. Test commitments, understand the gaps, negotiate shortcomings, and then document the outcomes.

5. Assessing the business needs against the technical/solution capabilities is the bedrock for everything else

Having all parties involved in the validation of the project requirements can be extremely beneficial. Early engagement of the ultimate consumers (business users) in the procurement process is important. It can bring useful insights, help focus priorities and, at the very least, will promote better awareness of the journey being undertaken.

However, it is not always easy to strike the right balance of engagement with different stakeholders. Try to find stakeholders who will engage in the right way. If the dialogue is at too high a level, it can lead to executive “helicopter” insights that don’t necessarily translate into practical contributions. Too much at the working level or with too many stakeholders can lead to inertia from over-analysis or distractions.

There is no easy answer. It requires a balance – typically, a core group of specialists, with select stakeholders at various levels, is the most successful approach. 

One tip is to determine what level of effort all those involved can commit to (usually less than ideal) and plan accordingly so users can prioritise what is important.

Good luck.


Brand Post

Show Comments