SDWSCS Part 3: On-Premises Threat Prevention — Firewall, IPS & AMP

Part 2 established where enforcement can live; this part deploys the on-box threat prevention stack — the enterprise firewall in the data path and IPS + AMP in the UTD container. This is the syllabus module with the heaviest lab, and the configuration order matters: firewall first, container second, inspection profiles last.

The enterprise application-aware firewall

The ZBFW rules engine matches on the usual five-tuple objects plus application lists resolved by NBAR2. The subtlety everyone hits: NBAR2 needs a few packets to classify a flow, so application-match rules are enforced once classification lands, not on the SYN. For applications that can be identified on the first packet (by server IP/port from the NBAR2 cache), enforcement is immediate; for the rest there’s a short classification window. Design consequence: pair application rules with a sane default posture rather than relying on app-match alone to gate the first packet.

Actions are inspect (stateful, return traffic allowed automatically), pass (stateless allow — you need a matching rule in the reverse zone pair), and drop. Logging goes to syslog or high-speed logging (HSL) via NetFlow v9 export — HSL is the right answer at any real session rate.

Edge# show sdwan zonebfwdp sessions
SESSION ID  STATE  SRC IP        DST IP        SRC PORT  DST PORT  PROTOCOL
1245        open   10.1.1.10     142.250.74.4  51234     443       PROTO_L7_HTTPS
Edge# show sdwan zbfw statistics drop

Those two commands, plus show policy-firewall config, are the firewall troubleshooting kit.

IPS/IDS: Snort in a container

The UTD container runs Snort against traffic the unified policy punts to it. Decisions you make when deploying:

IDS vs IPS mode. IDS inspects and alerts; IPS inspects and drops. Start regulated sites in IDS for a soak period, review alerts, then flip to IPS — turning on drop mode with an untuned signature set against production traffic is how you learn which internal app looks exactly like an exploit attempt.

Signature set. Three curated levels, straight from Talos:

Set	Behaviour
Connectivity	Fewest signatures, CVSS 10 only, lowest latency risk
Balanced	The default — CVSS 9+ recent vulnerabilities, sane false-positive rate
Security	Broadest coverage (CVSS 8+, older CVEs), highest inspection cost

Balanced is the correct default; Security is for sites whose traffic profile justifies the added latency and false-positive triage.

Signature allow-list. Individual signature IDs (generator ID + signature ID) can be suppressed when a known-good application trips a rule — the day-two operation you’ll perform most.

Fail-open vs fail-close. If the container dies, does traffic flow uninspected (fail-open) or stop (fail-close)? Availability-first sites choose fail-open; compliance-first choose fail-close and accept that a container crash is now an outage. This single radio button deserves a design-review conversation, not a default.

Signature updates pull from Cisco (directly or via vManage as proxy) on a schedule — the edges need reachability to the update source, which is easy to forget on tightly-locked-down transports.

Edge# show utd engine standard signature update status
Current signature package version: 29.0.c
Last update status: Successful
Edge# show utd engine standard logging events

AMP: file reputation and sandboxing

Advanced Malware Protection adds file-level inspection to the same container. Two stages:

1. File reputation — the engine computes a SHA-256 of files crossing the box and queries the AMP cloud. Verdicts: clean, malicious, unknown. Malicious files are dropped inline.
2. File analysis (Threat Grid / Secure Malware Analytics) — unknown files can be uploaded for detonation in the sandbox. The verdict comes back minutes later, which means file analysis is retrospective: the first copy of novel malware gets through the box, and the value is the alert telling you exactly which host has it. Retrospective events are the operational payoff — wire them into whatever your SOC actually reads.

AMP needs its own cloud region choice (NAM/EU/APJC — a data residency decision, not a performance one) and, like everything UTD, costs container resources. show utd engine standard statistics daq all | i file confirms files are actually being extracted.

Deployment order (the lab, condensed)

1. Verify app-hosting resources and install the security virtual image matching the IOS XE version (vManage → Maintenance → Software Repository).
2. Build zones, zone pairs, and the firewall rules in a unified security policy.
3. Create the advanced inspection profile: IPS (mode, signature set, allow-list), AMP (region, file types, analysis on/off).
4. Reference the profile from the policy rules that need it, attach the policy to the device template / config group, push.
5. Verify: show utd engine standard status green, generate an EICAR download and a test signature hit, confirm events in vManage → Monitor → Security.

The classic failure at step 5 is a version mismatch between the security virtual image and IOS XE — the container simply won’t start, and the fix is downloading the image that matches the exact XE train.

Next up, Part 4: content filtering — URL filtering categories and reputation, and the TLS/SSL decryption proxy that determines whether any of it can see inside HTTPS.