Posted on Reading Time: 3 minuteson
MEF CTO Pascal Menezes recently sat down with Craig Connors, VP, and GM for the SASE Business at VMware, and a member of MEF’s Technology Advisory Board (TAB), for an engaging discussion on a wide range of topics around software-enabled security at the network edge, including secure access service edge (SASE) and secure service edge (SSE). Below is a snapshot of that conversation.
What are the market drivers for SASE and SSE, and where does SD-WAN fit in?
Craig Connors: I think SASE is a misunderstood term. Before the pandemic and post pandemic, it really became synonymous with remote work, but that’s not what the evolution of the market was about. It was about this proliferation of distributed devices, whether it is workers in and out of the office, IoT devices, connected cars, or all of these different types of remote access devices. And then the movement of applications from centralized locations, like the data center and the cloud to the edge. So now I have devices moving from a central place to being spread all over. And SASE is all about: How do I securely connect all of those users and devices with all those applications that are running now at the edge, in the cloud, in the data center, all of these different locations?
Pascal Menezes: What you’re saying is that SASE was meant to connect all kinds of things from everywhere and secure it and give connectivity, which really is the “access” part of secure access. Then, service edge was supposed to provide cloud-based security functions. And it was supposed to be this thin CPE with SD-WAN, and then all the functions in the cloud—that was kind of the black-and-white thinking.
Between SASE on one side and SSE on the other side, they’re not really that different. To me, it’s a crawl, walk, run scenario. Is it a journey?
CC: Even though remote work isn’t the core use case that was originally set out, it is a use case that came and accelerated the market so rapidly. I was part of SD-WAN early on and watched it take six, seven years to develop. And overnight, SASE caught fire because of this rapid shift to work from home. But at the same time, in the pure analyst view, I think it led to people co-opting the term SASE for things that it wasn’t originally intended for.
SSE and SD-WAN are really the two core pieces of the SASE puzzle. And while the market is maturing rapidly, all of us vendors are either security vendors coming to the networking side, or networking vendors branching out into the security side. We’re still maturing across the stack. SASE is the final destination.
How can networking and security teams get out of their silos and work together on SASE?
CC: There is an evolution going on in organizations where it used to be a network buying decision run by the networking team, and a security buying decision run by the security team. NOC and SOC were very isolated from each other. I think a great piece of SASE that illustrates how that’s changing is zero trust network access. Some folks see it as a networking function. Some folks see it as a security service edge function. And it’s the first place we see both parties coming to the table together to talk about it and make a joint buying decision. As SASE solutions mature, we’ll also start to see network and security teams converge to be one team, one buying decision, one product offering.
What are your thoughts on bundling vs. single-vendor SASE solutions?
CC: Part of the ideal end state of SASE is the single-pane-of-glass, single-vendor solution. Service providers, as they’ve so successfully done with SD-WAN, can bundle underlay and overlay services and then project as if it’s a single pane of glass or a single vendor solution to the customer by delivering it as a fully managed solution. For example, maybe it’s Cisco and VMware under the covers. But from the customer’s perspective, it’s all AT&T.
For their full discussion, listen to the complete podcast episode SASE: Journey or Destination?