3 ways network teams can influence SASE decisions

Secure access service edge (SASE) has gotten a lot of attention during the past two years from enterprises interested in improving their security posture, specifically as part of an effort to adopt Zero Trust frameworks.

That puts a lot of energy behind cybersecurity initiatives, but what about the network?

The fact is, the network is central to Zero Trust and to SASE. When coined by analysts, the concept of SASE rested on several functional pillars including SD-WAN, secure Web gateway, cloud-access security broker, next-generation firewall, and Zero Trust Network Access. SD-WAN is the most foundational, though—so fundamental that, whereas a SASE solution might legitimately omit other pillars and still be classed as SASE, omitting the SD-WAN turns it into something else: a secure service edge solution.

Unfortunately for the network team—and the enterprise—all the energy for SASE being centered on cybersecurity means that network staffs and network functions can get short shrift in the selection process, with the staff being looped in as an afterthought or included only in the final selection via a proof-of-concept deployment. 

But network teams have some options to get themselves to the table right at the start.

Network teams can launch SASE projects.

There are a lot of stalled-out SD-WAN projects or projects just beginning to lurch back into motion after the stall of COVID. There are also SD-WAN refreshes going on as folks get tired of their current solution or find its evolution or costs making it a less good fit than it used to be. And there are places where SD-WAN is just becoming a consideration, too.

From any of these starting points, the network team can take a live SD-WAN selection process and turn it into a SASE project instead. The big caveat: getting all the relevant cybersecurity folks to join in and buy in is crucial.

Even if the cybersecurity folks aren’t ready to roll out the security parts of SASE at the same time as SD-WAN, choosing the right SD-WAN package with an eye toward adopting the security piece down the line can save the enterprise a lot of trouble when that time comes. It can also help sharpen and accelerate the planning around the relevant security transitions.

Insist on giving input into the SASE selection.

Using SD-WAN as the anchor, network engineers and architects can demand a role in the SASE selection process from the start, making the case that a real SASE solution has to fully meet the current and anticipated needs of the WAN. If the cybersecurity folks leading the effort are reluctant, the network team should be able to make the case to the CIO and CTO that failing to include them from the start is risky. The network team needs a seat at the table to ensure that the SASE selection criteria meet SD-WAN goals and that SD-WAN use cases are woven into SASE proof-of-concept testing to minimize the risk of deploying an inadequate solution or overspending on a solution, a key piece of which will be left on the metaphorical shelf.

Make SASE a mantra.

If neither SD-WAN nor SASE projects are imminent, the network team’s best strategy is to make sure every conversation about SASE includes a mention of SD-WAN and the needs and goals of the WAN generally. If everyone in senior leadership consistently hears the network team talking about SASE and SD-WAN in a single breath, they will be much more likely to suggest network participation in the effort from the beginning rather than grafting it on later in the process.

Source