YanoSecA log records events according to a system’s configuration. An access log may record a resource request; an authentication log may record a login check. Correlation compares related records using a shared request identifier and a known time basis rather than merely similar text.
The supplied files are fiction. Their request IDs connect events in this story, and both give the same date and UTC basis. Z after a time denotes UTC in this notation. A source address or account label is not a verified person, and an incomplete or inaccurate real log can support less than a neatly ordered table suggests.
Before you begin
- Recommended first
- Hex, Base64, and XOR in code, Encoding, hashing, and encryption, Notes: scope, command, result, time, PCAP triage
- Estimated time
- 15 min reading, 15 min activity. Setup and optional practice may take longer.
- Where you work
- Read the supplied byte tables and authored records in any browser, with paper or a text editor. Preserve original files; inspect copies in any later lab. No scanner, image decoder, capture, memory acquisition or installation is required. Practical tool work remains separate from this reading activity.
- Without a lab
- All evidence needed for the activity appears on this page. Copy it into notes if downloads are unavailable. Read the labeled model and predict each result; a paper trace practises the reasoning while tool operation waits for a lab. Reading needs no JavaScript. Answer checking needs JavaScript and a secure context; saving progress also needs usable browser storage.
After this lesson you can:
- Put the 11:00:09 access line and the 11:00:12 auth-ok line in order.
- Use UTC and the shared date before comparing.
- Call the account name a label in the fiction.
01Example
Fresh worked event order, separate from the packet’s R-19 activity and R-20 checkpoint.
Authored request R-30, same date and UTC basis:
12:03:04Z access
12:03:06Z auth fail
12:03:09Z auth ok
Order: access, failed check, successful check.
The later success does not erase the earlier failure.02Same clock, then the seconds
First compare dates and zones. Then select the same request identifier before ordering its times. In real systems, clock skew means clocks disagree; ordering nominal timestamps does not prove clocks were synchronized. Missing or rotated records may also leave events outside your evidence.
The time-basis note describes the packet rather than guaranteeing a complete real audit trail. Record exactly the listed events and their sources. Avoid turning a shared IP address into attribution to a human.
Order authored request R-30 conditionallyModel. A teaching model drawn by hand. It shows the idea, not real tool output.
Read the full explanation below.
Authored fictional records · not captured incident traffic
Date basis: same date; calendar date not specified. Zone: UTC. Clock skew: not measured.
Basis pending · exact request pending
Supplied source excerpts, original line numbers
Worked authored R-30 example
| Original line | Exact quoted source |
|---|---|
| 1 | Authored request R-30, same date and UTC basis: |
| 2 | 12:03:04Z access |
| 3 | 12:03:06Z auth fail |
| 4 | 12:03:09Z auth ok |
| 5 | Order: access, failed check, successful check. |
| 6 | The later success does not erase the earlier failure. |
Event 1: not ordered yet
Event 2: not ordered yet
Event 3: not ordered yet
No event selected. Read the source and check the time basis before ordering.
The later success does not erase the failure. Nominal timestamp order depends on the supplied basis; clocks may disagree and history may be incomplete.
Read the complete supplied source excerpts before ordering any events.
Follow the explanation
- Read the complete supplied source excerpts before ordering any events.
- Check the explicit shared date relationship and UTC basis; clock accuracy remains unmeasured.
- Select exact request R-30 before ordering its timestamps.
- 12:03:04Z: access. Retain the exact source citation.
- 12:03:06Z: auth fail. Retain the exact source citation.
- 12:03:09Z: auth ok. The prior failure remains part of this chronology.
- Keep all three records and the limits on identity, clock accuracy, completeness and causality.
Complete conditional chronology · R-30
Authored fictional records. Date: same date; calendar date not specified; UTC; clock skew not measured.
Basis citations: Worked authored R-30 example line 1.
| UTC time | Event | Source |
|---|---|---|
| 12:03:04Z | access12:03:04Z access | Worked authored R-30 example, line 2 Context: Worked authored R-30 example, line 1 |
| 12:03:06Z | auth fail12:03:06Z auth fail | Worked authored R-30 example, line 3 Context: Worked authored R-30 example, line 1 |
| 12:03:09Z | auth ok12:03:09Z auth ok | Worked authored R-30 example, line 4 Context: Worked authored R-30 example, line 1 |
Worked authored R-30 example
| Original line | Exact quoted source |
|---|---|
| 1 | Authored request R-30, same date and UTC basis: |
| 2 | 12:03:04Z access |
| 3 | 12:03:06Z auth fail |
| 4 | 12:03:09Z auth ok |
| 5 | Order: access, failed check, successful check. |
| 6 | The later success does not erase the earlier failure. |
- Authored fictional records: account labels are not verified people; documentation address 192.0.2.44 is not identity.
- Clock accuracy and skew are unmeasured. Nominal order is conditional on the supplied same-date UTC basis, not proof of real event causality.
- The packet need not be complete history. A later success does not erase an earlier failure.
- Equal timestamps retain source order; their internal order is unknown without further evidence.
03Order request R-19
Work only on R-19, with UTC and 2026-04-02 as the printed basis. The later independent pair uses another request.
Order only authored request R-19Model. A teaching model drawn by hand. It shows the idea, not real tool output.
Read the full explanation below.
Authored fictional records · not captured incident traffic
Date basis: 2026-04-02. Zone: UTC. Clock skew: not measured.
Basis pending · exact request pending
Supplied source excerpts, original line numbers
access-demo.log
| Original line | Exact quoted source |
|---|---|
| 1 | Label: original fictional access lines. Not a server log. |
| 2 | Timezone basis: UTC. Date: 2026-04-02. |
| 3 | 11:00:09Z access GET /drawer request R-19 |
| 5 | Source address on both lines: 192.0.2.44 |
| 6 | That address is a documentation address. It does not identify a person. |
auth-demo.log
| Original line | Exact quoted source |
|---|---|
| 1 | Label: original fictional authentication lines. Not a server log. |
| 2 | Timezone basis: UTC. Date: 2026-04-02. |
| 3 | 11:00:10Z auth fail account lamp request R-19 |
| 4 | 11:00:12Z auth ok account lamp request R-19 |
| 7 | An account name on a line is a label in this fiction. It does not identify a real person. |
timezone-note.txt
| Original line | Exact quoted source |
|---|---|
| 1 | Label: time basis for the two fictional logs. |
| 2 | Both files say UTC and the date 2026-04-02. |
| 3 | Compare times only when the date and the zone label match. |
| 4 | A gap in the file is possible. The displayed event rows are the whole packet. |
| 5 | Clock skew was not measured. No host was contacted. |
Event 1: not ordered yet
Event 2: not ordered yet
Event 3: not ordered yet
No event selected. Read the source and check the time basis before ordering.
The later success does not erase the failure. Nominal timestamp order depends on the supplied basis; clocks may disagree and history may be incomplete.
Read the complete supplied source excerpts before ordering any events.
Follow the explanation
- Read the complete supplied source excerpts before ordering any events.
- Check the explicit shared date relationship and UTC basis; clock accuracy remains unmeasured.
- Select exact request R-19 before ordering its timestamps.
- 11:00:09Z: access. Retain the exact source citation.
- 11:00:10Z: auth fail. Retain the exact source citation.
- 11:00:12Z: auth ok. The prior failure remains part of this chronology.
- Keep all three records and the limits on identity, clock accuracy, completeness and causality.
Complete conditional chronology · R-19
Authored fictional records. Date: 2026-04-02; UTC; clock skew not measured.
Basis citations: timezone-note.txt line 2; access-demo.log line 2; auth-demo.log line 2.
| UTC time | Event | Source |
|---|---|---|
| 11:00:09Z | access11:00:09Z access GET /drawer request R-19 | access-demo.log, line 3 |
| 11:00:10Z | auth fail11:00:10Z auth fail account lamp request R-19 | auth-demo.log, line 3 |
| 11:00:12Z | auth ok11:00:12Z auth ok account lamp request R-19 | auth-demo.log, line 4 |
access-demo.log
| Original line | Exact quoted source |
|---|---|
| 1 | Label: original fictional access lines. Not a server log. |
| 2 | Timezone basis: UTC. Date: 2026-04-02. |
| 3 | 11:00:09Z access GET /drawer request R-19 |
| 5 | Source address on both lines: 192.0.2.44 |
| 6 | That address is a documentation address. It does not identify a person. |
auth-demo.log
| Original line | Exact quoted source |
|---|---|
| 1 | Label: original fictional authentication lines. Not a server log. |
| 2 | Timezone basis: UTC. Date: 2026-04-02. |
| 3 | 11:00:10Z auth fail account lamp request R-19 |
| 4 | 11:00:12Z auth ok account lamp request R-19 |
| 7 | An account name on a line is a label in this fiction. It does not identify a real person. |
timezone-note.txt
| Original line | Exact quoted source |
|---|---|
| 1 | Label: time basis for the two fictional logs. |
| 2 | Both files say UTC and the date 2026-04-02. |
| 3 | Compare times only when the date and the zone label match. |
| 4 | A gap in the file is possible. The displayed event rows are the whole packet. |
| 5 | Clock skew was not measured. No host was contacted. |
- Authored fictional records: account labels are not verified people; documentation address 192.0.2.44 is not identity.
- Clock accuracy and skew are unmeasured. Nominal order is conditional on the supplied same-date UTC basis, not proof of real event causality.
- The packet need not be complete history. A later success does not erase an earlier failure.
- Equal timestamps retain source order; their internal order is unknown without further evidence.
Label: original fictional access lines. Not a server log.
Timezone basis: UTC. Date: 2026-04-02.
11:00:09Z access GET /drawer request R-19
10:00:02Z access GET /board request R-20
Source address on both lines: 192.0.2.44
That address is a documentation address. It does not identify a person.
Label: original fictional authentication lines. Not a server log.
Timezone basis: UTC. Date: 2026-04-02.
11:00:10Z auth fail account lamp request R-19
11:00:12Z auth ok account lamp request R-19
10:00:05Z auth ok account desk request R-20
The 10:00:05 line is a different request from the 11:00 lines.
An account name on a line is a label in this fiction. It does not identify a real person.
Label: time basis for the two fictional logs.
Both files say UTC and the date 2026-04-02.
Compare times only when the date and the zone label match.
A gap in the file is possible. The displayed event rows are the whole packet.
Clock skew was not measured. No host was contacted.
- Find the R-19 row in access-demo.log and the two R-19 rows in auth-demo.log. Exclude R-20 before sorting.
- Write 11:00:09Z, 11:00:10Z and 11:00:12Z in order with access, auth fail and auth ok beside them.
- Write a supported chronology and a limit: the fictional account lamp is a story label, not a verified person, and clock accuracy is not measured.
- Stop with that note. Do not look up the documentation address or seek a real account.
04Optional challenge
In about ten optional minutes, remove the timezone label from a copy of one R-19 line in your notes. Explain why comparing it with the remaining UTC lines now requires additional time information. Keep the original evidence unchanged.
05Fresh cases for the checks
Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.
Log packet A — original fictional records, shuffled source order; no system was contactedOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Time basis: full calendar dates, UTC (Z). Compare the recorded timestamps on that basis.
Clock accuracy and synchronization were not measured; this is not a proof of causality.
The packet may omit other events. Row numbers below are source citations.
1 | 2026-05-11T00:00:01Z auth fail account cedar request R-81 source auth.log
2 | 2026-05-10T23:59:57Z auth ok account birch request R-810 source auth.log
3 | 2026-05-11T00:00:03Z auth ok account cedar request R-81 source auth.log
4 | 2026-05-10T23:59:58Z access GET /parcel request R-81 source access.log
Log packet B — separate fictional evidence; all timestamps are 2026-06-14 UTCOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Clock accuracy is unmeasured. These rows do not establish a complete history or a person's identity.
B1 | 10:04:08Z auth ok account pine request R-520 source auth.log
B2 | 10:04:07Z auth fail account ash request R-52 source auth.log
B3 | 10:04:06Z access GET /shelf request R-52 source access.log
B4 | 10:04:09Z auth ok account ash request R-52 source auth.log
Log packet C — separate incomplete fictional copy after one record was lostOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Basis: 2026-07-09 UTC. Clock accuracy is unmeasured.
C1 | 08:12:04Z access GET /box request R-73 source access.log
C2 | 08:12:06Z auth fail account willow request R-73 source auth.log
These are all surviving records available for this question.
The missing record's contents are unknown; no other history or identity evidence is supplied.
Log packet D — optional fictional comparison with a missing time basisOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
D1 | 2026-08-03T09:20:00Z access request R-94 source access.log
D2 | 2026-08-03 09:19:59 auth ok request R-94 source auth.log
The second source provides no timezone or UTC offset. No clock comparison is supplied.
06Optional evidence note
Spend up to five minutes writing a short note about one packet. Include its provenance, exact request ID, a source citation, a supported observation, and one limit.
Self-check: state that these records were authored for the course, preserve the date and timezone basis, and separate recorded order from causality. Do not turn an account label into a verified person or a missing record into a known result. This note is self-reviewed, not automatically graded.
07Common mistakes
If a nearby row is included, check its request ID before its time; R-20 is separate evidence.
If an IP is described as a person, reduce the claim to the address recorded in the fictional log.
If a timestamp is treated as a guaranteed physical order across hosts, ask about clock synchronization and recording delay.
References
- RFC 5737: documentation IPv4 addresses
Background on documentation addresses, timestamps or interpreting recorded evidence.