Baselining Behaviour: Network Anomaly Detection Without the Noise

Overview

Alert fatigue is not a people problem. It is an architecture problem. When a detection system treats every novel event as a potential threat, analysts spend most of their time dismissing legitimate traffic rather than investigating real incidents. The four systems that form this detection stack — iMonitor, NetMon, NetPulse, and WraithNet — were built to solve that problem at its source: by understanding what normal looks like before trying to define what abnormal means.

The core insight is that a flat global threshold is not a baseline. It is a noisy rule with a more respectable name. A real baseline is entity-specific, time-aware, and tied to a catalogue of known-good operational behaviour. Deviation from that baseline — not deviation from an arbitrary number — is what makes an anomaly worth investigating.

Features

iMonitor — iOS Network Capture

iMonitor captures network traffic from iOS devices using a packet capture integration that parses connection data and ingests it through a secured internal endpoint. The ingestion path is separated from the admin API surface — internal events use a token-verified channel while the analyst dashboard uses authenticated sessions with full security headers enforced on every response. The backend stores connections, packet metadata, DNS queries, alerts, and statistics in a structured database. A live WebSocket stream feeds the React dashboard in real time, and an AI router connects to a local model for session-level anomaly summaries on demand.

NetMon — Three-State Baseline Engine

NetMon's baseline system operates in three explicit, manually-transitioned states. In the off state, every connection is evaluated by the full rule engine with no suppression. In learning mode, every external connection that passes the rule engine is recorded as a known-good behaviour — capturing which process connected to which destination under what conditions. In active mode, any connection that matches a recorded pair is suppressed before any rule evaluation occurs. The suppression is intentional and auditable — the state is stored in a file that can be inspected and changed at any time.

NetPulse — Connection Classification

NetPulse enumerates all active system connections on a configurable collection window and classifies every remote IP address into one of six categories: loopback, private, link-local, multicast, reserved, and public. This classification happens at collection time, not at query time. By the time a snapshot reaches the evaluation layer, every connection already carries a clean label. Public connections — particularly new ones — are the highest-value signal. Separating them from internal traffic at the collection boundary prevents the detection layer from treating all connections as equivalent.

WraithNet — Baseline-Aware Spike Detection

WraithNet reads NetPulse snapshots and maintains a learned baseline of average connection count and average public destination count across past samples. It does not activate spike detection until a minimum number of baseline samples have been collected — the system waits until it knows what normal looks like before it decides what a spike means.

Once the baseline is established, two spike conditions are evaluated on every snapshot. The first fires when the current connection count exceeds two and a half times the learned average, but only when the absolute connection count is also above a minimum floor. The second fires when the current public destination count exceeds three times the learned average, again only above a minimum floor. The floors prevent the multiplier from triggering on systems with very low baseline traffic. Both conditions produce structured findings with a severity label, a confidence value, and the current and baseline-average values that triggered them.

Explainable Findings

Every alert produced by this stack is self-explanatory. Each finding includes what happened, what the normal baseline was, how far the observation deviated, and the confidence the system assigns to the assessment. An analyst reading the alert does not need to query a separate system to understand why it fired. That explainability is structural — it is built into the finding schema, not added as an afterthought.

What It Resolved

The problem these systems were built to solve was an alert queue where the signal-to-noise ratio had inverted. Routine operational traffic — scheduled tasks, cloud sync, monitoring agents, backup jobs, software update checks — generated constant rule firings that had no threat value. Analysts who saw the same classes of alerts every day stopped reading them carefully.

The three-state baseline in NetMon resolved this by systematically removing known-good traffic from the evaluation surface. After a learning period, routine infrastructure is invisible to the rule engine. What remains in the alert queue is what has not been seen before — and that genuinely new behaviour is where investigation effort belongs.

WraithNet's multiplier-with-floor approach resolved the false-spike problem that comes with naive threshold-based anomaly detection. A system that normally makes two public connections would alert at six under a simple 3x rule, even though six connections is entirely unremarkable in absolute terms. The floor prevents that class of false positive without requiring manual tuning of per-entity thresholds.

The IP classification in NetPulse resolved the visibility problem at the bottom of the stack. When all connections are treated as equivalent, the detection layer cannot distinguish between a spike in internal database traffic and a spike in external public connections. Classifying at collection time makes that distinction immediate and consistent across every system that reads NetPulse data.

Usage

iMonitor runs on the network host connected to an iOS device, capturing traffic continuously and making it accessible through a secured dashboard. The analyst view shows connection history, DNS queries, traffic flows, and AI-generated session summaries. NetMon runs on the monitored host, evaluating every external connection in real time. Analysts interact with the dashboard to review alerts, manage the baseline, and clear or update the whitelist as infrastructure changes.

NetPulse runs as a background service collecting connection snapshots on a defined interval. WraithNet consumes those snapshots, evaluates them against the baseline, and produces structured security evaluations that include findings, risk scores, severities, and response actions.

Benefits

• Lower alert volume: baseline suppression removes known-good traffic from the evaluation surface, making what remains significant by default.
• No manual exception lists: learning mode builds the suppression layer from observed behaviour rather than requiring manual configuration that decays as infrastructure changes.
• Proportional thresholds: spike detection uses multipliers and absolute floors rather than static numbers, so the sensitivity scales with the actual baseline of each system.
• Clean separation between layers: collection, classification, baseline evaluation, and response are separate subsystems that can be updated independently.
• Immediate context on every alert: every finding includes the baseline values that triggered it, so analysts understand the deviation without querying a separate system.
• Consistent IP classification: the six-category scheme is applied at collection time, ensuring every system downstream works with clean, labelled data rather than raw strings.