Baselines Turn Activity Into Evidence

A log entry by itself is not a security conclusion.

Neither is a screenshot. Neither is a packet. Neither is an alert.

They are observations from a system. To decide whether an observation matters, you need something to compare it with.

That comparison point is a baseline.

A baseline answers “what should normal look like?”

Suppose an authentication log contains this event:

10:14:22Z user=alex client=LAB-07 result=ALLOW resource=/status

Is that good or bad?

You cannot tell yet.

If alex is an approved user and LAB-07 is an approved classroom device, the event may match expected behavior.

If the baseline says only the instructor account should access /status, the same event becomes evidence of a policy mismatch.

The event did not change.

Your context changed.

Build the evidence chain carefully

Use four levels when reasoning from technical artifacts.

1. Raw event

What did the source record?

Example:

10:14:22Z user=alex client=LAB-07 result=ALLOW resource=/status

2. Observation

Restate only what is directly visible.

The log records an allowed request by alex from LAB-07 to /status at 10:14:22Z.

3. Interpretation

Connect the observation to a baseline or rule.

The baseline states that students should have read-only status access, so this event is consistent with expected student access.

4. Claim

State the strongest conclusion your evidence supports—and no stronger.

This log entry does not show an access-policy violation for this request.

Notice the wording.

It does not say the system is secure. One event cannot prove that.

Synthetic evidence set

Use this fictional baseline for RNX-LAB-WEB-01:

Now inspect the supplied synthetic events:

10:02:10Z user=mia      role=student    client=LAB-03 result=ALLOW resource=/status
10:04:31Z user=unknown  role=none       client=LAB-11 result=DENY  resource=/status
10:07:05Z user=alex     role=student    client=LAB-07 result=ALLOW resource=/admin
10:09:42Z user=teacher  role=instructor client=LAB-01 result=ALLOW resource=/admin
10:12:16Z user=devon    role=student    client=LAB-22 result=ALLOW resource=/status

Do not jump straight to “attacker.”

The data does not identify motives.

It gives us events that can be compared with the baseline.

Work the evidence

Event 1

mia is a student on approved client LAB-03 reading /status.

Observation: allowed student access to the status resource.

Baseline comparison: expected.

Bounded claim: this event matches the documented access rule.

Event 2

An unknown user receives DENY for /status.

Observation: the service denied this request.

Baseline comparison: expected.

Bounded claim: the supplied log shows the denial control operating for this one request.

Do not say “unknown users cannot get in.” You only observed one denied request.

Event 3

A student account receives ALLOW for /admin.

Observation: an allowed admin-resource request is recorded for a student role.

Baseline comparison: unexpected.

Bounded claim: the observed authorization result conflicts with the stated baseline for /admin.

That is a strong finding because it connects a raw event to an explicit expected state.

Event 4

An instructor account receives ALLOW for /admin.

Matches the current baseline.

Event 5

A student uses client label LAB-22, but the baseline lists LAB-01 through LAB-20.

This is suspicious only in the technical sense that it conflicts with the documented client list.

It could mean:

• the client is unauthorized;
• the baseline is stale;
• the label is wrong;
• the inventory changed; or
• another system produced the record.

A good evidence record preserves those alternatives until more evidence eliminates them.

Evidence quality has dimensions

Not all evidence is equally useful. Ask these questions.

Source

Where did the artifact come from?

A service log, endpoint log, firewall record, configuration file, screenshot, and human memory each answer different questions.

Time

When was it captured?

Evidence without a time boundary is difficult to correlate.

Integrity

Was the artifact changed after capture?

In professional investigations, checksums, controlled storage, and chain-of-custody procedures may matter. In this classroom course, the minimum requirement is simpler: identify whether you are using an original supplied artifact, a copy, or your own notes.

Coverage

What part of the system can this source see?

An application log may show authentication decisions while saying nothing about network traffic that never reached the application.

Limitation

What can this artifact not prove?

This is the habit most people skip.

Build an evidence ledger

Create a table like this for the five events.

Your wording should make it possible for someone else to separate what the system recorded from what you concluded.

The claim ladder

Security conclusions should get weaker as evidence gets thinner.

Compare these statements:

Too strong:

The admin page is compromised.

Better:

A supplied log event records a student-role request being allowed to /admin, which conflicts with the stated instructor-only baseline.

The second claim is less dramatic and more useful.

It tells a defender exactly what must be verified next.

What evidence would you request next?

For Event 3, useful next evidence could include:

• the access-policy snapshot active at 10:07;
• the application version/configuration identifier;
• nearby authentication events for the same role;
• a controlled reproduction in the isolated lab; or
• confirmation that the baseline itself is current.

Notice what is missing from that list: random internet searching, probing unrelated systems, or assuming intent.

The next step follows the evidence gap.

Mini-check: fact or inference?

Classify each statement.

1. result=DENY appears in the supplied log.
2. The user was malicious.
3. The client label conflicts with the approved inventory list.
4. The system has definitely been breached.
5. The student-role admin event should be verified against the active policy.

Direct observations/comparisons: 1 and 3.
Unsupported inference: 2 and 4.
Defensible next action: 5.

Add the baseline to your Week 1 artifact

Write:

Expected state:
Evidence source:
Time window:
One event that matches the baseline:
One event that conflicts with the baseline:
Strongest claim supported:
One alternative explanation:
One additional source you would request:
One thing the current evidence cannot prove:

Lesson 3 will use the student-role /admin event as the starting point for a controlled defensive change.