Snort 3 IPS on FTD — Base Policies, NAP & Tuning

① Snort 3 vs Snort 2 — and how IPS attaches to the access-control policy

The single most important idea: deep inspection on Cisco Secure Firewall Threat Defense is done by Snort, and the LINA data plane hands matching traffic to it. The unified FTD image is LINA + Snort: LINA does the firewalling and forwarding, Snort does the intrusion and application inspection.

Snort 3 is now the default engine, replacing the legacy Snort 2. Snort 3 is multi-threaded (Snort 2 ran one process per core), noticeably faster, and uses a cleaner rule syntax that organises signatures into rule groups instead of long flat rule lists.

IPS is per-rule, not a global switch

You do not turn IPS on globally. In the access-control policy, you attach an intrusion policy to the inspection settings of an individual Allow rule. Only traffic that is allowed by that rule is then sent through Snort for intrusion inspection — so you inspect exactly the flows you choose, where it matters.

② The four intrusion base policies — the security-vs-connectivity dial

Every intrusion policy you create is built on a base policy — a Talos-maintained starting set of enabled rules that sets the trade-off between catching threats and not breaking traffic. There are four, from loosest to strictest:

• Connectivity over Security — fewest rules; favours uptime and throughput, lowest false positives, weakest detection.
• Balanced Security and Connectivity — the default and the sane starting point for most networks; Talos's recommended middle ground.
• Security over Connectivity — more rules enabled; stronger detection at the cost of more false positives.
• Maximum Detection — the most aggressive; for lab/high-assurance segments, not a busy production edge.

The interview line: start at Balanced, then tune up or down per segment. Picking Maximum Detection on a production edge to 'be safe' is the classic way to drown the SOC and block real users.

③ The Network Analysis Policy — preprocessors, normalisation & variables

Intrusion rules only work if the traffic they see is clean and reassembled. That is the job of the Network Analysis Policy (NAP) — the preprocessors / inspectors that run before any intrusion rule.

The NAP does IP defragmentation (reassembles fragmented packets), TCP stream reassembly (rebuilds the byte stream so an attack split across segments is seen as one), normalisation (strips evasive tricks like overlapping fragments or odd encodings), and runs protocol decoders (HTTP, SMTP, DNS and more) so rules can match on real fields. Turn these off and a fragmented or segmented exploit walks straight past the rules.

Variables scope the rules

Intrusion rules reference variables. HOME_NET is what you protect; EXTERNAL_NET is everything else. Set them correctly and rules fire in the right direction; leave them as any and you get noise and missed context.

④ Tuning — rule actions, Recommendations & cutting false positives

Talos ships rule updates as the LSP (Lightweight Security Package) — keep it current so coverage stays fresh. Within a policy each rule has a rule action: Generate Events (alert only), Drop and Generate Events (block and alert — but it only actually drops when the device is deployed inline), or Disable.

Tune to your network, not to a default

Secure Firewall Recommendations look at the hosts, operating systems and services FMC has discovered and recommend enabling the rules that matter for them while disabling rules for software you do not run — fewer rules, better signal. For the false positives that remain, use suppression (mute a rule for a specific source/destination) or thresholding rather than disabling a useful rule outright.

The interview line: Balanced base policy, current LSP, Recommendations tailored to your hosts, suppress the stubborn false positives — never bulk-disable to silence alerts.