What Is Snort? The IPS Engine Inside Cisco Secure Firewall

By Taylor Thomas · 2026-08-29

Snort is an open-source intrusion detection and prevention engine: software that reassembles network traffic, inspects it against a large set of attack-description rules, and either alerts on or blocks what it matches. Released in 1998 and developed commercially by Sourcefire until Cisco acquired the company in 2013, it grew into one of the most widely deployed inspection engines in the world — and today it is the deep-inspection core of Cisco Secure Firewall Threat Defense. Understanding Snort is understanding how a modern firewall decides that one packet inside an allowed session is an attack.

Inspection After Permission

A stateful firewall’s core decision is whether a conversation is allowed. An intrusion prevention system asks whether an allowed conversation is hostile. That second question is harder: the engine reassembles TCP streams so an exploit split across segments cannot slip through, decodes protocols and exposes normalized representations so evasion tricks collapse back into canonical form, and evaluates the traffic against thousands of rules describing exploits, malware callbacks, and protocol abuse.

Where the engine sits determines what it can do about a match. Deployed passively, it receives a copy of traffic from a SPAN port or tap and can only detect and alert. Deployed inline, it sits in the forwarding path and can drop the packet or kill the session. The SNCF 300-710 blueprint makes this pairing explicit — objective 1.2, “Implement NGIPS modes,” lists exactly two: passive and inline.

The Grammar of a Rule

A Snort rule has two parts. The header states the action, protocol, source and destination addresses and ports, and direction — which traffic this rule even considers. The options body states what to look for: content matches at particular offsets, flow-state qualifiers such as flow:established,to_server, identification options — the SID and revision number analysts quote — and optional reference entries linking a rule to identifiers such as CVEs. When an analyst says a signature is firing, this grammar is what they are reading.

That literacy is a durably transferable skill. Curated rule sets from Cisco Talos do the bulk of the authoring, but tuning a noisy signature, judging a false positive, or writing a rule for a custom application all require reading the language fluently. Fluency is what separates tuning from guessing when a busy sensor floods the console.

What Snort 3 Changed

Snort 2 itself was single-threaded, so it scaled the way software of its era did: multiple independent instances, commonly one per core, each carrying its own copy of configuration and rules. Snort 3 rebuilt the engine to run multiple packet-processing threads inside a single process, cutting the duplicated configuration and rule memory those instances once consumed. Two other changes matter day to day. Service inspection now applies protocol rules by the service the engine detects rather than by port number, so HTTP inspection follows HTTP onto nonstandard ports once the engine identifies the service, and most port-based configuration becomes optional. And the rule syntax was made more consistent and easier to read — the same broad header-and-options model, with less ceremony.

The engine remains signature-driven at its core; how detection is extending beyond signatures is its own story, covered in Machine Learning in the IPS.

Snort Inside Secure Firewall Threat Defense

Inside FTD, three policies divide the labor. The access control policy classifies traffic and applies actions such as allow, block, or trust — and its Allow rules can invoke an intrusion policy for the traffic they permit. The network analysis policy governs preparation: how Snort decodes and normalizes traffic in support of rule evaluation. The intrusion policy governs judgment: which rules are enabled, and whether a match generates an event or, inline, drops the traffic. Talos maintains and ships the Cisco-provided rule content, so the engineer’s daily work is governance — selecting base policies, tuning against real traffic, and reading intrusion events with enough fluency to tell an attack from a false alarm.

Where This Meets the Exam

Snort is not background knowledge for the firewall track — it is named on the blueprint. SNCF 300-710 objective 2.6 is “Describe Snort within Secure Firewall Threat Defense,” objective 2.4 lists intrusion rules under object configuration, and domain 3 expects you to analyze the intrusion events the engine produces. The SNCF 300-710 course builds that judgment on live lab topologies, generating and analyzing real intrusion events. If IPS work is in your path, the first lesson is free.

Frequently Asked Questions

Is Snort the same thing as Cisco Secure Firewall?

No. Snort is the inspection engine; Secure Firewall Threat Defense is the firewall platform that embeds it. When an access control rule sends traffic to an intrusion policy, Snort is the component evaluating the packets and returning the verdict.

What is the difference between an intrusion policy and a network analysis policy?

The network analysis policy controls how traffic is prepared for inspection — decoding and normalizing protocols in support of rule evaluation. The intrusion policy controls the inspection itself: which rules are enabled and whether a match generates an event or drops the traffic. Misaligned preparation can undermine even a well-tuned rule set, which is why the two are managed as a pair.

What changed in Snort 3?

Snort 3 rebuilt the engine to run multiple packet-processing threads inside one process, where single-threaded Snort 2 was commonly scaled as multiple independent instances. It added service inspection that applies protocol rules by detected service rather than port, and adopted a cleaner, more uniform rule syntax. It is the current-generation inspection engine in modern Secure Firewall Threat Defense releases.