A Log Records a System's View

Logs are one of the most useful defensive evidence sources because they can preserve what a system believed happened at a particular time.

That phrase — what a system believed happened — is important.

A log entry can be incomplete, delayed, misconfigured, duplicated, missing, or generated from a clock that is wrong.

Useful does not mean perfect.

Read a log as structured evidence

Supplied fictional authentication event:

2026-08-11T14:03:22.418Z source=auth-service event=login account=alice result=success method=training-mfa request_id=rnx-441

Break it into fields:

A strong claim:

The supplied auth-service record reports a successful fictional login decision for account Alice at the represented timestamp using the training-MFA method and request ID rnx-441.

A weak claim:

Alice definitely logged in at exactly that real-world moment and nobody else could have been using the account.

The log alone does not prove the human or the accuracy of every field.

Event time, ingestion time, and observation time can differ

A system may record:

event_time=14:03:22
ingested_at=14:03:29

That seven-second gap may be normal buffering, network delay, queueing, or load.

For some investigations the distinction matters.

A centralized platform may sort by ingestion time even when the original event timestamp is earlier.

So ask:

• when did the source say the event occurred?
• when did the collector receive it?
• when did an analyst observe it?

These are different times.

Good logs answer operational questions

A useful event often includes enough context to answer:

• what happened?
• where?
• which account/service identity was involved?
• what object/action was targeted?
• what result occurred?
• which request/change/session can connect it to other evidence?

But more fields are not always better.

Do not log secrets just because debugging would be easier.

Sensitive data creates a logging boundary

Avoid recording:

• passwords;
• authentication secrets;
• full API/session tokens;
• private student records;
• unnecessary message/file contents;
• unrelated personal identifiers.

Logs have access-control and retention requirements because they can become sensitive datasets themselves.

Event naming should be stable

Compare:

Something bad happened

with:

event=authorization_decision action=update_match_note decision=deny reason=role

Stable event names and fields make searching, correlation, and alert logic much more reliable.

Activity: build an event dictionary

Use these supplied events:

event=login

event=authorization_decision

event=role_change

event=service_health

event=config_change

event=backup_result

For each, define:

source component
required fields
optional fields
sensitive fields prohibited
one operational question the event can answer
one question it cannot answer alone

Logs need provenance too

When you export or screenshot evidence, record:

• source system;
• query/filter used;
• represented time window;
• timezone;
• whether fields were transformed;
• whether records were sampled; and
• whether the export is complete.

Without provenance, a beautiful timeline can still be misleading.

Synthetic event set

14:03:22.418 auth-service login alice success request=rnx-441
14:03:22.604 status-web request /admin role-check request=rnx-441
14:03:22.607 status-web authorization deny role=viewer request=rnx-441
14:03:22.610 status-web response status=403 request=rnx-441

These four records can be correlated through rnx-441.

They support a stronger story than a single 403 line because they show the represented authentication and authorization chain.

Begin your Telemetry and Timeline Record

Create:

1. source inventory;
2. event dictionary for six events;
3. prohibited logging fields;
4. timestamp/timezone convention;
5. correlation fields; and
6. one narrow claim based on the supplied request chain.

Lesson 2 combines multiple independent sources into a timeline.