Every monitoring system needs a definition of "normal." Without one, every packet is equally suspicious, and no packet is suspicious enough to investigate. The question isn't whether to build a baseline — it's how to build one that actually reflects how your network behaves.
Most organizations default to the simplest possible answer: take the last N minutes of data and compute an average. It works until it doesn't. When the Monday morning authentication surge triggers alerts every week, or when a quiet holiday period makes every login look suspicious in January, the "simple average" approach reveals its limitations.
What a Baseline Is Actually Trying to Model
A useful network baseline answers one question: given what I know about this network's history, what traffic level should I expect right now?
That question is more complex than it appears. "Right now" has context:
- What time of day is it? (Business hours vs. overnight)
- What day of the week is it? (Tuesday vs. Sunday)
- What week of the month is it? (Month-end batch processing?)
- What is the long-term trend? (Growing, shrinking, stable?)
A baseline that ignores these dimensions isn't measuring what's expected — it's measuring what happened recently. Those are very different things.
The Three Components of a Real Baseline
1. Trend
Your network isn't static. Applications expand, user populations grow, workloads migrate to cloud. A baseline that doesn't account for trend will perpetually chase reality, over-alerting as traffic climbs and under-alerting during periods of contraction.
Trend modeling requires looking at traffic over weeks and months, not just minutes. A 5% month-over-month growth rate in north-south traffic is probably normal. A 5% weekly spike on top of that trend is worth investigating.
2. Seasonality
Networks have rhythms — and those rhythms exist at multiple scales simultaneously:
- Intraday: Business hours see 3-8x the overnight traffic for most enterprise segments.
- Weekly: Monday morning authentication storms, Friday afternoon quiet periods, weekend backup windows.
- Monthly: End-of-quarter reporting, monthly patch cycles, billing system activity.
A baseline that doesn't model these rhythms will fire alerts at predictable, patterned moments — training analysts to ignore them.
3. Residual Variance
Even after removing trend and seasonality, real traffic has natural noise. A good baseline model captures the expected range of this noise, not just the center point. Traffic that falls within the expected noise band is normal. Traffic that departs from it — in either direction — is anomalous.
This is why confidence intervals matter more than point estimates. The question isn't "is this exactly the predicted value?" but "is this plausibly within the range of normal values?"
Building Baselines at the Right Granularity
One of the most common mistakes in network monitoring is building a single baseline for an entire network. That's like building one weather model for an entire continent.
Effective baselines are built per segment, per direction, per protocol class:
- Separate baselines for east-west vs. north-south traffic
- Separate baselines per VLAN or subnet group
- Separate baselines for TCP, UDP, ICMP, and application-layer protocols
This granularity matters because an anomaly in one dimension is often masked when aggregated with another. A slow DNS exfiltration attack, for example, might be invisible in aggregate traffic data but stand out sharply in a baseline scoped to DNS query volume from a specific subnet.
Handling Baseline Disruptions
Networks change. Baselines built on historical data eventually become stale. Common disruption scenarios include:
- Office closures: A surprise holiday or emergency WFH mandate shifts the expected pattern dramatically.
- Application migrations: Moving a major workload to Azure changes where the traffic goes, not just how much there is.
- Network expansion: Adding a new office or cloud region introduces traffic that has no historical baseline.
Good baseline systems detect these disruptions automatically using changepoint detection — identifying moments where the underlying behavior shifts and resetting the model accordingly. Without changepoint detection, you either let the model drift (generating false positives for weeks) or manually retrain it (operationally burdensome).
What Good Looks Like
A mature baselining system has these characteristics:
- Per-segment models with configurable grouping granularity
- Multi-scale seasonality (at minimum: daily and weekly)
- Trend modeling with changepoint detection
- Bidirectional anomaly detection (unexpected spikes and unexpected absences)
- Automatic retraining on a rolling window
- Confidence interval output rather than binary thresholds
FlowSight builds and maintains these models automatically from collected flow data. From the moment collection begins, it starts learning your network's rhythm — and within two weeks, it has enough seasonal coverage to begin producing high-confidence baselines. The models retrain continuously on a 90-day rolling window, so they stay current as your environment evolves.
The Payoff
When baselines are done right, anomaly detection becomes genuinely useful. False positive rates drop dramatically. The alerts that fire are ones worth investigating. And the analysts who receive them develop confidence in the system rather than the habit of dismissing it.
The difference between "monitoring that generates noise" and "monitoring that surfaces threats" is almost always the quality of the baseline underneath it.