Remote Access Is Not Just a VPN Problem

1. A log is evidence, not an explanation

A log records that something happened.

It does not automatically explain why it happened or whether it was malicious.

Consider an authentication event showing a successful login.

By itself, that event tells us very little.

It becomes more useful when additional context is available:

Was the login expected?

Were there failed attempts immediately before it?

Which account was used?

From which device or address did it originate?

Was the user normally active at that time?

What happened after authentication?

The same applies to endpoint and network events.

A process execution event may be normal administrative activity or part of an attack.

A firewall connection may represent legitimate application traffic or lateral movement.

A DNS request may be harmless browsing or communication with attacker-controlled infrastructure.

Logs therefore provide observations.

Investigation provides interpretation.

The goal is not to make every event generate an alert. The goal is to preserve enough reliable evidence to understand activity when context becomes important.

2. Time turns isolated events into a sequence

Incident investigation depends heavily on chronology.

One event may look unremarkable. Five related events occurring within several minutes can tell a completely different story.

For example:

Several failed authentication attempts occur.

A successful login follows.

A new process starts on the endpoint.

The endpoint connects to an internal server it does not normally access.

An administrative action occurs shortly afterwards.

Each event may exist in a different system.

Authentication logs describe the login.

Endpoint telemetry records the process.

Firewall or network logs record the connection.

Server logs record the administrative action.

The investigation becomes useful when those events can be placed on the same timeline.

This is why accurate timestamps and consistent time synchronization matter.

If systems disagree about time, investigators may misread the order of activity or spend unnecessary effort determining which event happened first.

During an incident, time is not merely metadata.

It is part of the evidence.

3. Authentication logs tell you about identity activity

Authentication data is often one of the first places to look during an investigation.

It can show:

• successful logins;
• failed login attempts;
• account lockouts;
• remote-access authentication;
• privileged account activity;
• changes in authentication behavior.

But the useful signal is usually not one isolated login.

Patterns matter.

Repeated failures followed by success may deserve attention.

A privileged account authenticating from an unexpected endpoint may require investigation.

An account becoming active at an unusual time may be significant when combined with other evidence.

Authentication logs help answer:

• Who appeared to access the system?
• When did that access occur?
• From where did it originate?
• Was the attempt successful?
• Was the same identity active elsewhere?

They provide the identity layer of the investigation.

They do not prove that the legitimate user was behind the keyboard.

That distinction matters.

A valid account can still be compromised.

4. Endpoint logs show what happened after access

Authentication tells us that access occurred.

Endpoint telemetry can show what happened next.

Depending on the available tooling, useful evidence may include:

• process creation;
• parent-child process relationships;
• command execution;
• file creation or modification;
• security-control changes;
• network connections;
• USB activity;
• service creation;
• persistence-related changes.

The relationship between events is often more important than the individual event itself.

For example:

A user opens a document.

The document launches another process.

That process starts a command interpreter.

The command interpreter connects to an external address.

Viewed separately, the environment contains several events.

Viewed as a chain, the investigator sees behavior.

This is where endpoint visibility becomes particularly valuable.

It helps move the investigation from:

“An account logged in.”

to:

“After the login, this sequence of activity occurred on the device.”

That is a much stronger basis for deciding whether an incident is real, how serious it is, and what should be contained.

5. Network logs show where activity tried to go

Endpoint evidence explains behavior on the host.

Network evidence helps show where that behavior reached.

Firewall, VPN, DNS, proxy and other network logs may reveal:

• source and destination;
• protocol and service;
• allowed or denied connections;
• remote-access sessions;
• DNS lookups;
• unusual internal communication;
• Internet destinations.

This is especially important when investigating possible lateral movement.

A compromised workstation may attempt to reach servers, management interfaces or other endpoints.

Even if those connections are denied, the attempts themselves provide useful evidence.

A deny log can therefore be as valuable as an allow log.

The important questions are:

• What did the device attempt to reach?
• Which connections were allowed?
• Which were blocked?
• Was the destination normal for that system?
• Did the same pattern appear elsewhere?

Network logs help define the potential scope of the activity.

6. Correlation creates context

The strongest investigation rarely depends on one log source.

Useful conclusions usually appear when several sources support the same sequence.

Consider a simplified example.

Authentication logs show that an account connected remotely.

Endpoint telemetry shows a command interpreter starting shortly after the connection.

DNS logs show a request to an unusual domain.

Firewall logs show an outbound connection from the same device.

Server logs later show the same account accessing an internal resource.

No single event proves the entire incident.

Together, they establish context.

This is the practical purpose of correlation.

It connects:

• identity;
• device;
• process;
• network activity;
• destination;
• time.

The result is not simply more data.

It is a more defensible explanation of what occurred.

7. Collection without retention and accessibility is not enough

Logs are useful only if they still exist when the investigation begins.

Some incidents are detected immediately.

Others are discovered days or weeks after the original activity.

If relevant records have already been overwritten, the organisation may know that something happened without being able to reconstruct how.

Retention therefore needs to reflect operational and investigation requirements.

But retention alone is not enough.

Logs must also be searchable and accessible.

An environment can technically retain large amounts of data while still making investigation painfully slow because events are distributed across systems, stored in inconsistent formats, or accessible only through individual consoles.

A practical logging model should consider:

• what events are important;
• where they are collected;
• how long they are retained;
• whether timestamps are reliable;
• who can access them;
• how quickly they can be searched during an incident.

The objective is not to collect everything forever.

The objective is to retain the evidence most likely to support investigation and response.