SDWSCS Part 2: The SDWAN Security Model & Unified Security Policy

Every security feature in this series exists because of one design decision covered back in ENSDWI Part 9: direct Internet access. The moment a branch stops backhauling to the data centre and breaks out locally, the branch edge inherits the security responsibilities the DC firewall used to own. Module 1 of SDWSCS is about facing that squarely — what the threat model now looks like, and the menu of places enforcement can live.

The four deployment patterns

Cisco frames SD-WAN security as four patterns, and the whole course hangs off this taxonomy:

1. Embedded (on-box) security — the Catalyst edge itself enforces: application-aware zone-based firewall, IPS/IDS, URL filtering, AMP, TLS/SSL decryption. Right answer when the branch needs local breakout and you don’t want another appliance or a cloud subscription per site.
2. Cloud-delivered security — traffic tunnels to Umbrella SIG (or another SSE) and enforcement happens in the cloud. Right answer at scale: hundreds of small sites, thin edges, one policy in one place.
3. Regional/dedicated security — traffic is steered via service chaining to a dedicated firewall stack in a regional hub or colo. Right answer where regulation or organisational reality says the packet must pass a real firewall team’s box.
4. Hybrid — in practice, almost everyone: embedded firewall plus DNS security everywhere, SIG for web traffic from small sites, service chains for the regulated VPNs.

Notice what the taxonomy is really encoding: who owns the control and where the state lives. That’s the question to ask in every design review, and it’s the question Parts 3–8 answer pattern by pattern.

What actually runs on the box

The embedded stack is two different execution environments, and keeping them straight explains almost every behaviour and limit:

• The zone-based firewall (ZBFW) runs in the QFP data path natively. It’s stateful, VPN-aware, application-aware via NBAR2 (1,400+ application signatures), and it costs comparatively little forwarding performance.
• IPS/IDS, URL filtering and AMP run in the UTD container — the Unified Threat Defense security virtual image, a Snort-based engine running under app hosting (IOx). Packets are punted from the data path into the container and back. That’s why these features have platform minimums: you need the DRAM (8 GB+) and flash to host the container at all, and the punt path is why throughput drops when you enable them.

Edge# show utd engine standard status
Engine version : 1.0.x_SV3.1.67.0_XE17.x
System memory  : Usage 34.0%
Overall system status: Green
Signature update status: Idle

If show utd engine standard status isn’t Green, nothing in Parts 3–4 works — check app-hosting resources before anything else.

Security policy in vManage: the two generations

Pre-20.6, each security feature was configured as its own policy and they stacked awkwardly — firewall here, IPS there, each with its own inspection pass. From vManage 20.6 / IOS XE 17.6, unified security policy merges them: one policy, built on zone pairs, where a single rule can match traffic and apply firewall action plus an advanced inspection profile (IPS, URL filtering, AMP, TLS decryption) in one pass through the Snort engine.

The building blocks, in the order vManage wants them:

1. Zones — interface- or VPN-scoped. Service VPN 1 = LAN, transport = WAN, and so on.
2. Zone pairs — directional (LAN → WAN). No zone pair, no inspection: traffic that doesn’t match a pair follows the default action.
3. Rules — match on source/destination prefixes, ports, and application lists; action inspect, pass, or drop.
4. Advanced inspection profile — the attachment point for the UTD features, referenced per rule.

Two defaults that generate most of the tickets: inter-zone traffic is dropped unless a rule allows it once ZBFW is enabled, and intra-zone traffic is passed unless you say otherwise. And one architectural fact worth tattooing somewhere: the firewall is VPN-aware but enforcement is per-edge — there is no fabric-wide session table. A flow that enters at site A and exits at site B is inspected at each box independently.

Self-zone and the control plane

The edge’s own control-plane traffic (DTLS to controllers, OMP, BFD) lives in the self zone. Write a LAN → WAN drop-all policy and the fabric stays up, because control connections are self-zone, not LAN. But write careless self-zone policy and you can cut the box off from its own controllers — vManage warns you, and you should read that warning slowly. Rule of thumb: don’t touch self-zone policy until you have a working out-of-band path.

Where this shows up in design

A quick decision table I use in reviews, which the rest of the series fills out:

Site profile	Pattern
Large branch, local breakout, sensitive data	Embedded full stack (Parts 3–4)
Small branch, thin edge, web-heavy traffic	DNS security + SIG (Parts 7–8)
Regulated VPN (payments, OT)	Service chain to dedicated firewall (Part 5)
Everything	ZBFW + DNS-layer security as the floor

Next up, Part 3: on-premises threat prevention — the enterprise firewall in detail, then IPS and AMP in the UTD container, signature sets, fail-open versus fail-close, and the lab that turns them all on.