FCSS SASE Architect cheat sheet

Unified SASE converges four planes into one policy model: networking (SD-WAN), security inspection (SSE), identity/context (ZTNA), and a single management plane; the differentiator versus stitched point products is one policy engine and one console.

Policy evaluation order in a unified fabric: identity and device posture are resolved first, then application/URL classification, then security inspection, then routing/steering decision; a failure at any earlier stage changes which later stages apply.

Single-vendor SASE and dual-vendor SASE differ in where the fabric terminates: single-vendor uses one cloud edge for both networking and security; dual-vendor uses one vendor for SSE and another for SD-WAN with an interconnection (e.g., IPsec tunnels or API integration) between them.

Zero Trust pillars per NIST SP 800-207: identity, device, network, application/workload, data, plus visibility and analytics and automation and orchestration - SASE delivers the network and application pillars plus telemetry into the others.

SASE identity plane relies on federated IdP (SAML/OIDC) plus SCIM provisioning; group membership drives policy, so stale directory data is a top cause of over-permissive access.

SASE management plane KPIs: policy propagation latency to all edges, single-pane coverage of all traffic types (web, private app, SaaS API, non-web), and consistent enforcement across on-prem, branch, mobile, and cloud workloads.

Digital experience monitoring (DEM) in unified SASE correlates end-to-end hop data (client, tunnel, PoP, SaaS) - use it to separate ISP/last-mile faults from policy or inspection faults before escalating.

Traffic steering decision: send to the nearest PoP by latency and health, not by geography alone; asymmetric or tromboned traffic (backhauling branch traffic to a distant PoP) is the classic unified-SASE design error.

SASE = network-as-a-service convergence of SD-WAN with cloud-delivered security service edge (SSE), defined by Gartner; the defining trait is policy follows the user and device, not the data center perimeter.

Core SASE edge services: SWG (web filtering, TLS inspection), CASB (SaaS discovery, inline and API-based control), ZTNA (per-app access, replaces inbound VPN), FWaaS (L3-L7 filtering at the PoP), and DLP.

SD-WAN under SASE supplies underlay selection and SLA-based path steering (per-packet or per-flow), local internet breakout, and application-aware routing; it does not by itself inspect content.

Deployment models: cloud-only (all traffic to PoP), hybrid (breakout with selective backhaul), and on-premises connector for legacy apps - choose per application based on latency sensitivity and data residency.

TLS inspection is the dominant capacity cost: size PoP throughput for full inspection of expected concurrent TLS sessions, and exempt pinned/unsupported apps via bypass lists to avoid breaking them.

SASE SLA design must cover both underlay (jitter, loss, latency per path) and edge service (PoP availability, inspection throughput); a single SLA for both hides the actual fault domain.

ZTNA vs VPN: ZTNA grants per-application, identity- and posture-gated access with no broad network reachability; VPN grants network-level reachability, so lateral movement risk is higher.

Traffic that cannot be proxied (non-web protocols, legacy thick clients) needs a connector/app-connector model or explicit bypass - plan these before declaring a SASE migration complete.

SSE = SWG + CASB + ZTNA + FWaaS, delivered from a cloud edge; it is the security half of SASE and can be adopted independently of SD-WAN.

SWG decision order: category/URL reputation → threat inspection (AV, sandbox) → data controls (DLP) → allowed; ordering determines whether blocked traffic still consumes inspection capacity.

CASB modes: inline forward/reverse proxy (real-time block), API-based (retroactive scan and remediation for sanctioned apps), and log-based discovery - combine inline for control with API for coverage.

TLS inspection requires a trusted re-signing CA distributed to endpoints; certificate pinning, client-certificate auth, and some IoT/medical devices must be bypassed or they fail silently.

ZTNA architecture: app connectors sit close to the app, the broker sits in the cloud, clients connect outbound only - no inbound ports on the app, which removes the exposed VPN concentrator.

FWaaS in SSE is L3-L7 with identity-aware rules; because it lives at the PoP, it can enforce east-west SaaS-to-SaaS and user-to-app flows that on-prem firewalls never see.

DLP effectiveness depends on classification accuracy: exact data match and fingerprinting for structured data, ML/document classifiers for unstructured, plus OCR for scanned content.

SSE selection criteria: PoP footprint versus user geography, inspection throughput per tenant, API coverage of sanctioned SaaS, connector support for legacy protocols, and log export to SIEM.

Secure SD-WAN integrates security inspection (NGFW, IPS, URL filtering, malware) into the SD-WAN edge so branch traffic is inspected at breakout rather than backhauled to a data center.

Path selection metrics: per-tunnel SLA probes measure latency, jitter, and loss; policy steers by best-quality, highest-bandwidth, or weighted load-balance, with failover when the SLA threshold is breached.

Local internet breakout (DIA) reduces latency to SaaS but shifts inspection to the branch edge - size edge throughput for the sum of breakout plus inter-site traffic, not just WAN capacity.

Topology choices: hub-and-spoke (simple, backhauled), full mesh (direct site-to-site, more tunnels), and partial mesh with regional hubs; tunnel count scales roughly as n(n-1)/2 for full mesh, so plan scale limits.

Overlay security: IPsec with IKEv2, per-tunnel keys, and segmentation via VRFs or zones; SD-WAN segmentation must map to the same policy intent used by the SSE/ZTNA layer to avoid policy drift.

Application-aware routing uses first-packet classification plus flow monitoring (e.g., IPFIX/AppFlow-style telemetry); encrypted traffic needs either local inspection at the edge or classification by IP/port heuristics.

Branch high availability: dual CPE with BFD-triggered failover, dual underlay transports (MPLS plus broadband/5G), and a validated fail-to-standby time that meets the business RTO.

Secure SD-WAN to SASE migration path: start with DIA plus cloud security for SaaS, then move private apps to ZTNA connectors, then retire backhaul - sequencing avoids a policy gap during cutover.