Baselining is the step teams skip and the step everything else depends on. Anomaly detection without a baseline is threshold guessing. Capacity planning without a baseline is extrapolating from last Tuesday. Incident triage without a baseline reduces to asking whoever has been there longest whether the number looks high.
The method below is the one that survives production, mostly because it takes segmentation and validation seriously rather than treating baselining as a switch to flip.
In this guide
- A seven-step method from purpose definition through ongoing maintenance.
- Which statistic to use for which purpose, and why the mean is usually the wrong choice.
- The mistakes that quietly ruin baselines, including the one that makes an attacker part of normal.
What a baseline actually is
A baseline is a documented description of normal behavior for a defined entity over a defined period, expressed with enough statistical detail to say whether a new observation is unusual.
Three parts of that definition carry weight.
Defined entity: A baseline for "the network" is close to useless. Baselines belong to interfaces, device groups, applications, or host roles.
Defined period: Networks have daily, weekly, and often monthly rhythms. A baseline that ignores them produces alerts every Monday at 9 AM and every month-end.
Statistical detail:"About 200 Mbps" is just an estimate. A proper baseline uses percentiles to show the normal range of traffic.
Step 1: Decide what the baseline is for
The purpose determines every subsequent choice, and mismatched baselines are the most common failure.
| Purpose | Time granularity | Statistic that matters | Update cadence |
|---|---|---|---|
| Capacity planning | Daily and weekly aggregates | 95th percentile, growth trend | Monthly |
| Performance troubleshooting | 1 to 5 minute intervals | Median and 95th percentile, variance | Weekly |
| Anomaly detection | 5 to 15 minute intervals | Distribution shape, standard deviation, peer counts | Continuous |
| Billing and chargeback | Per interval per entity | 95th percentile, total volume | Per billing cycle |
A capacity baseline built on daily averages cannot support anomaly detection, because a 20-minute exfiltration event disappears entirely inside a daily average. Build separate baselines for separate purposes rather than trying to make one serve all four.
Step 2: Choose the metrics
More metrics do not produce better baselines. These carry most of the signal.
Volume metrics
- Bytes in and out, per interface and per host, at your chosen interval
- Packets in and out, which combined with bytes gives average packet size
Relationship metrics
- Distinct peer count per host per interval, the single most useful security metric in the list
- Ratio of internal to external destinations per host
- Set of ports each host normally uses, and its entropy
Application metrics
- Traffic share by application or application category
- Protocol distribution across TCP, UDP, ICMP, and others
Quality metrics
- Interface errors and discards
- Retransmission indicators where available
- Class-based counters (CBQoS or equivalent) where QoS is deployed
Temporal metrics
- Activity distribution by hour of day and day of week
- First and last activity time for user-associated devices
Distinct peer count deserves the emphasis. Volume anomalies are noisy because legitimate volume varies enormously. Peer count is far more stable per host role, which makes deviation meaningful. A workstation that talks to 20 things every day and suddenly talks to 200 is a stronger signal than one that transfers twice as many bytes.
Step 3: Segment before you measure
This is the step that determines whether the baseline is useful, and it is the step most often skipped.
A single network-wide baseline averages a domain controller, a print server, a developer laptop, and a security camera into one meaningless profile. Everything looks anomalous relative to that average, which means nothing does.
Segment by role, with groups such as:
- Domain controllers and directory services
- Database servers
- Application and web servers
- File and storage servers
- Backup infrastructure
- User workstations, split by department where behavior genuinely differs
- Printers and multifunction devices
- IoT, cameras, badge readers, and building systems
- Network infrastructure management interfaces
- Guest and BYOD networks
- Remote access and VPN pools
Two practical notes. First, IoT and building systems belong in their own groups because their behavior is extremely regular, which makes deviation detection unusually reliable there. Second, if you cannot enumerate your device roles, run four weeks of collection and cluster hosts by observed behavior. The clusters that emerge are frequently more accurate than the CMDB.
For internal segments specifically,east-west traffic analysis covers the instrumentation these groups need.
Step 4: Collect for the right duration
Duration depends on the cycles you need represented.
- Two weeks: Minimum for daily patterns. Enough to start, insufficient for confident alerting.
- Four to six weeks: Captures weekly cycles reliably and usually includes a month-end. This is the practical target for most environments.
- Three months: Captures quarter-end effects, which matter in finance, retail, and any organization with quarterly close processes.
- Twelve months: Required for genuine seasonality, including academic calendars, retail peaks, and fiscal year cycles.
Two rules during collection.
Exclude known-abnormal periods: A migration weekend, a major incident, or a holiday shutdown should be marked and excluded rather than averaged in.
Do not alert from an immature baseline: Collect silently first. Alerting from a two-week profile trains the team to ignore the tool, and that habit is difficult to reverse.
Step 5: Choose the statistic
The mean is the default in most tools and the wrong choice in most cases, because network traffic distributions are heavily skewed and a few large transfers drag the average away from typical behavior.
Use the median for typical behavior. It resists the pull of outliers.
Use the 95th percentile for capacity and billing. It is the industry convention for burstable circuit billing precisely because it ignores brief spikes while capturing sustained demand.
Use percentile bands for anomaly detection: 5th to 95th as the normal envelope, with excursions beyond the 99th treated as notable. Percentile bands make no assumption about distribution shape, which matters because network traffic rarely follows a normal distribution.
Use standard deviation carefully. Three-sigma rules assume normality. Applied to skewed traffic distributions they alert too often on the high side and never on the low side. Low-side deviation matters, since a server that stops talking is frequently a more urgent event than one talking more.
Record the whole distribution. Store percentiles at 5, 25, 50, 75, 95, and 99. The shape tells you whether traffic is steady, bursty, or bimodal, and each shape needs different alert logic.
Step 6: Validate before alerting
Run the baseline in observation mode for at least two weeks and check three things.
Backtest
Replay the previous period against the proposed thresholds. Count how many alerts would have fired and inspect a sample. If the count is unmanageable, the thresholds are wrong.
Inject known events
Take a real event you remember (a backup job that overran, a migration, a scan) and confirm the baseline would have flagged it. A baseline that misses events you already know about will miss the ones you do not.
Review with the people who run the systems
Application owners routinely explain patterns that look anomalous and are entirely expected. That conversation prevents weeks of false positives, and it is faster than discovering the same facts through alert triage.
Step 7: Maintain the baseline
A baseline is a living artifact. Three maintenance obligations keep it honest.
Rolling recalculation
Recompute on a rolling window, typically 30 to 90 days, so gradual growth is absorbed and step changes still stand out. Confirm with any vendor whether their profiles recompute on a rolling window, on a schedule, or on a trigger, because the three behave differently after a step change.
Change-triggered review
Application deployments, office moves, acquisitions, VPN policy changes, and architecture shifts all invalidate portions of the baseline. Tie baseline review to change management rather than to a calendar.
Drift monitoring
Track how far the current profile has moved from the profile of three months ago. Slow drift is normal and worth knowing about. Sudden drift with no corresponding change record is itself a finding worth investigating.
One risk deserves explicit mention. If an attacker is already present during the learning window, their activity becomes part of normal and will never be flagged. Mitigate this by combining learned baselines with rules that do not depend on history, such as threat intelligence matching and policy-violation detection, as described in network traffic analysis techniques.
Common mistakes
- One baseline for the whole network. Averages away every meaningful difference between device roles.
- Using the mean. Skewed distributions make the mean unrepresentative of typical behavior.
- Alerting too early. A two-week baseline produces noise that destroys trust in the tool.
- Ignoring low-side deviation. Traffic dropping to zero is often the more urgent signal.
- Never refreshing. A baseline from 18 months ago describes a network that no longer exists.
- Baselining sampled data as if unsampled. On sampled exporters, small flows may be absent entirely, so peer-count baselines built from sampled data understate reality.
- Losing the documentation. If the baseline lives only inside the tool, nobody can review or challenge it. Export and version the profiles.
Baselining with NetFlow Analyzer
ManageEngine NetFlow Analyzer builds traffic profiles from flow exported by existing infrastructure, with grouping that supports role-based baselining instead of a single network-wide average.
Feature highlights
- IP group profiling: Define device groups by role and build separate baselines for each.
- Percentile-based reporting: 95th percentile utilization for capacity and billing, alongside median and distribution views.
- Learned traffic profiles: Behavioral baselines built from collected flow history, with learning periods that vary by detection rule. Some rules apply immediately, some need around a week of observation, and some need longer.
- Historical comparison: Compare current traffic against the same interval in prior periods to separate seasonality from change.
- Deviation alerting: Threshold, port, and volume-deviation rules with severity mapping and escalation into ITSM workflows.
Build baselines from the flow your network already exports.
Start your 30-day free trialFAQs
What is a network traffic baseline?
A documented description of normal behavior for a defined entity over a defined period, expressed with enough statistical detail to judge whether a new observation is unusual. The three load-bearing words are defined entity (an interface, device group, or host role rather than "the network"), defined period (accounting for daily, weekly, and monthly rhythms), and statistical detail (a distribution with percentiles rather than a remembered average).
How long does it take to baseline a network?
What metrics should a network baseline include?
Should baselines be per device or per group?
How often should baselines be updated?
What if an attacker is already inside during baselining?
By Shynu,
ManageEngine Team