Why I Hate Multivendor SASE
|
Listen to post:
π This audio player requires that "Preferences" cookies be accepted
|
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.