Behavioural, Threshold and Signature Detection Compared

Every mitigation product has to answer one question millions of times a second: is this traffic hostile? There are three broad ways to answer it, and the differences between them are not a matter of vendor preference. They are differences in what can be known.

At a glance

Appliance	Method	Catches	Misses
Signature	Known tools and known packet patterns	Anything not seen before, and anything trivially varied
Static threshold	Volume above a fixed line	Attacks under the line, and legitimate peaks above it
Dynamic threshold	Volume abnormal for this time and place	Slow ramps that move the baseline with them
Behavioural	Traffic shaped unlike your normal, including novel vectors	Whatever was already wrong when it learned, and the long tail

No row is redundant. The rows fail in different directions, which is the reason products combine them rather than choosing.

Signature detection

Match the traffic against patterns known to be hostile: a tool’s characteristic packet construction, an impossible flag combination, a header field with a value no legitimate stack produces.

The strength is precision. A packet with a TCP flag combination that cannot occur in a real conversation has no legitimate counterpart, so dropping it carries essentially no false-positive risk. This is why malformed-packet handling is nearly always signature-driven and why it is safe to leave permanently enabled.

The weakness is the definition. A signature is a description of something already seen. It cannot describe an attack tool released last week, and it can often be evaded by a trivial variation that changes nothing functional. Signatures are also a maintenance dependency: they require updates, and updates require a supply path — which is where the detection-locality question becomes relevant.

Signatures are excellent at the bottom of the stack, where structure is rigid, and progressively less useful as you move up toward traffic that is well-formed by construction.

Threshold detection

Set a limit; act when it is exceeded. Packets per second from one source, requests per second to one URL, new sessions per second to one service.

Static thresholds are simple, predictable and auditable, which are real virtues in a control somebody has to operate at 3am. They are also blunt in both directions. Set high, they miss attacks that stay below the line — and an attacker who can measure your service can stay below it deliberately. Set low, they refuse traffic on your busiest legitimate day, which is the most common self-inflicted outage in this field.

Dynamic thresholds address part of that by deriving the limit from recent history and from the time of day and week. Traffic that is normal at 09:00 on a weekday is abnormal at 04:00 on a Sunday, and a threshold that knows the difference catches more with fewer refusals.

The remaining weakness is that a limit derived from recent history moves with a sufficiently slow ramp. An attacker who increases volume over days can carry the threshold along.

Behavioural detection

Learn what the traffic normally looks like across many characteristics, then flag departures from that shape. Not volume alone: the ratio of SYN to ACK, the distribution of packet sizes, the proportion of requests that complete, the geographic and network spread of sources, the mix of protocols.

The strength is that it can catch something never seen before, because it describes normality rather than abnormality. A novel vector still has to differ from your normal traffic in some measurable respect, and a system watching enough characteristics will see the departure without knowing what caused it.

Two weaknesses matter and are frequently understated.

It inherits its training data. A baseline learned while something was already wrong encodes that as normal. Deploying during an ongoing low-level attack, or during an atypical period, produces a baseline that will be wrong for a long time.

The long tail is anomalous and legitimate. Behavioural systems learn from the majority. Old TLS stacks, embedded clients, one partner behind a single busy address, the scripted integration somebody built in 2019 — all of these depart from normal and all of them are real. This is where false positives concentrate, and it is why the false-positive test has to aim at the tail deliberately.

The mechanics of how baselines are actually computed are covered in behavioural baselining.

Why every product uses all three

The methods fail in different directions, and a defence built on one of them inherits its blind spot whole.

A realistic path looks like this. Malformed and impossible packets go first, by signature, at fixed cost and with no false-positive risk. Rate ceilings bound what any single source can present, by threshold. What survives is judged behaviourally, where the expensive analysis is applied to a much reduced volume.

That ordering is not incidental — it is the same cheap work first principle that governs where state is allocated.

Questions that separate implementation from claim

Five, and none of them can be answered with an adjective:

1. Which countermeasures are signature-based, which threshold-based, which behavioural? Answer per countermeasure rather than for the product.
2. What characteristics does the behavioural engine measure, and over what learning window?
3. What is the behaviour before a baseline exists, and how long is that period?
4. When methods disagree, which decides?
5. How does an operator override a verdict during an incident, and how is the override reverted?

Question 5 is the one that separates products in operation rather than in evaluation. Every detection method will be wrong at some point on a real network, and what matters then is whether a human can correct it in seconds and put it back afterwards. The escalation ladder that depends on it is in the escalation matrix.