ENSDWI Part 10: Security — Service Insertion, Embedded, and Cloud-Delivered
Domain 5.0 (Security and QoS) is 15% of the exam; this part takes the security half — blueprint 5.1 through 5.3. Almost all of it is “describe”-verb material except service insertion, so the game is knowing what each feature is, where it runs, and which licence/platform it needs.
5.1 Configure service insertion
Steer traffic through a network service (firewall, IPS, load balancer) that isn’t in the natural path. Three moving parts:
- Advertise the service. The edge in front of the firewall announces it into the fabric —
service FW address 10.1.5.5under the VPN (or via template/config group). OMP carries it as a service route (Part 2’s third route type). - Steer with policy. Control policy:
action accept / set service FWon matched routes (topology-level steering at vSmart), or data policyset servicefor packet-level steering. Traffic to matched destinations detours via the service site, through the firewall, then onward. - The service itself is not fabric-aware. It’s a normal L3 device on the service VPN; the edge hands traffic to it and picks it up on the other side.
Tested details: predefined service names (FW, IDS, IDP, netsvc1–4); the service is advertised per VPN; and if the service goes down (edge withdraws the service route), traffic reverts to the direct path unless policy is strict. “Firewall inspection for spoke-to-spoke traffic without hairpinning through the DC” scenarios = service insertion at a regional hub.
5.2 Embedded security on the WAN Edge
The on-box stack — cEdge/IOS-XE only, container-based (Snort runs in an LXC/app-hosting container), needs 8 GB+ RAM platforms and the right DNA tier. Configured from vManage security policy (a separate policy builder from Part 8/9’s: Configuration → Security), pushed in templates/config groups.
5.2.a Application-aware enterprise firewall
Zone-based firewall: zones = collections of VPNs (or interfaces), zone-pairs with inspect/pass/drop policies between them. Application-aware via NBAR/SD-AVC — rules can match ~1,400 applications, not just ports. Stateful, with HSL (high-speed logging). Default posture: intra-zone allowed, inter-zone dropped until a zone-pair policy says otherwise. The “Guest VPN must not reach Corp VPN on the same edge” answer when the fusion-router pattern isn’t offered.
5.2.b IPS
Snort-based intrusion prevention in a container. Signature set from Cisco Talos, auto-updated via vManage. Modes: detection (alert) or protection (drop). Signature levels: Connectivity / Balanced (default) / Security. Requires the security licence tier and a signature-update path (vManage proxies or direct). Failure handling: fail-open vs fail-close if the container dies — exam likes asking which is default (fail-open for availability).
5.2.c URL filtering
Category-based (82 categories) + reputation-based (score 0–100) web filtering, allow/block lists, block page or redirect. Runs in the same Snort container. Cloud lookups for uncategorised URLs. Per-VPN application.
5.2.d AMP (Advanced Malware Protection)
File reputation (SHA-256 hash lookup against the AMP cloud) and optional file analysis (unknown files detonated in Threat Grid sandbox). Retrospective events: if a file’s verdict later turns malicious, AMP flags where it went. Describe-level: know the two functions and the Threat Grid name.
5.2.e SSL/TLS proxy
The edge as TLS man-in-the-middle so IPS/URL-F/AMP can inspect encrypted traffic: edge holds a subordinate CA certificate (issued from enterprise CA, or vManage acts as CA), terminates the client’s TLS, re-originates to the server, re-signs the server cert on the fly. Clients must trust the proxy CA (pushed via AD GPO or MDM). Exam points: needs the CA trust distributed to endpoints, decrypt policies choose what’s proxied, undecryptable traffic (pinned certs) gets pass/drop policy. Same trade-offs as any middlebox TLS inspection — the certificate-trust distribution is the deployment battle, not the config.
5.2.f TrustSec
Catalyst SD-WAN carries SGTs (Scalable Group Tags) across the overlay: inline tagging in the tunnel encapsulation, or SXP integration with ISE where inline isn’t possible. The edge propagates tags; enforcement is typically elsewhere (switches, firewalls, or ZBFW matching SGTs). Describe-level: SGT propagation (inline vs SXP), ISE integration, and that this extends campus microsegmentation over the WAN.
5.3 Cloud security integration
5.3.a DNS security (Umbrella)
Lightest-touch cloud security: the edge redirects DNS queries to Cisco Umbrella (208.67.222.222/220.220), with the org’s Umbrella token attached (EDNS), so Umbrella applies the org’s DNS policy — malicious domains sinkholed before a connection ever starts. Configured as a DNS security policy in the vManage security builder; per-VPN; local-domain bypass list for internal names. Needs an Umbrella subscription and API token. It’s DNS-layer only — no inline packet inspection.
5.3.b Secure Internet Gateway (SIG)
Full-tunnel cloud security: branch Internet traffic is tunnelled to a cloud security stack — Cisco Umbrella SIG or third parties (Zscaler, generic) — which applies SWG/FW/CASB/IPS in the cloud. Facts the exam wants:
- Transport: IPsec or GRE tunnels from the edge to the SIG PoPs; automatic tunnels (Umbrella/Zscaler API-orchestrated from vManage credentials) vs manual (any SIG). Active/backup or active/active tunnel pairs, with layer-7 health checks (HTTP probe to a service URL) driving failover.
- Steering: service-route-style — SIG feature template creates the tunnels; routing sends traffic via
service sig(route-based: static default in the service VPN pointing at SIG) or data policy actionsecure-internet-gateway. - SIG vs DIA vs DNS-security is the classic scenario triple: DNS security = resolve-time protection only; DIA + embedded stack = inspect locally on the edge; SIG = ship it to the cloud stack. Questions describe a customer posture and ask which fits — small branch, no on-box horsepower, full inspection required → SIG.
Where each feature runs — the one-table summary
| Feature | Runs | Key dependency |
|---|---|---|
| Service insertion | Fabric (policy + service edge) | OMP service routes |
| Enterprise firewall (ZBFW) | Edge, IOS-XE native | zones/zone-pairs |
| IPS / URL-F | Edge, Snort container | 8 GB+ RAM, security licence, Talos updates |
| AMP / Threat Grid | Edge + cloud lookup | AMP cloud, sandbox subscription |
| SSL/TLS proxy | Edge | subordinate CA, client trust |
| TrustSec | Edge propagation | ISE (SXP) or inline tagging |
| DNS security | Umbrella cloud | Umbrella token |
| SIG | Umbrella/Zscaler cloud | IPsec/GRE tunnels, health checks |
Exam traps for this domain
- Security policy is its own builder in vManage — separate from centralized control/data policy. Different wizard, different push path (templates, not OMP).
- Snort container features (IPS, URL-F) share platform requirements — memory and licence. ZBFW is native IOS-XE and cheaper to run.
- IPS default = balanced signatures, fail-open.
- SSL proxy requires the client-side CA trust or users drown in warnings — deployment questions hinge on this.
- Umbrella DNS ≠ SIG: resolve-time vs full-tunnel. Read which the scenario needs.
- SIG automatic tunnels exist for Umbrella and Zscaler; anything else is manual config.
- Service insertion services are per-VPN and withdrawn with the service route — steering silently reverts to direct path.
Part 11 finishes the domain with QoS on the WAN Edge — the full classification-to-scheduling pipeline, per-tunnel and adaptive QoS — and the App-QoE suite: TCP optimisation, DRE, packet duplication, and FEC.