Behavioural Baselining and ML Detection

Static thresholds are wrong at every peak that is not average. Signatures are silent on anything nobody has named yet. Between those two failures sits the argument for learning what normal looks like and judging against it.

The argument is good. What is usually oversold is the conclusion drawn from it.

What a baseline actually is

A description of a service’s ordinary behaviour across whichever dimensions the product measures: request rates per endpoint, connection establishment rates, packet size distributions, source diversity, response codes, session durations. Built from observation over time, and used to decide what counts as a departure.

The important word is departure. A baseline detects difference. Whether a difference is an attack, a marketing campaign or a new mobile app release is a judgement the system makes with whatever policy it was given.

Where it sits among the alternatives

Appliance	Detects the unnamed	Needs history	Typical failure
Static threshold	No	No	Wrong at every peak that is not average
Learned baseline	Yes	Weeks	Drift, and confident wrongness on novel normal
Signature matching	No	No	Silent on anything not yet named
Baseline plus deterministic floor	Yes	Weeks	More configuration to maintain

The last row is what most mature deployments converge on: learned detection for what a rule cannot express, with a hard deterministic limit underneath it that does not depend on a model being right.

What it works against

Novel vectors, which is the whole point. An attack shape that no signature describes still produces traffic unlike the traffic that came before, and a learned baseline notices that without anyone having written a rule.

Slow-ramping and low-rate application-layer attacks, where the absolute numbers stay unremarkable but the shape changes — a shift in which endpoints are being hit, or in the diversity of sources, or in session duration.

Multi-vector campaigns, where no single dimension crosses a threshold but several move together.

What it does not work against

Sparse traffic. A service with a handful of requests a minute has no describable normal. Deterministic limits serve small services better than learned detection does.

Traffic it cannot see. A baseline built from sampled flow records RFC 7011 can describe volume and is structurally blind to a slow application-layer attack, because the evidence it reads does not contain the event. An encrypted session that is never terminated is opaque to anything above the transport layer, regardless of how good the model is.

Attacks that ramp inside the learning rate. A campaign that grows slowly enough can be absorbed into the baseline as the new normal. This is the adversarial case against adaptive detection and it is not hypothetical.

Saturation. As always RFC 4732, classification quality is irrelevant once the circuit is full.

Operational risk

The learning window is a window of exposure, and what the product does during it — monitor only, apply defaults, or apply nothing — is a question with three different answers across the market.

Baseline visibility. If you cannot see what the system currently believes normal is, you cannot tell whether a false positive was a bad threshold or a poisoned baseline. Ask to see it.

Retraining after an incident. A baseline that learned from a period containing an attack has learned the attack. Whether the product excludes mitigation periods from learning is worth asking about explicitly.

Seasonality. Retail before a sale, a broadcaster before a final, a bank at month end. A baseline that has never seen the peak will meet it as an anomaly.

False-positive risk

The characteristic risk of this technique, and it presents differently from a rate limit’s. A threshold that is too tight fails predictably and visibly. A baseline fails confidently — it has a reason for what it did, that reason is a statistical departure, and the departure was your business succeeding.

Which is why every serious evaluation of a baseline-driven product measures goodput at a real business peak rather than in a quiet window, as the proof-of-concept methodology sets out, and why a deterministic floor underneath the model is worth more than a slightly better model.

How to verify

1. Run the full learning window on your real traffic; do not accept a demonstration on synthetic traffic as evidence.
2. Test at a genuine business peak, not a convenient hour.
3. Replay legitimate traffic alongside each attack class and record the rejection rate.
4. Ask to see the current baseline, and confirm you can read it without a support ticket.
5. Simulate a legitimate step change — a launch-shaped spike — and observe what the system does.
6. Disconnect anything the classification depends on and repeat one test, so you know whether there is a floor beneath the model.

Sources