How SASE Vendors Design Their Solution - Part 1 The Pillars of SASE Architecture
How SASE Vendors Design Their Solution - Part 1: The Pillars of SASE Architecture
The promise of the Secure Access Service Edge (SASE) is to deliver a converged, high-performance security and networking stack from the cloud. The architectural decisions made by a vendor are the most critical factor in delivering on this promise. At the core of a purpose-built SASE platform lies a multi-tenant cloud architecture. This isn’t simply about hosting virtual machines in the cloud; it’s about building a service from the ground up where a single, unified software stack serves all tenants simultaneously. This design is inherently efficient. Resources are shared, updates are seamless across the entire platform, and the service can scale dynamically to meet demand without the need to spin up dedicated virtual appliances for each customer or for each discrete security function. 🚀
The most elegant and efficient SASE designs employ a Single-Scan Multi-Action (SSMA) engine. With SSMA, that stream of data is inspected in memory, in a single pass. As that single inspection occurs, the engine can apply all security policies at once: Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), Data Loss Prevention (DLP), and threat prevention. This single-pass approach is the architectural lynchpin for performance. Because the data is not written to disk or duplicated for different security services, latency is minimized. The processing overhead is drastically reduced, allowing the platform to handle enormous volumes of traffic, even with full SSL/TLS decryption enabled, without a noticeable impact on user experience. This is the “good” design–an integrated, high-throughput data plane built for the scale of the modern enterprise. 🌐
However, not all SASE solutions are created equal. Many legacy SASE providers, often evolving from disparate product lines, have resorted to “stitching” together their services in the cloud. This approach, known as service chaining, is the architectural opposite of SSMA. In this model, each security function–firewall, DLP, sandboxing–runs as a separate virtual machine (VM) or container. To apply a full security stack, a user’s traffic must be passed sequentially from one virtual appliance to the next. Some vendors even use outdated protocols like the Internet Content Adaptation Protocol (ICAP) to redirect traffic between services. This design is fundamentally inefficient and creates a host of problems, including increased latency, operational complexity, and throughput bottlenecks. Each “hop” between virtual appliances adds latency, and packets are often duplicated, decrypted, and re-encrypted multiple times, compounding the performance penalty. The overall throughput of the system is limited by the slowest link in the service chain. This stitched-together approach is the “ugly” secret of many first-generation cloud security vendors. It’s a relic of the on-premises world, ported to the cloud without a fundamental redesign. ⚠️
The choice between these two architectures represents a critical trade-off. While service chaining may have allowed vendors to get to market quickly by repurposing existing products, it sacrifices the performance, scalability, and operational simplicity that are the hallmarks of a true SASE platform. Ultimately, the architectural foundation of a SASE vendor’s solution dictates its ability to deliver security without compromise. A true SASE architecture is purpose-built for the cloud, while a stitched one is merely cloud-hosted.