Chapter 1: The SSE/SASE Landscape and Why Cisco Secure Access Exists
Learning Objectives
Explain the market shift from perimeter/VPN security to Security Service Edge (SSE) and SASE
Describe the business and technical problems Cisco Secure Access is designed to solve
Position Cisco Secure Access within the broader Cisco security portfolio
Pre-Reading Check — From Castle-and-Moat to Cloud-Delivered Security
1. The castle-and-moat model rested on two assumptions that later collapsed. Which pair correctly names them?
2. Why is "perimeter erosion" a problem specifically for the castle-and-moat design rather than just a general trend?
3. A remote user in Denver reaches Salesforce over a full-tunnel VPN routed through a New Jersey data center. What is the core problem this illustrates?
4. Why does broad, network-level VPN access create security risk beyond mere over-provisioning?
5. Direct-to-cloud access fixes backhaul latency but "blinds" the central inspection stack. How does cloud-delivered security resolve this false choice?
1. From Castle-and-Moat to Cloud-Delivered Security
Key Points
For ~30 years, security followed castle-and-moat: a hardened perimeter around a trusted internal network, with a few gates (internet edge, VPN concentrator, branch) to guard.
Two founding assumptions collapsed — apps moved to SaaS/public cloud and users moved to remote/hybrid work — producing perimeter erosion: the moat now guards an increasingly empty castle.
Legacy VPN preserved the model but granted broad network-level access (enabling lateral movement) and forced backhaul/hairpinning of cloud-bound traffic through the data center.
Direct-to-cloud (split tunneling, local breakout) fixes latency but leaves traffic uninspected — a visibility blind spot.
Cloud-delivered security moves the security stack to global PoPs near users, ending the false choice between performance and protection.
The castle-and-moat model treated everything inside the corporate LAN and data center as trusted and everything outside as untrusted. It worked when both the applications and the users lived inside the perimeter. As SaaS (Salesforce, Microsoft 365) and public cloud pulled applications out, and remote/hybrid work pulled users out, the "inside vs. outside" boundary stopped being meaningful — this is perimeter erosion.
The traditional bridge back into the castle was the VPN (e.g., Cisco AnyConnect). Once the tunnel was up, the user was effectively "inside," and the central firewall/proxy/IPS could inspect their traffic. But VPN grants network-level access — broad reach across subnets and servers — which is exactly what an attacker exploits for lateral movement after compromising one credential or device. To inspect remote traffic, the model also forced it back through the data center, producing backhaul/hairpinning: a Denver user reaching cloud Salesforce first crosses the country to a New Jersey data center and back, paying two cross-country round trips.
The moat around an empty castle: you fortified the castle, but the treasury moved to a bank across town, the workers went home, and the merchants set up in the city marketplace. Guarding the gate no longer guards anything that matters.
Because the detour is annoying, users disable the VPN or IT enables split tunneling, sending internet/SaaS traffic directly out — direct-to-cloud access. That is great for performance but blinds the central inspection stack. The industry's insight: this is a false choice. Move the security stack itself into the cloud, close to users and apps, and traffic can go direct-to-cloud and be fully inspected at the nearest point of presence (PoP). That is cloud-delivered security.
Castle-and-Moat + VPN vs. Cloud-Delivered Security
Dimension
Castle-and-Moat + VPN
Cloud-Delivered Security
Where security is enforced
Central data-center appliances
Distributed cloud PoPs near the user
Path to SaaS
Backhaul / hairpin through DC
Direct-to-cloud, inspected at nearest PoP
Access granularity
Network-level (broad)
Application-level (least-privilege, ZTNA)
Trust basis
Network location ("inside the LAN/VPN")
Identity + device posture + context
Direct-to-cloud traffic
Uninspected (blind spot)
Fully inspected at the edge
User experience
Latency, bandwidth bottlenecks
Low latency, local breakout
Animation: The Perimeter Dissolves — Castle-and-Moat → Direct-to-Cloud
Watch the trusted moat fade as apps and users move outside it, then re-form as direct paths to the cloud.
Figure 1.1: VPN backhaul (hairpinning) vs. cloud-delivered direct-to-cloud path
flowchart LR
subgraph Legacy["Legacy VPN Backhaul"]
direction LR
U1["Remote User (Denver)"] -->|VPN tunnel| DC["Data-Center Firewall / Proxy (New Jersey)"]
DC -->|inspect, then exit| SF1["Salesforce (Cloud)"]
SF1 -.->|return path| DC
DC -.->|return path| U1
end
subgraph Cloud["Cloud-Delivered Security"]
direction LR
U2["Remote User (Denver)"] -->|local internet| POP["Nearest Cloud PoP (inspection)"]
POP -->|direct-to-cloud| SF2["Salesforce (Cloud)"]
end
Post-Reading Check — From Castle-and-Moat to Cloud-Delivered Security
1. The castle-and-moat model rested on two assumptions that later collapsed. Which pair correctly names them?
2. Why is "perimeter erosion" a problem specifically for the castle-and-moat design rather than just a general trend?
3. A remote user in Denver reaches Salesforce over a full-tunnel VPN routed through a New Jersey data center. What is the core problem this illustrates?
4. Why does broad, network-level VPN access create security risk beyond mere over-provisioning?
5. Direct-to-cloud access fixes backhaul latency but "blinds" the central inspection stack. How does cloud-delivered security resolve this false choice?
Pre-Reading Check — Defining SSE and SASE
1. Which equation best captures the Gartner relationship between SASE and SSE?
2. An enterprise already has mature SD-WAN and wants to modernize only its security. Which does the chapter suggest it primarily needs?
3. Which of the four SSE pillars is the direct antidote to legacy VPN's broad-network-access problem?
4. Why does CASB exist as a distinct pillar when SWG already inspects web traffic?
5. What does "convergence" — the organizing principle of SSE/SASE — actually collapse?
2. Defining SSE and SASE
Key Points
Gartner (2019):SASE (Secure Access Service Edge, "sassy") — a cloud-native architecture that converges networking (SD-WAN) and security into one unified service applying zero trust.
Gartner (2021–2022):SSE (Security Service Edge) — the security-only half of SASE. The arithmetic: SASE = SD-WAN + SSE.
SSE's consensus core is SWG + CASB + ZTNA, commonly expanded with FWaaS plus DLP, DNS security, and RBI.
ZTNA grants per-application, least-privilege access (antidote to broad VPN); CASB controls SaaS where SWG alone falls short.
Convergence replaces multi-vendor point-product sprawl with one cloud platform and a shared policy plane — which is why SSE is usually the first phase of a SASE journey.
Gartner introduced SASE in 2019 as the convergence of networking (SD-WAN) and security. Around 2021–2022 it carved out SSE as the security-only subset. The simplest mnemonic is arithmetic: SASE = SD-WAN + SSE. SSE is the toolkit enterprises reach for first when modernizing.
Foundational — you cannot be an SSE platform without strong SWG
CASB (Cloud Access Security Broker)
API + inline control of SaaS: shadow-IT discovery, sharing/access policy, data protection
So much data moved to SaaS that SWG alone cannot fully control it
ZTNA (Zero Trust Network Access)
Identity-centric, per-application access to private apps; continuous verification
Direct antidote to legacy VPN's broad network access
FWaaS (Firewall-as-a-Service)
Cloud-delivered L3/L4 firewall, app control, often IPS/advanced threat protection
Removes on-premises firewall appliances from branch/DC
Minimum SSE core is usually cited as SWG + CASB + ZTNA; the expanded core adds FWaaS plus DLP, threat protection, and sometimes RBI, sandboxing, DNS-layer security, and DEM. Cisco's SSE sits at the expansive end. (Note: any Magic Quadrant vendor rankings mentioned in the chapter are lower-confidence and should be verified against the current Gartner report.)
Convergence is the deepest idea: security functions converge with one another (one platform, one policy plane instead of four consoles) and networking converges with security (SD-WAN unified with the security stack). That is why many organizations treat SSE as the first phase of a SASE journey — replace VPN with ZTNA, consolidate SWG/CASB/DLP, then later add SD-WAN.
1. Which equation best captures the Gartner relationship between SASE and SSE?
2. An enterprise already has mature SD-WAN and wants to modernize only its security. Which does the chapter suggest it primarily needs?
3. Which of the four SSE pillars is the direct antidote to legacy VPN's broad-network-access problem?
4. Why does CASB exist as a distinct pillar when SWG already inspects web traffic?
5. What does "convergence" — the organizing principle of SSE/SASE — actually collapse?
Pre-Reading Check — Where Cisco Secure Access Fits
1. Which legacy-to-converged mapping is correct for Cisco Secure Access?
2. What is Cisco's central differentiator in how customers adopt Secure Access, versus pure-play SSE competitors?
3. Why does it matter that Secure Access is "one service within the Cisco Security Cloud" rather than a standalone product?
4. In Cisco's formula, what completes full SASE beyond the SSE core, and how flexible is the networking piece?
5. A practitioner notes Secure Access FWaaS is optimized for user/branch egress. What is the honest implication?
3. Where Cisco Secure Access Fits
Key Points
Secure Access is an evolution, not an invention: the cloud side grew out of Cisco Umbrella (SIG) — DNS, SWG, CASB, cloud firewall — re-architected into a unified zero-trust SSE.
The endpoint side converges AnyConnect + the Umbrella Roaming Client (EoL April 2025) into one modular Cisco Secure Client (VPN + Umbrella/DNS + ZTNA modules).
Cisco's differentiator is a low-friction, parallel-run migration (often under an hour) — evolve, don't rip-and-replace.
Secure Access is a core service of the Cisco Security Cloud, sharing a policy plane and telemetry with Duo (MFA/identity), ISE (SGTs), XDR (detection), and ThousandEyes (DEM).
It anchors single-vendor SASE: SASE = SD-WAN + SSE + DEM, deployable standalone or unified with Cisco/third-party SD-WAN. Flagships: Cisco+ Secure Connect and AT&T SASE with Cisco. Backed by ~1 Gbps/IPsec tunnel, ECMP 8–10 tunnels/site, and FedRAMP Moderate.
On the cloud side, Umbrella became Secure Access. Umbrella began as DNS-layer security and grew a full SIG (Secure Internet Gateway) stack — SWG, CASB, cloud firewall. Secure Access repackages those into a unified zero-trust SSE and extends them with embedded ZTNA (client-based and clientless), enhanced "DNS Defense," DLP, and AI-assisted detection, under one control plane. On the endpoint side, AnyConnect became Cisco Secure Client, which also replaces the Umbrella Roaming Client (EoL April 2025).
Secure Access sits inside the broader Cisco Security Cloud: Duo supplies MFA/identity as the SSO front door for SWG and ZTNA decisions; Cisco ISE contributes Secure Group Tags (SGTs) for segmentation context; XDR + Threat Intelligence consume Secure Access telemetry for detection-and-response; and ThousandEyes provides Digital Experience Monitoring (DEM). The value is that a policy or event in Secure Access can be correlated across identity, segmentation, detection, and performance because they are one platform, not four disconnected tools.
On positioning: on its own, Secure Access is the SSE half. It becomes full SASE as SASE = SD-WAN + SSE + DEM, offered as single-vendor SASE whose design virtue is modularity — deploy standalone as SSE, or unify with Cisco SD-WAN (Meraki/Catalyst), third-party SD-WAN over IPsec (Fortinet, VMware, Aruba), or direct internet access. Flagship unified offerings are Cisco+ Secure Connect (Meraki-managed) and AT&T SASE with Cisco (carrier-delivered). Enterprise specifics: ~1 Gbps per IPsec tunnel, ECMP 8–10 tunnels/site, wide AWS PoP coverage, and FedRAMP Moderate. Honest caveat: FWaaS is optimized for user/branch egress, not a full vFTD replacement for complex east-west data-center segmentation.