Why I Hate Multivendor SASE
Of late, there’s talk about using multiple vendors to deliver a SASE solution. One would provide the SD-WAN and security, another the global private backbone, and perhaps a third-will deliver remote access. But is that what SASE is all about?
As the article points out, Gartner analysts defined SASE as a single, vendor cloud-native platform. In their August 2019 report “The Future of Network Security Is in the Cloud,” they wrote: “This market converges network (for example, software-defined WAN [SD-WAN]) and network security services (such as SWG, CASB and firewall as a service [FWaaS]). We refer to it as the secure access service edge and it is primarily delivered as a cloud-based service.”
In Gartner’s Hype Cycle for Network Security, 2020, the analyst firm does give a nod to “dual vendor deployments that have deep cross-vendor integration” as a form of SASE. However, I would argue that an “integrated” solution still has its faults.
The keyword in the original description of SASE is “converges.” There’s a difference between convergence and integration. Convergence conveys that network and security have been brought together onto one platform best developed by a single provider, whereas integration conveys that multiple services or appliances from two or more suppliers are tied together through APIs or other means.
Gartner calls this integrated approach a “SASE alternative” that approximates the offerings of a true SASE solution. The industry is more broadly calling it “multivendor SASE,” a solution in which customers stitch together networking and security functions from different vendors through integration.
SASE Was Defined to Address All of an Enterprise’s Requirements
As pointed out in the report, traditional enterprise network design, where the enterprise datacenter is the focal point for access, is increasingly ineffective and cumbersome in a world of cloud and mobile. Backhauling branch and mobile traffic for inspection no longer makes sense when most traffic needs to go directly to the cloud. Secure access services need to be everywhere.
By spanning all edges, applications, and traffic flows, SASE provides:
- Support for existing east-west traffic (such as WAN, site-to-site, VoIP, RDP, to on-premise apps, etc.), which is still present and will be for some time, and
- Support for both current and future traffic flows with full optimization and security.
Pulling together all networking and security functions into a single, coherent platform does more than make deployment simpler. With all traffic consolidated into one converged platform, SASE provides complete visibility that enhances security and control.
How Multivendor SASE Falls Short
Multivendor SASE, which involves taking components from various vendors and integrating them together, falls short of a truly converged solution in several ways. First is the challenge of deploying multiple devices, especially if the security stack is repeated in each branch. That’s a lot of appliances to deploy, configure and maintain.
Next is the major effort to integrate the different services and devices into a somewhat cohesive solution. The main solution provider – maybe an MSP or a telco – will take care of much of the integration, but some effort might still be on the customer’s plate. Integration is a daunting task, as the separate pieces are likely to be on different development or update cycles. Each time a patch is applied or an OS is updated, testing is needed to ensure there are no problems with the APIs or other aspects of the integration. This cycle of “update and test” adds time and cost to the solution each time one of the components changes.
Network and security management can be a challenge in a multivendor SASE solution. When there are distinct devices from different vendors, they each run their own management consoles and store data in separate formats and places. Perhaps one dominant management console is chosen to present the relevant data. However, important detail data from the individual services or devices might not be made available through that console. Moreover, alerting may be less efficient, as separate tools each want to provide their own alerts. Even if a SIEM is present to correlate the alerts, significant work is required to tune and maintain the SIEM’s correlation engine.
With the security stack being separate from the network, there is a loss of, call it data fidelity, where network security is concerned. The security tools are working from logs and not actual network flows, and so they aren’t seeing everything in full context and thus might miss indications of threats.
The Advantages of Converged, Single Vendor SASE
When all networking and security components converged into one platform, great synergies can be achieved.
All traffic on the network needs to be inspected by various devices to know how to treat that traffic. The WAN needs to know how to route the traffic. The firewall needs to know how to process the traffic based on numerous policies. Different security devices need to know if the traffic harbors threats, or if sensitive data is being exfiltrated. Each of these functions need to inspect traffic that is not encrypted. With Cato, the network and security are converged, so the traffic can be decrypted one time, inspected by all necessary functions, and then re-encrypted. Contrast this to a multivendor SASE that decrypts/re-encrypts traffic multiple times as it passes through each individual service or device. The converged SASE approach is much more efficient and doesn’t impact overall performance.
Having network and security all on one platform, in the same data flow, has the advantage of deep visibility when it comes to threat detection. The security inspection tools see everything on the network, not just logs. This provides deep and broad context – in Cato’s case, the context of all customers, not just one – to understand everything that is happening on the network and catch threats earlier in the kill chain.
As for integration, there is none. Cato’s entire SASE code base is one stack. It allows us to be very agile when it comes to updates, enhancements, and introducing new features. We don’t depend on third parties’ development lifecycles as a multivendor SASE solution must do.
Multivendor SASE Isn’t SASE At All—It’s Merely an Alternative
When it comes down to it, what the industry is calling “multivendor SASE” isn’t really SASE at all. It’s simply a way to allow traditional network or security vendors to bolt onto their current solutions to provide services that are similar but far short of true SASE.