Suricata → Cisco Firepower

Suricata ↔ Cisco Firepower: integration to migration path.

Your IPS is load-bearing — promote a bad rule to drop and a segment goes dark. So Suricata never replaces Firepower on a flag day. It deploys alongside FTD as a passive sensor first, proves it catches what Talos catches, then takes over enforcement one segment at a time — FTD staying the inline firewall the whole way, every step reversible in minutes.

The honest part is that this is subsystem decomposition, not a box swap: we retire FTD's intrusion engine and Talos sub, not the FTD chassis. We tell you exactly which Cisco capabilities stay before Phase 1.

The idea

Watch the same wire first. Take over enforcement last.

The topology that makes this zero-outage is a parallel feed: a SPAN, TAP or ERSPAN copy of the exact traffic FTD inspects is mirrored to a Suricata sensor running in IDS mode. Suricata alerts on its own ruleset and emits EVE-JSON straight to your SIEM with a Community ID on every flow, while FTD keeps enforcing inline. Because both tools see the same packets keyed by the same join, we can prove detection parity before a single drop verdict moves — then promote enforcement to Suricata segment by segment, with FTD shifted to monitor-only Detection so nothing double-blocks.

The phases

Six steps. Each one reversible.

0

Baseline & inventory

We document per-segment line rate, your FMC intrusion policy by Talos category, connection-event volume, encrypted-traffic share, TLS-decrypt coverage, AMP lookup volume and custom Snort rule count. Read-only against FMC — nothing on the wire changes.

Users see: No user impact.

Rollback: N/A

1

Suricata sensors in IDS mode

Suricata stands up per segment on a SPAN, TAP or ERSPAN copy, emitting EVE-JSON to your SIEM as a separate sourcetype with Community ID and JA3/JA4 enabled. No drop actions. FTD stays the inline enforcement point, intrusion policy untouched.

Users see: None — Suricata only watches a mirror.

Rollback: Stop the Suricata service. Under 5 minutes.

2

Parallel detection, FTD authoritative

Suricata alerts alongside FTD for at least 30 days. We join both feeds on Community ID and track every delta — FTD-only Talos hits, Suricata-only ET / JA3 hits, and agreements — so the rule gap is quantified before any enforcement moves.

Users see: None for users; the SOC sees parallel alerts during tuning.

Rollback: Disable Suricata sourcetype routing. Under 5 minutes.

3

Migrate enforcement, segment by segment

Per segment, Suricata goes inline behind a fail-open bypass NIC with curated drop rules, while FTD's intrusion policy shifts to Detection so it monitors without double-blocking. Waves run low to high blast-radius, each rule category soaked seven days before promotion to drop.

Users see: None when tuning is correct — only the inspection engine on that segment changed.

Rollback: Revert FMC intrusion policy to Prevention and force the bypass NIC open. Under 15 minutes.

4

Retire FTD's intrusion engine

Once Suricata is proven across every segment, the FTD intrusion policy is unassigned and the Talos intrusion-rule subscription becomes cancellable. FTD keeps owning the firewall, NAT, VPN, URL categories, AMP file disposition and TLS decrypt. Suricata is the sole intrusion plane.

Users see: None for traffic.

Rollback: Re-assign the intrusion policy and push. Under 15 minutes.

5

Decommission the Talos intrusion sub

The Talos intrusion subscription is cancelled at renewal. The FTD chassis is typically retained as firewall plus URL plus AMP — a full Cisco exit forks into a separate firewall-replacement workstream out of scope here.

Users see: None unless the firewall layer also moves.

Rollback: Re-purchasing the Talos sub is commercially painful — the practical rollback point is the end of Phase 4.

Feature parity

Where Suricata matches FTD — and where it does not.

CapabilitySuricataCisco FirepowerParity
Inline IPS enforcement af-packet paired plus copy-mode ips (or nfqueue) FTD inline Snort 3 intrusion engine At parity
Signature detection suricata-update (ET Open / ET Pro / custom) Talos ruleset (daily SRUs) Partial
Protocol-metadata logging EVE-JSON (http / dns / tls / ssh / flow) FMC connection events (sparser per-L7) At parity
Encrypted-traffic handling JA3/JA4 plus SNI; no native TLS decrypt FTD inline TLS decrypt (licensed) SaaS only
File extraction / disposition file-store extract plus SHA256 to your sandbox AMP for Networks file disposition plus trajectory Partial
Threat intel feed Abuse.ch (SSLBL / URLhaus), MISP-generated rules Talos URL reputation plus threat intel Partial
Community ID community-id yes (Corelight spec) Not emitted by FMC eStreamer OSS only
Alerting / output EVE-JSON to SIEM (no eStreamer parser) eStreamer (TLS-mutual) plus syslog At parity
MITRE ATT&CK tagging alert.metadata (ET Pro mitre_technique_id) Talos-curated ATT&CK metadata Partial
Custom detection lua rule keyword, git-versioned .rules FMC UI-constrained custom rules At parity
ISE quarantine integration None native (SOAR plus pxGrid substitute) FTD to ISE pxGrid quarantine SaaS only
Deployment & HA / scale VPC Traffic Mirroring fan-out / bypass-NIC pair FMC centralised policy push at scale Partial
Cost model Sensor compute plus ops plus optional ET Pro Per-Gbps plus per-feature SKU plus Talos sub Partial
Compliance (PCI 11.5.1 / SOC 2) git diff of rules plus suricata-update cron evidence Vendor-attested Talos currency Partial

What we're honest about

The caveats most vendors leave out.

Talos rule coverage has a real gap

Roughly 20–30% of the Talos SIDs firing in your environment have no clean ET Open or custom equivalent. We quantify it from your 90-day SID firing data in Phase 0, budget custom-rule authoring, and may recommend keeping an ET Pro subscription indefinitely to narrow it rather than pretend it closes.

Inline TLS decrypt does not come across

FTD's inline TLS decryption is a licensed feature; the OSS substitute is a Squid SSL-bump or NGINX terminator feeding the sensor — a different architecture, not a one-to-one swap, with its own legal and HR review of TLS interception. If FTD currently decrypts, that is a separate workstream we scope honestly.

AMP file disposition and ISE quarantine stay with Cisco

There is no OSS real-time file-hash verdict cloud; MISP plus VirusTotal plus offline sandboxing is categorically slower. FTD's ISE pxGrid quarantine has no native Suricata equivalent either. We retain FTD's AMP and ISE layers rather than overstate parity.

Self-hosting means you own the SOC and uptime

Cisco TAC, Talos IR and the 24x7 vendor backstop go away with the subscription. If Suricata fails inline a segment outages; if it fails in IDS mode you have a detection gap. That is why we run it as a managed service — HA bypass NICs, standby sensors and a tested DR runbook, not just an install.

Why this beats a flag day

Reversible at every step, soaked before anything is cancelled.

Every per-segment enforcement cutover rolls back in under 15 minutes — revert the FMC intrusion policy to Prevention and force the Suricata bypass NIC to fail open. And nothing irreversible happens early: we hold the FTD intrusion engine and the Talos subscription live through a soak of at least 30 days at the full drop set with no Suricata-attributed incident before that subscription is ever cancelled. The expensive, contractual step is always the last one, and only after the evidence is in.

See whether your Firepower stack decomposes cleanly.

A call with a senior detection engineer. We map your segments and line rates, quantify the Talos coverage gap from your real SID firing data, and tell you honestly which Cisco capabilities stay and which Suricata can own — before you commit to anything.

Map my migration →