Intrusion Prevention System (IPS)

A signature, a packet and a decision

A signature describes something specific: a sequence of bytes in a request, a malformed field, a pattern used by a known exploit against a known software version. The engine reads the packets of a flow, reassembles them where needed, and tests them against the active signatures. When one matches, the engine acts according to the mode.

Choosing a signature set

Cisco's SD-WAN security policy offers signature sets of different strength. The names are along the lines of connectivity, balanced and security, with connectivity enabling the fewest signatures and security the most. Check the names and what each includes in your release. The trade is the same in every case.

• A larger set covers more attacks, uses more processing, and produces more false positives (alerts on harmless traffic).
• A smaller set is faster and quieter, and misses more.

There is no universally correct set. A payment network with an auditor often starts with a stronger set and accepts the tuning work. A small branch router with little spare capacity may need a lighter one.

Signature updates

Signatures age quickly, so the value of IPS depends on how current they are. The SD-WAN Manager distributes updates to the edges, based on the threat intelligence that Cisco publishes. Set up the update schedule or process in the Manager, make sure the Manager (or the edge) can reach the update source, and check the signature version on the router after an update. An IPS with a year-old signature set looks healthy in every status output and protects against old attacks only.

Allowed lists, and where alerts go

When one signature keeps firing on a harmless application, do not turn IPS off. Add an exemption instead. The policy supports an allowed list in which you can name a signature, and in some cases a source or destination, that is not to be acted on. Record the reason, the owner and a review date for each entry. An allowed list with no notes becomes a permanent blind spot.

Alerts are written to the router's logs and can be sent to a log server so they can be searched and kept. Plan where they go before turning on prevention: an alert that nobody reads has no value, and an audit may ask how long they are kept. Check your release for the supported destinations.

What traffic it covers

IPS is part of a security policy that is attached to a site. It applies to the VPNs and directions that the policy covers, which in practice means the traffic that a firewall rule hands to the inspection engine. At BR-01 you might cover VPN 40 (point-of-sale, 10.40.1.0/24) for traffic to the data centre and the internet, and leave voice in VPN 20 alone. Voice is delay-sensitive and rarely a target for this kind of signature, so inspecting it costs more than it gains. The VPN numbers are examples.

Resources and failure behaviour

On IOS XE SD-WAN, IPS does not run inside the packet forwarding code. It runs as a container or virtual service on the router. That has practical consequences.

• Resources. The service needs memory and storage, and the router must have an installed security package and the right licence or subscription. Platform support varies, and small models may support only part of the feature set. The platform guide for your router and release has the numbers.
• Performance. Inspection reduces the throughput the router can sustain and adds latency. Test with realistic traffic on the real platform.
• Failure. If the inspection service is down or overloaded, traffic that was meant to be inspected may be passed without inspection or may be dropped, depending on configuration. Passing keeps the network working and removes protection. Dropping protects and breaks the network. This is a design decision, so find out which your release does by default, set it deliberately, and test it.

A roll-out that does not break the shop

1. Check the platform. Confirm support, resources and the security package for the model and release.
2. Start in detection mode on one pilot site, with the set you expect to use.
3. Review the alerts for a period that covers normal business, including month-end and backups. Sort them into real threats, harmless matches and unclear ones.
4. Tune. Add allowed-list entries for harmless matches, with a note for each. Consider a lighter set if one signature family causes most of the noise.
5. Move to prevention at the pilot site, with someone watching the first days. Keep a rollback ready.
6. Extend site by site, and keep updates current.
7. Record changes: set, mode, allowed-list entries, update dates and who approved them.

Is the engine running?

The commands below are the ones used on IOS XE for the inspection service. Syntax and fields differ by release, so verify them on your router.

BR-01#show utd engine standard status
Engine version     : 1.0.x
Profile            : Cloud-Balanced
System memory      : Usage 24.0 %   Status: Green
Engine status      : Running   Health: Green
Signature version  : 2026-10-12
Traffic analysis   : Packets 2418830   Bytes 1920411022

BR-01#show utd engine standard config
UTD Engine Standard configuration
 IPS/IDS            : Enabled
 Operation mode     : Intrusion Detection
 Signature set      : Balanced
 Fail behaviour     : Fail-open
 Logging            : Alerts to log server 192.0.2.50

Where IPS projects go wrong

• Prevention on day one. A legitimate application is blocked by a signature nobody has reviewed.
• Detection forever. The alerts go unread and the network is not protected, though the policy looks complete.
• No decryption. Most web traffic is HTTPS, so the engine sees little of it. See the TLS proxy lesson.
• Signatures out of date. The status is green and the version is a year old.
• Undersized router. The engine competes with forwarding and the branch slows down at busy hours.
• Allowed-list entries with no owner. Exemptions pile up and nobody remembers why.

Test yourself on IPS