Delivering a true secure access service edge (SASE) platform requires rethinking decades of networking and security principles and embracing cloud-native architectures — something few vendors today can claim, according to Cato CMO Yishay Yovel.
The Gartner-coined product category, which combines elements of SD-WAN, cloud-based security, and edge computing, has gained significant traction in the two years since its inception. In the wake of the COVID-19 pandemic, SASE’s remote access functionality and low barrier to entry made it an attractive option for enterprises grappling with the rapid shift to remote work.
And within months of the first lockdown orders going into effect, nearly every SD-WAN and security vendor had announced a SASE security architecture, either through internal development, partnerships, or acquisitions.
But in order to bring a product to market in time, many competing vendors have taken shortcuts, effectively pushing virtualized appliances into the cloud, Yovel said.
Old Architectures Mean the Same Old ProblemsAt the heart of Yovel’s argument is that SASE services must be built on a cloud-native architecture and distributed across multiple edge locations.
While several vendors including Cisco and Fortinet have bucked this notion, arguing that networking and security appliances still have a role to play both at the branch and the edge, it's a principle that’s reflected in Gartner’s own literature and wholeheartedly embraced by Cato’s own offering.
Yovel claimed many competing vendors — specifically calling out Palo Alto Networks — have opted to push virtualized remote access, security, and networking appliances into the public cloud, rather than rework them into a unified cloud-native platform.
“The feeling I have is that a lot of the market is trying to talk about SASE now in a generic way, like everybody has everything, or everybody has the same capabilities, and it doesn't matter exactly how they're done,” he said, adding that just because a vendor claims to offer the full SASE software stack, doesn’t mean it's been implemented in a way that’s scalable.
This approach can be especially limiting for vendors relying on public cloud providers for networking and compute resources, he explained. Because many of the SASE functions — cloud-based firewalls in particular — are compute-intensive, they usually have to be run in cloud data centers and can’t run on the cloud provider’s more numerous content delivery network edge locations.
This dramatically limits the number of locations a SASE vendor can offer if relying on public cloud infrastructure. For example, Google Cloud claims services in 146 edge locations around the globe, but only operates 21 global data centers, which it refers to as regions.
Scalability and availability are another challenge, Yovel noted. In many cases, these virtual appliances aren’t multi-tenant and have to be assigned to a specific customer account, resulting in additional resources being required should the customer bump up against the limits of a single instance.
“Essentially the cloud for Palo Alto [Networks] is a shortcut. ‘I need to reach global distribution with my solution, so I need someone that has global presence. Oh, GCP is a good choice. Let's put our firewalls in GCP,’” he said. “You solve the global distribution problem but all the architecture is simply wrong.”
Finally, Yovel argues that unless a vendor’s SASE software stack is unified, customers may miss out on the ability to share context across multiple security or network functions.
He explained that many functions, SD-WAN for example, are only aware of certain contexts like what application is being used, but this context could be used in conjunction with other contextual information like time, location, or identity to inform other parts of the SASE stack.
“We collect all the context elements. It doesn't matter which part of these engines need them. Everything is built into a unified thing,” Yovel said.
Orbiting in Cato SPACEAccording to Yovel, Cato has sidestepped many of these challenges by building a unified cloud-native networking and security service, which it calls the single pass cloud engine (SPACE).
Each SPACE contains the full SASE software stack, runs as microservices on a single processor core, and can process up to two gigabits of traffic with all security functions enabled, Yovel claims.
Cato achieves this by load balancing all traffic coming into the point of presence (PoP) across all of the SPACEs, regardless of who the customer is. This enables Cato to automatically recover from failures and seamlessly scale as demands change, he explained.
“There is no direct connection between the SPACE and the customer,” he added. "In order to make sure that there are no things that create rigidity in the load balancing and high availability, every flow must be able to get into any SPACE."
Instead, each customer’s policy information is wrapped up with contextual details like application, user identities, location, and time, which tells the SPACE what to do with that specific traffic flow.
This architecture extends to Cato’s entire network of SASE PoPs as well.
“We have 65 PoPs that are connected to 50 PoPs at any given time,” Yovel said. “They have thousands of users, hundreds of locations, clouds. Basically they are connected to whatever makes sense in terms of proximity, and it’s all dynamic.”
The benefits of the architecture extend well beyond scalability and reliability, he added, explaining that because each SPACE can serve multiple customers, they aren’t stuck paying for something when they’re not using it.
Comments