Angstep Ltd - Netmon Blogs

Behavioural Baselines: Turn Routine Network Data Into Earlier Warnings

Most monitoring tools tell you when something has already failed.

A device goes offline. A service stops responding. A scan finds a vulnerability. An alert arrives, a ticket is raised, and someone starts investigating. That is useful—but it is reactive. By the time a server is unavailable or a user reports an issue, the early warning signs may have been visible for hours, days, or even weeks.

Netmon’s new behavioural baseline capability helps MSPs spot those signs sooner.

Rather than requiring another agent, another dashboard, or a separate security product, Netmon learns from the monitoring and discovery data it already collects. It builds an understanding of what is normal for each managed device: its usual latency, expected online hours, and the ports and services it normally exposes. It then flags meaningful deviations from that established pattern.

That makes monitoring more intelligent. Instead of asking only, “Is this device up?”, Netmon can start asking, “Is this device behaving as it normally does?”

For an MSP, that distinction matters. It can mean finding a failing connection before a client calls, detecting unexpected access before it becomes an incident, and demonstrating a more proactive level of service at every client review.

The Limits of Simple Up/Down Monitoring

Traditional network monitoring is built around clear, binary events. A host responds to a ping or it does not. A port is open or closed. A threshold is exceeded or it is not.

Those alerts remain essential, but real networks are rarely that simple.

A server can be online while responding increasingly slowly. A workstation can be reachable but active at a highly unusual time. A printer can remain available for printing while suddenly exposing a remote-management service it has never used before.

None of these conditions necessarily means there is an attack or outage. They do mean something has changed—and in managed IT, unexplained change is worth understanding.

Consider a few practical examples:

A workstation that is normally asleep every evening comes online at 3am
A printer that usually exposes printing services suddenly opens port 22, commonly used for SSH
A device’s latency doubles and remains elevated over time, rather than briefly spiking during normal network activity
A server begins exposing a database or file-sharing port that was not previously present
A device that is normally stable starts dropping in and out of availability throughout the day

A conventional monitoring system may not treat these events as urgent. The device could still be “up,” and the new port might not appear in a basic availability check. But behavioural baselining gives those changes context.

It does not just identify a state. It identifies a departure from the device’s own normal behaviour.

What Netmon Learns

Behavioural baselines work because Netmon already has visibility across the client network. Its continuous device discovery identifies assets on the LAN, including workstations, servers, printers, cameras, network equipment, and IoT devices. Live availability checks, latency measurements, packet-loss history, and service discovery provide the raw evidence needed to understand how those devices behave over time.

The new feature uses that existing information to establish normal patterns for each device.

Expected Online Patterns

Many devices follow predictable schedules.

Office workstations may be active during business hours and quiet overnight. A reception PC may be online from early morning until the end of the working day. A server may be continuously available. A warehouse terminal may only be used during a specific shift.

When a device appears outside its usual pattern, Netmon can alert the MSP to investigate.

That does not automatically mean a compromise. An employee might be working late, an update may have restarted a machine, or a user may have taken a device home and connected through an expected route. But it creates a useful, auditable question: why is this device active now?

This is particularly valuable for unattended assets. A device unexpectedly coming online overnight may indicate an unauthorised user, a scheduled task, a Wake-on-LAN event, a reboot following patching, or a change in working practice that the MSP has not been told about. The point is not to assume the worst; it is to make unusual activity visible rather than allowing it to disappear into the background.

Typical Latency and Performance

Momentary latency changes are normal. Networks get busy, Wi-Fi conditions change, backups run, and internet connections occasionally suffer a brief wobble.

Persistent degradation is different.

Netmon can learn what typical latency looks like for an individual device, then highlight when that latency remains materially above its usual level. That is far more useful than reacting to every temporary spike or relying on one global threshold that does not suit every environment.

For example, a device that normally responds in a few milliseconds but begins responding at twice its established baseline may be experiencing:

Wi-Fi interference or weak signal strength
A developing cable, switch-port, or network-interface fault
Network congestion caused by backups, cloud synchronisation, or unexpected traffic
A VPN, routing, or internet connectivity issue
Resource pressure on the endpoint itself
A problem that will soon become a visible outage

This gives technicians the chance to investigate when the issue is emerging, rather than waiting until users complain that systems feel slow or unreliable.

Combined with Netmon’s latency and packet-loss history, the baseline helps differentiate a brief, harmless event from a trend. It shifts the conversation from “there was a spike” to “this device has been consistently performing outside its normal range since yesterday afternoon.”

That is a much stronger basis for proactive support.

Usual Ports and Services

Open ports are not automatically dangerous. A printer needs relevant print services. A server may legitimately expose web, database, file-sharing, or remote-management services. A camera or IoT device may have its own required ports.

The real concern is often not that a port is open, but that it has changed.

Netmon learns which ports a device normally exposes and alerts when a new service appears. This can reveal accidental configuration changes, unapproved software, an exposed management interface, or potentially malicious activity.

Imagine a standard office printer that normally offers its expected printing services but suddenly exposes port 22. SSH may have been enabled through a firmware update, a configuration change, or an administrator’s troubleshooting activity. Equally, it may warrant an urgent security check.

Likewise, a workstation unexpectedly exposing Remote Desktop, file sharing, a database listener, or a web-management interface creates a clear question for the MSP: was this approved, and is it safe?

This is where behavioural baselines become especially powerful alongside Netmon’s vulnerability scanning and risky-service detection. The baseline tells you that a service is new. Netmon can then help determine whether that service is associated with known CVEs, actively exploited threats, or risky exposure that needs attention.

That is much more actionable than receiving an isolated list of open ports with no sense of whether they have always existed.

Better Signal, Less Alert Fatigue

One of the biggest problems in managed monitoring is alert fatigue.

If technicians receive too many low-value alerts, important warnings get buried. A system that cries wolf constantly does not improve security or service; it simply moves the burden from machines to people.

Behavioural baselines help focus attention on changes that matter.

Rather than treating every 100\text{ms} latency event as a possible incident, Netmon can distinguish between ordinary variation and a persistent deviation from a device’s established pattern. Rather than producing a static port list, it can point out that a device now exposes something it did not before.

This context helps reduce noise without reducing visibility.

It also supports better triage. A technician can investigate alerts with a more informed starting point:

What is unusual?
When did the change begin?
Is the device otherwise stable?
Has latency, packet loss, availability, or service exposure changed at the same time?
Does the new service create a known vulnerability or security risk?
Is the device expected to be active at this time?

Those are the questions that turn an alert into an investigation—and an investigation into a defensible technical decision.

Stronger Security Through Context

Cybersecurity is often about detecting abnormal behaviour before the impact becomes obvious.

A behavioural baseline cannot replace endpoint protection, patching, access control, backups, or human judgement. What it can do is provide an additional, network-level layer of awareness across the devices Netmon discovers and monitors.

This is particularly useful because networks contain more than managed laptops and servers. They contain printers, cameras, routers, switches, smart devices, specialist equipment, and other assets that may not run a conventional endpoint agent.

These devices are often overlooked, yet they can introduce significant risk. They may be unpatched, poorly documented, or changed by suppliers, installers, or firmware updates without the MSP receiving an alert.

Netmon’s auto-discovery ensures those devices are visible. Behavioural baselines then help make their changing behaviour visible too.

When Netmon identifies an unfamiliar device, the MSP can use its trust workflow to approve and document it. When a trusted device changes its normal behaviour, the baseline can raise the next question. Has the device changed legitimately, or has something happened that needs investigation?

This creates a practical security workflow:

Netmon discovers the device.
The MSP identifies and trusts expected assets.
Netmon learns normal availability, latency, and services.
A meaningful deviation triggers an alert.
Netmon’s vulnerability and risky-service information helps assess the security impact.
The technician investigates, remediates, or records an accepted risk with a required note.

The outcome is not simply more data. It is a clearer chain of evidence and decision-making.

From Detection to Resolution

Monitoring becomes much more valuable when it links directly to action.

Netmon already supports automatic ticket creation when real-world device performance goes wrong. Behavioural baselines improve the quality of the trigger conditions behind those tickets. Instead of opening work only when a device disappears entirely, Netmon can identify persistent performance deterioration or unexpected behavioural change before service failure.

That gives MSP teams more time to respond calmly and methodically.

For some investigations, Netmon’s built-in remote access lets a technician connect directly to the relevant managed device from the dashboard. There is no need to move between separate remote-access tools, monitoring consoles, spreadsheets, and scanner reports just to establish what has happened.

Where remediation is appropriate, technicians can also run common Windows and Linux scripts from the main dashboard. That might support diagnostics, collect further evidence, verify a configuration, stop an unwanted service, or apply an approved fix.

The advantage is operational as well as technical. A behaviour alert is not left as a vague security observation; it can become a managed workflow from detection through investigation, remediation, and documentation.

More Valuable Client Reporting

Clients do not always see the work that prevents problems.

They see the outage that did not happen, the suspicious change that was investigated before it became serious, or the slow device that was fixed before staff began complaining. That is excellent service—but unless it is reported clearly, it can remain invisible.

Netmon’s branded, plain-English security reporting helps MSPs show the value behind that proactive work.

Behavioural baselines add a compelling story to those reports. Instead of only listing devices, vulnerabilities, and scan results, an MSP can demonstrate that it monitors for changes in normal operation:

Devices active outside expected hours
Persistent performance degradation
New network services and unexpected exposure
Newly discovered or unapproved assets
Risks identified, investigated, remediated, or formally accepted

This is more understandable to a non-technical client than a raw port scan or a page of CVE references. It connects technical monitoring to a business outcome: reducing disruption, finding risk earlier, and maintaining oversight of the client’s environment.

It also provides useful evidence during service reviews. If a client asks, “What are we paying you for?”, the answer becomes concrete. Netmon has not merely checked whether devices are online. It has continuously learned what normal looks like, detected when normal changed, and enabled the MSP to act before that change became a larger problem.

A Smarter Use of Existing Monitoring

The strongest benefit of Netmon’s behavioural baseline capability is that it makes existing data more useful.

MSPs do not need to deploy yet another point product simply to identify unusual device activity. Netmon brings together continuous discovery, availability checks, latency and packet-loss tracking, port and service visibility, vulnerability intelligence, risky-service detection, remote access, scripts, ticketing, risk acceptance, and client-ready reporting.

A new port is no longer just an open port; it is a change from known normal behaviour. A latency rise is no longer just a number; it is a persistent decline from an established performance level. A workstation online overnight is no longer an unnoticed event; it is an exception that can be checked, explained, and documented.

For MSPs, that means fewer blind spots, more useful alerts, earlier intervention, and stronger evidence of proactive service.

Netmon already helps you monitor, secure, and report on client networks from one platform. Behavioural baselines take the next step: helping you recognise when a network is not simply online, but no longer behaving as it should.

Born in Colwyn Bay North Wales, Steve's introduction IT & Computers was at secondary school in 1974. That first year, Machine Code was hand written onto gridded paper and sent to Connah's Quay Technical College where is was copied to punch card and then entered into a mainframe computer. The results printed out were sent back for the following week! Yes Steve was around before the Internet and was coding the hard way.

Steve left School in 1976, or as he prefers to say, “I ran away from home and joined a flying circus” - joining the Royal Air Force to work as an Electronics Engineer on analogue and digital RADAR and communications equipment. His last 5 years in the RAF he worked in an Automatic Test Equipment (ATE) department on the System Management Team and also writing models for Microchips. It was a good job that he had kept up with computers which had become rather a passion by the time he started in ATE. After 8 specialist programming courses for ATE Programming and a Cluster Start Course for System Administration, Steve was one of the most flexible people in the department.

During that time the main Mainframe we replaced in a £3.9 million upgrade reducing the run time of the biggest ATE program from just under 2 weeks to the time it took for a finger to come off a depressed return key!

Leaving the RAF after 18 years’ service, Steve worked for a Charity (Apex Leicester Project) before returning to electronics at Sonatest in Milton Keynes which after 3 or 4 years led to a Job at Telematica; the then development arm of Trafficmaster PLC (Tm). Eventually brought in-house at Tm he worked moved into the IT Support Team of 5 people looking after 300 users in the UK as well as sites in Italy, Germany and Benelux countries – 24x7 cover. His last project moving email from a Linux Box to Microsoft Exchange for the 300 users in the company each of whom typically had 5 email addresses.

In 2006 Steve left to start his own company back in North Wales, Computer Technical Solutions Ltd (CTS) was an MSP and became an MSSP following another of Steve's passions Cybersecurity. Whist working full time running CTS, Steve completed a Masters Degree in Computer Science with Cybersecurity at Wrexham University.

Officially semi-retiring in 2025, by May 2026 that overactive mind started thinking about all of the software he had seen not just for MSSPs but also for his clients that was either extremely expensive or that didn't exist with a complete answer to the needs of the SME.

By August 2026 Angstep Ltd was formed and two significant pieces of software had been created. Netmon the Network Monitoring Software and the second release Parkcore aimed at Caravan/Lodge Holiday Parks, now in the final development stages and under Beta Release. Determined, focused and loving life… And so, it begins!