How can you tell the difference between normal network activity and an attack?

Every business network contains unusual activity. An employee logs in earlier than usual. A workstation suddenly starts communicating with a new external service. A server receives hundreds of connection attempts within a few minutes. A device transfers significantly more data than it normally does.

None of these events automatically means that an attack is taking place.

This is one of the fundamental challenges of cybersecurity monitoring. Modern networks generate enormous amounts of activity, and legitimate behaviour is rarely perfectly consistent. Users change locations, applications update, cloud services create new connections, automated processes run in the background, and business operations naturally change throughout the day.

The real question is therefore not simply whether something unusual happened.

It is whether the unusual activity makes sense in the context of everything else happening around it.

What does normal network activity actually look like?

There is no universal definition of normal network behaviour.

A manufacturing company may have machines communicating continuously with a small number of internal systems, while an office environment may generate constantly changing connections to cloud applications, collaboration platforms and remote services. A company operating several locations will have a different traffic pattern again, particularly when VPN connections, remote employees and centrally managed infrastructure are involved.

Even within the same organisation, normal behaviour changes over time.

A backup server transferring large amounts of data at 2 a.m. may be completely expected. The same volume of traffic leaving an employee workstation for an unfamiliar external destination could deserve immediate attention. Hundreds of authentication attempts against a remote service may indicate an attack, but similar activity from an internal management system could be part of a legitimate automated process.

This is why security monitoring cannot rely only on fixed assumptions about what network traffic should look like.

It needs context.

An anomaly is not the same thing as an attack

Anomaly detection is often described as the ability to identify activity that differs from an established pattern. In practice, however, detecting something unusual is only the first part of the problem.

An anomaly is simply a deviation from expected behaviour.

A user connecting from a new location is an anomaly. A server communicating with an IP address it has never contacted before is an anomaly. A sudden increase in DNS requests may be an anomaly. A device generating significantly more outbound traffic than usual may also be an anomaly.

All of these can have legitimate explanations.

The difficulty begins when security systems treat every deviation as an incident. The result is a large number of alerts, many of which require investigation but ultimately turn out to be harmless. If this happens continuously, security monitoring becomes less effective rather than more effective.

The objective should therefore not be to detect as many anomalies as possible. It should be to identify which anomalies become meaningful when placed in context.

The difference often appears in the sequence

Consider a simple authentication event.

A failed VPN login is extremely common. Someone may have mistyped a password or a device may still be using an old credential. Even several failed attempts may not be particularly interesting.

Now imagine that the same external IP address attempts dozens or hundreds of logins against several accounts within a short period.

The event has changed.

Add another piece of information: after the repeated failures, one authentication succeeds.

The situation changes again.

If the authenticated account then begins accessing systems or network segments it does not normally use, the individual events start forming a sequence that deserves significantly more attention.

None of the signals necessarily provides the complete answer on its own. Their relationship does.

The same principle applies elsewhere in the network. A DNS request to a previously unseen domain may be harmless. A new outbound connection may also be legitimate. Increased data transfer may have a perfectly reasonable explanation. But if all three occur on the same workstation within a short period, immediately after another suspicious event, the combined pattern can tell a very different story.

This is why effective detection increasingly depends on correlation rather than isolated alerts.

Why multiple data sources matter

A firewall sees one part of the environment. Authentication systems see another. DNS services, VPN infrastructure, intrusion detection systems, endpoints and network devices each provide different pieces of information.

Looking at only one of these sources can make suspicious activity appear harmless.

A firewall, for example, may correctly allow a connection because it complies with the configured policy. From the firewall's perspective, nothing necessarily went wrong. But the fact that a connection was permitted does not tell us whether the user making it had just experienced dozens of failed authentication attempts, whether the destination is unusual for that device, or whether another security system detected suspicious behaviour immediately beforehand.

The same applies to blocked traffic.

A blocked connection demonstrates that a security control performed its job. It does not necessarily explain what caused the connection, whether the same source tried another route afterwards, or whether similar activity appeared elsewhere in the infrastructure.

The value emerges when these separate observations can be connected.

Instead of asking only:

"Was this connection allowed or blocked?"

the more useful questions become:

"What happened before it? Which user and device were involved? Has this behaviour occurred before? What happened immediately afterwards? Did another security system observe related activity?"

That is the difference between collecting events and understanding them.

Why false positives are such a difficult problem

Security systems need to be sensitive enough to detect suspicious behaviour without turning every unusual event into an emergency.

This balance is difficult because real environments are messy.

Users make mistakes. Applications behave unexpectedly. Software updates change communication patterns. New cloud services appear. Remote employees connect from different networks. Automated systems generate bursts of activity that may look suspicious when viewed without context.

If detection rules are too broad, the organisation receives too many alerts.

If they are too narrow, genuinely suspicious behaviour may remain unnoticed.

The problem is not merely inconvenience. When administrators or analysts repeatedly investigate alerts that turn out to be harmless, attention becomes a limited resource. Important signals can disappear among routine warnings.

Reducing false positives therefore does not simply mean generating fewer alerts. It means improving the quality of the information used to decide which activity deserves attention.

Historical behaviour, device identity, user activity, timing, destination, frequency and related security events can all help transform an isolated anomaly into something that can be assessed more reliably.

Baselines help, but networks never stand still

One way of identifying unusual behaviour is to establish a baseline: an understanding of how users, devices and systems normally behave.

This can be extremely useful.

If a workstation normally communicates with twenty predictable services and suddenly starts making repeated connections to dozens of unfamiliar destinations, that change is worth examining. If an account normally logs in during business hours from a consistent environment and suddenly authenticates remotely at an unusual time, that may also deserve attention.

But baselines cannot be static.

Businesses introduce new applications. Employees change roles. Infrastructure is replaced. New locations are opened. Cloud services are adopted. Remote working patterns change.

A security system that treats yesterday's behaviour as a permanent definition of normality will eventually generate noise rather than useful insight.

The challenge is therefore not simply learning what is normal. It is recognising when normal behaviour legitimately changes while still identifying deviations that may represent genuine risk.

Context changes the meaning of an event

This is perhaps the most important principle in modern security monitoring.

An event rarely has a fixed meaning.

Ten failed logins from one employee may be a forgotten password. Ten failed logins across ten accounts from the same external source may indicate reconnaissance or credential testing. A successful login is normally expected activity. A successful login immediately following hundreds of failed attempts may deserve investigation.

A large outbound data transfer may be a scheduled backup. The same transfer from a workstation that has just communicated with an unusual external host may represent a completely different situation.

Security therefore cannot be reduced to a simple distinction between "good traffic" and "bad traffic".

What matters is behaviour, relationships and sequence.

From anomaly detection to understanding

This is also where AI-assisted analysis can become useful.

The purpose of AI in security monitoring should not simply be to create another stream of alerts. Its real value appears when it helps analyse relationships between events, identify patterns across different data sources and present those relationships in a form that an operator can understand.

Instead of seeing hundreds of individual log entries, the operator should be able to understand that one device experienced repeated authentication attempts, established a successful session, contacted an unusual destination and subsequently generated abnormal outbound traffic.

The individual logs still matter. But the security decision comes from the story they form together.

This is the approach behind ITPACK SHIELD. Network and security events are not treated only as separate entries to be stored and searched. The objective is to correlate relevant activity, analyse its context and help determine which patterns require attention.

The technology does not remove the need for human judgement. It helps make that judgement possible when the volume and complexity of events become too large to evaluate manually.

The real challenge is not detecting unusual activity

Most organisations already have systems capable of generating security information.

Firewalls produce logs. VPN systems record authentication. DNS infrastructure records requests. Intrusion detection systems generate alerts. Endpoints and network devices continuously describe what is happening around them.

The harder problem is deciding what those signals mean together.

A network without anomalies would be unusual in itself. Normal business activity constantly creates deviations, exceptions and unexpected events. The goal of security monitoring cannot therefore be to eliminate unusual behaviour or investigate every deviation.

It is to recognise when several ordinary-looking signals stop being ordinary because of the way they connect.

An attack does not always announce itself with one obviously malicious event. Sometimes it appears only when the events before and after it are finally seen as part of the same story.

And that is why visibility alone is not enough.

The real value lies in understanding what the network is trying to tell you.