Chapter 7: Integrated Security and SASE

On-Box Security

The first layer of protection happens inside the router itself. A crucial point about SD-WAN mode: you rarely hand-write the firewall and IPS configuration. Instead you author policy centrally in Cisco SD-WAN Manager (vManage), which translates that policy into native IOS XE constructs and pushes them to the router. The device CLI becomes your tool for verification rather than authoring.

Zone-Based Firewall

A zone-based firewall (ZBFW) is a stateful model where interfaces (or, in SD-WAN, VPN segments) are grouped into named zones, and policy is written between pairs of zones rather than per-interface. On the Catalyst 8000 this is the application-aware enterprise firewall, matching not only Layer 3/4 criteria but also Layer 7 application signatures with deep packet inspection.

The mental model is a building with security doors between rooms. Each room is a zone (LAN, WAN, Data Center, the router's own control plane). You never write a rule about "this door"; you write a rule that says "traffic going from the lobby room to the vault room is allowed only if it is a verified employee." That from-zone-to-zone rule is a zone-pair, and its action is one of inspect, pass, or drop.

Figure 7.1: Zone-based firewall zone-pair model

The single most important rule of ZBFW behavior: any zone-pair you do not explicitly configure is denied by default once zones are attached. This causes most "everything broke after I turned on the firewall" incidents. A second classic trap is the self-zone: if you do not write a policy permitting traffic to the router's own control plane, you can lock yourself out of management.

Worked example — LAN-to-WAN with default-drop. Suppose a branch needs LAN users to reach the web and DNS, but nothing inbound from the Internet should reach the LAN. In vManage you create the LAN and WAN zones, then build the inter-zone rules:

• LAN to WAN: match HTTP, HTTPS, DNS (ports 80, 443, 53) → action allow/inspect, with logging.
• LAN to WAN default: match any → action drop.
• WAN to LAN default: match any → action drop.

After attaching the Enterprise Application-Aware Firewall policy and pushing it, vManage generates native ZBFW configuration. You verify on the device with:

! See the security policy that was pushed
show sdwan running-config security
! See the generated zone-based firewall constructs
show running-config | section zone
show zone security
! Inspect active firewall sessions and drops in the data plane
show policy-map type inspect zone-pair sessions
show platform hardware qfp active feature firewall

Snort IPS / IDS

Where the firewall decides whether a flow is allowed, an intrusion prevention system (IPS) decides whether an allowed flow is actually carrying an attack. The Catalyst 8000 integrates Snort IPS (Snort3) with the appropriate SD-WAN security licenses. If the firewall is the guard who checks your badge, the IPS is the screening machine that opens your bag and looks for contraband even though your badge is valid.

Figure 7.2: Packet inspection flow through ZBFW, Snort IPS, and AMP

On IOS XE, Snort runs inside the UTD (Unified Threat Defense) engine, a container installed on the router. The IPS supports two operating modes and a choice of base rulesets:

The vManage workflow: upload the UTD Snort image and signatures to the software repository; create an IPS profile (mode, base policy, categories); bind the profile to the LAN-to-WAN zone-pair so allowed flows are handed to Snort; then attach and push the combined firewall+IPS policy. Verify on the device:

! Confirm the UTD/Snort engine is installed and running
show platform software utd status
show utd engine standard status
! Inspection counters and active sessions
show utd statistics
show utd active-sessions

Three diagnostics to memorize: not installed/running means the container image failed to download (check repository and device disk/memory); license errors at UTD start mean the security/IPS license is missing; and counters stuck at zero mean the IPS is not bound to the right zone-pair, or traffic is not matching the firewall rules that invoke it.

URL Filtering and AMP

Two more on-box capabilities round out content security. URL filtering enforces policy on web destinations by category — blocking, allowing, or warning. AMP (Advanced Malware Protection), branded Cisco Malware Defense, performs file and malware analysis at the WAN edge so a malicious download is identified and blocked before it reaches an endpoint. If IPS is the bag scanner looking for known attack patterns, AMP is the lab that takes a suspicious file and analyzes its reputation. Both require higher-tier DNA/SD-WAN security licenses.

Key Takeaway: The Catalyst 8000 delivers a full on-box security stack — zone-based application-aware firewall, Snort IPS via the UTD engine, URL filtering, and AMP/Malware Defense. Author policy centrally in vManage and use the CLI to verify; remember any unconfigured zone-pair drops by default and the self-zone must be explicitly permitted.

Secure Connectivity

On-box inspection protects traffic at the branch. The next layer protects traffic as it moves: encryption in flight, the ability to inspect encrypted traffic, and a lightweight control at the DNS layer.

IPsec and Crypto Offload

Every SD-WAN tunnel in the Catalyst SD-WAN fabric is an encrypted IPsec tunnel, and the Catalyst 8000 platforms encrypt and decrypt at line rate. The heavy mathematical work is handled by dedicated crypto offload hardware rather than the general-purpose CPU — a dedicated mail-room that seals and unseals every envelope so the executives (the CPU doing routing and policy) are not slowed down. This matters when the same box also builds IPsec tunnels to cloud security gateways, maintaining several per WAN transport. IPsec depends on a healthy underlay: when public-IP reachability, MTU, or NAT timeouts degrade, the symptom is intermittent tunnel flaps rather than an obvious hard failure.

TLS/SSL Proxy

The overwhelming majority of web traffic is now encrypted with TLS. A firewall or IPS that can only read the outside of the envelope cannot see the threat inside. The TLS/SSL proxy terminates the encrypted session on the router, decrypts the traffic for inspection by the firewall, IPS, AMP, and URL filtering engines, then re-encrypts before forwarding — a controlled man-in-the-middle by the trusted edge device. This is the customs officer authorized to open sealed diplomatic pouches, inspect the contents, and reseal them. Because it is computationally expensive and security-sensitive, it is gated behind higher-tier DNA licenses.

Figure 7.3: TLS/SSL proxy decrypt-inspect-re-encrypt flow

DNS-Layer Security (Umbrella)

The cheapest, earliest place to stop a threat is the moment a device asks "what is the IP address for this domain?" Cisco Umbrella provides DNS-layer security: branch DNS requests resolve through Umbrella, which can block resolution of domains associated with malware, phishing, or command-and-control before any connection is attempted. It requires no IPsec tunnels, making it a natural first phase of a SASE rollout; many organizations begin here and later migrate to full SIG tunnels. One caution: DNS policies and full Secure Web Gateway (SWG) policies are configured independently, and inconsistent settings cause confusing results — DNS allows a domain but the SWG later blocks the HTTP request.

Key Takeaway: Secure connectivity combines hardware crypto offload for line-rate IPsec, a TLS/SSL proxy that lets on-box engines inspect encrypted traffic, and Umbrella DNS-layer security as a tunnel-free first line of defense and natural entry point into SASE.

SASE Integration

The third and outermost layer extends enforcement beyond the branch into the cloud. SASE (Secure Access Service Edge) converges WAN-edge functions with cloud-delivered security into a single, identity-aware service model. Cisco's SASE has three pillars: Catalyst SD-WAN at the WAN edge, Cisco cloud security in the middle (Umbrella SIG / Cisco Secure Access SSE), and identity and policy (Cisco ISE). The result is an "identity-first" model in which a user's traffic is consistently inspected and controlled in the cloud security layer regardless of how they connect. The end-to-end path is:

User → Branch LAN → Catalyst SD-WAN edge → SIG IPsec tunnel → Umbrella POP → Internet/SaaS — all under SASE policies.

Figure 7.4: Cisco SASE three-pillar architecture and end-to-end path

Secure Internet Gateway (SIG) Tunnels

A Secure Internet Gateway (SIG) is a cloud-delivered security stack — Cisco Umbrella SIG / Cisco Secure Edge — deployed as globally distributed security POPs, typically including DNS-layer security, an SWG, a cloud-delivered firewall (FWaaS), and CASB controls. The connection between the Catalyst 8000 and the SIG is an automatically built IPsec tunnel into which Internet-bound traffic is sent. The genuinely valuable part: you do not build these tunnels by hand. vManage provides SIG templates that automate the entire process.

Worked example — full Internet breakout via Umbrella SIG. For a branch with dual Internet circuits: (1) define the SIG provider profile in vManage (type, region/POP list, API credentials); (2) configure a SIG policy/config group specifying which edges and transports carry tunnels and how VPNs map to POPs; (3) attach to the device template — each edge then initiates IKE/IPsec, commonly one tunnel per circuit for redundancy; (4) define data/centralized policies to steer traffic, e.g. a default route into the SIG with app-aware routing choosing the best circuit-and-POP tunnel. This automation generates the IKE/IPsec parameters and crypto maps and provisions redundancy automatically.

A powerful refinement is segmentation preservation: SD-WAN VPNs (Corp, Guest, IoT) map to separate Umbrella identities and policies, so guest Wi-Fi can be forced through SIG-only with stricter filtering while corporate traffic gets its own policy. The same template framework also supports third-party SSE providers — Zscaler, Palo Alto Prisma Access, and Netskope.

Cloud OnRamp for SaaS and IaaS

Sending everything through a cloud gateway is simple but not always optimal — backhauling a low-latency SaaS app through a distant POP hurts user experience. Cloud OnRamp optimizes and secures access to cloud services. Cloud OnRamp for SaaS continuously measures performance to apps like Microsoft 365 across multiple paths and selects the best one; Cloud OnRamp for IaaS extends the fabric into AWS/Azure. For each app the edge probes three candidate paths — direct breakout, DC backhaul, and SIG tunnels — ranked by latency, loss, jitter, and HTTP response time.

Figure 7.5: Cloud OnRamp for SaaS path probing and selection

With Cloud OnRamp for SaaS over SIG tunnels, the probes run across the SIG tunnels too, so the best path might be a specific Umbrella POP over a specific circuit — optimization and security together.

Cisco Secure Access Integration

The newest pillar is Cisco Secure Access, Cisco's Security Service Edge (SSE) offering that unifies SWG, CASB, FWaaS, and ZTNA behind a single identity-aware policy plane alongside identity sources like Cisco ISE. From the Catalyst 8000's perspective the integration mechanics are familiar: the SD-WAN edge builds SIG/SSE tunnels and steers traffic exactly as it does for Umbrella, using the same vManage SIG template framework. The difference is where enforcement decisions are made: once traffic reaches the SSE, user identity, device posture, and application context drive the SWG, firewall, and CASB policies — completing the identity-first story where the same user gets the same policy at the branch or remote.

This raises the key design question of any SASE deployment: which enforcement lives where? L3/L4 filtering can happen at the SIG or the local firewall; app-aware routing lives in SD-WAN while web app controls live in the SWG. Deciding deliberately avoids duplicate or conflicting rules between on-box and cloud layers.

Key Takeaway: In Cisco SASE the Catalyst 8000 is the WAN-edge pillar that builds automated IPsec SIG tunnels (Umbrella, Secure Access, or third-party SSE) via vManage templates, preserves VPN segmentation as cloud identities, and uses Cloud OnRamp to send each application over the best-performing secure path — while identity-aware policy is enforced in the cloud security layer.