Chapter 5 — Security scope and evidence

Lesson map

Lesson 05 published. Map, example, EX017.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["5.1 Authority has fields, not a feeling"]
  N2["5.2 Original bytes, derived rows and receipts"]
  N3["5.3 Worked decision: reject expansion, preserve a us"]
  N4["5.4 Reproducibility and limitation checklist"]
  N5["5.5 Custody is a sequence of bounded claims"]
  N6["5.6 Offline byte-identity and privacy replay"]
  N7["Subject synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX017"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["5.1 Authority has fields, not a feeling"]
  N2["5.2 Original bytes, derived rows and receipts"]
  N3["5.3 Worked decision: reject expansion, preserve a us"]
  N4["5.4 Reproducibility and limitation checklist"]
  N5["5.5 Custody is a sequence of bounded claims"]
  N6["5.6 Offline byte-identity and privacy replay"]
  N7["Subject synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX017"]

[Learning outcomes and connection]
    |
    v
[5.1 Authority has fields, not a feeling]
    |
    v
[5.2 Original bytes, derived rows and receipts]
    |
    v
[5.3 Worked decision: reject expansion, preserve a us]
    |
    v
[5.4 Reproducibility and limitation checklist]
    |
    v
[5.5 Custody is a sequence of bounded claims]
    |
    v
[5.6 Offline byte-identity and privacy replay]
    |
    v
[Subject synthesis]
    |
    v
[Worked example] --> [Exercise EX017]

Learning outcomes and connection

The learner will distinguish a proposed evidence request from an approved scope, demonstrate byte-level integrity on an offline copy, and write a receipt that lets another operator reconstruct who collected what and when. Chapter 4 produced accepted and rejected rows; Chapter 5 asks whether the original and derived objects can be traced to a custodian and whether the requested collection was permitted. Chapter 6 will use those limits when comparing response options. NIST SP 800-61 Rev. 3 places response actions and records within risk management; NIST SP 800-86 describes IT forensic practice and data sources. The latter dates from 2006 and is not a current OS tool recipe or legal opinion. The L5 receipt is an original classroom design.

5.1 Authority has fields, not a feeling

“We need the logs” is not a collection scope. A technical request names the case identifier, decision question, source system, object or query, time window, fields, permitted method, privacy limit, collector, authorizer, expiration, storage destination and prohibited expansions. It also identifies the owner who can explain producer semantics. Read permission for an edge snippet does not automatically authorize a tenant-wide identity export, a database copy, a host memory image or a production configuration change. A responder can prepare a narrow proposal while these approvals remain blank.

For this chapter only, branch AUTH-L5 is an invented classroom approval card: at 12:06 UTC it permits an offline trainee to inspect the literal L4 CSV and a supplied in-memory byte string, with no live systems, no personal data and no external network. It expires at the end of the exercise. That card is not a retrospective approval for the Chapter 3 proposal concerning r-202, nor authority for an actual LLR tenant. A separate overbroad request says “export all identity sessions, image runner-02 and restart the API.” The trainee must reject that request: neither the source scope nor the change is covered by AUTH-L5. The appropriate next action would be a bounded new request to the relevant custodians and service owner, not an improvised expansion.

This distinction has technical consequences. If an export command searches too wide a time interval, it may disclose unrelated records and consume the evidence source while the desired short-retention rows expire. If a collector changes a live file's access time or rotates a log, the action can alter the evidence being measured. The answer is not a universal “never touch”; it is a documented, approved method selected for the decision, with known side effects and an alternative if a source is too volatile. The lab below deliberately avoids these operational risks by creating bytes in memory.

5.2 Original bytes, derived rows and receipts

Name three objects separately. Original is the exact supplied byte sequence. Working copy is a copy of those bytes in a controlled workspace. Derived report is the parser's accepted/rejected summary, with code and parameters. A SHA-256 digest over bytes can detect a difference between two objects if the expected digest itself came from a trusted path; it cannot certify the source system, the collector's authorization, the row semantics, completeness of a query or the absence of an earlier alteration. Python's hashlib documentation specifies the byte-hashing interface used in the demonstration. The lab's digest comparison is a teaching check, not a certified custody process.

Run this with Python 3. It reads no external file. The content is a deliberately tiny fictional line set; the corrected variant changes one event ID. The expected printed result is given below so a learner can verify the distinction without treating a hexadecimal digest as a magical truth label.

from hashlib import sha256

original = b"event_id,event_utc\nE1,2026-10-11T12:00:03Z\n"
working = bytes(original)
altered = original.replace(b"E1", b"E9", 1)
print("original_bytes:", len(original))
print("copy_matches:", sha256(original).digest() == sha256(working).digest())
print("altered_matches:", sha256(original).digest() == sha256(altered).digest())

The model output is original_bytes: 43, copy_matches: True, altered_matches: False. Verify the byte count locally. The result does not prove that the original bytes came from an edge server; the code constructed them. In a real approved collection, record the source object identifier and retrieval method alongside the digest, then make the independently held original available for authorized review. A digest of a normalized CSV is a different claim from a digest of raw export bytes. Do not compare them and call a mismatch “tampering” when the transformation itself changed line endings or encoding.

A minimal receipt for L5 would have: classroom object L5-original; custodian “exercise publisher”; supplied 12:06 UTC; collector “trainee”; AUTH-L5 scope; exact byte count and SHA-256 hex value; method “literal in-memory copy”; working-copy identifier; derived parser version; access restriction; no production claim. A later correction should be an additional receipt with a new version and reason, never a replacement that deletes the first. For a production process, the organization must choose its own retention, chain-of-custody and legal controls; this book does not provide a legal standard.

5.3 Worked decision: reject expansion, preserve a useful gap

Suppose the learner wants to explain why the L4 CSV lacks an accepted API row for r-201. Under AUTH-L5, the trainee may inspect only the supplied teaching bytes and record the accepted/rejected counts. The card does not authorize a live API query. The proper handoff distinguishes:

Lesson table; scroll horizontally to read all columns →

The table is a technical control on language. A respondent can say “this fixture has no accepted API r-201 row” and cite the parser, but should not say “there is no API evidence.” The latter conflates supplied scope with universe of possible records. A rejected malformed row may be relevant to quality even if unusable for a direct join. Keep it visible in the package.

5.4 Reproducibility and limitation checklist

Another trainee should be able to run the same code and compare the same bytes. Supply the original literal data, interpreter version, parser code/version, check order, selected time window, acceptance criteria and expected output. Ask a second trainee to introduce a one-byte variant and verify that the original digest remains unchanged while the variant digest differs. Then ask the harder question: what does that prove about LLR? The correct answer is “nothing about the origin or truth of LLR records beyond the supplied fixture.” A reproducible transformation supports review of a method, not independent authentication of a source.

5.5 Custody is a sequence of bounded claims

An evidence register separates authorization, acquisition, transformation and interpretation. Authorization names who allowed which source, fields, method and interval. Acquisition records the bytes actually received, source object, collector, time and receipt. Transformation identifies input/output objects, code version and rejected records. Interpretation says what the derived view supports and where it stops. None substitutes for another: a digest is not permission; permission does not prove query completeness; a clean parser run does not prove its rows describe true events.

For AUTH-L5, the trainee may compare classroom bytes. If a form asks for a “production collection time,” the truthful entry is not applicable/unknown rather than the exercise's 12:06 supply time. The L4 parser summary is a different derivative with its own source. Do not claim the 43-byte L5-original contains the full L4 CSV: it has only a two-column header and one row. To demonstrate the L4 parser's lineage, hash the actual L4 text separately and link that object to the parser run. This catches a common custody error: attaching the digest of one toy object to another because both appear in the same lesson.

Lesson table; scroll horizontally to read all columns →

The table is a technical checklist, not a universal legal chain-of-custody rule. For a real investigation, the responsible organization defines disclosure, retention and review with its own policy and counsel. NIST SP 800-86 supplies historical forensic-process vocabulary, but its 2006 publication cannot replace current source-specific procedures.

5.6 Offline byte-identity and privacy replay

Take the exact in-memory original from §5.2. In a separate L5-B variant, replace each LF newline byte with CRLF before computing a digest. The original has two LF bytes, so the variant has 45 bytes, compared with the original's 43. The two digests should differ even if a text editor displays similar lines. Report “different byte serialization,” not “attacker tampering.” Then make a byte-for-byte copy of L5-B and confirm that its digest equals L5-B's digest. The expected equality pattern is original = original copy; original ≠ CRLF variant; CRLF variant = its copy. None of the equalities authenticates an exporter.

For a proposed r-202 mapping request, compare two paper scopes. Request A asks for all employees' IdP sessions for a week. Request B asks the identity custodian whether a documented mapping exists for the single request and a short justified window, with field-level access and a retention deadline. AUTH-L5 authorizes neither real request, but B is a more bounded candidate for the incident, identity and privacy approvers. If that source does not exist, note the availability gap rather than silently expanding to A. If short-lived records will expire, escalate the approval decision promptly; urgency does not create collection authority.

Worked review result: an adequate L5-B report lists 43 and 45 bytes, the three equality claims, object IDs, and the scope boundary. It rejects “matching hashes prove r-201 never reached the API,” because the classroom object is not a complete API corpus and a hash cannot establish producer coverage. The next chapter uses this four-gate model to compare a response option against a justified target and the service outcome.

Common errors and limits

• Treating a request for evidence as approval to collect it.
• Hashing only a reserialized report and calling it the source object's digest.
• Assuming equal digests establish source authenticity, authority or completeness.
• Deleting the rejected-row report because it complicates a narrative.
• Expanding a read-only scope into process termination or service restart.

Exercises — subject 5

EX017 — Scope gate. Objective: enforce a written boundary. Inputs: AUTH-L5 and the overbroad request in §5.1. Classify each proposed action (read L4 CSV, compute its digest, export all IdP sessions, image runner-02, restart API) as allowed or not allowed; name a custodian and approval needed for one rejected source request. Evidence: five-row decision table. Rubric: 2 = only the offline actions allowed and no implied production permission; 1 = one scope ambiguity; 0 = performs or recommends an unapproved real action.

EX018 — Byte-integrity lab. Objective: reproduce and interpret §5.2. Run or inspect the code, record all three exact output lines, then change E9 to E1 in the variant and state which comparison changes. Explain why equal bytes do not authenticate the source. Evidence: transcript and limitation. Rubric: 2 = exact byte count/booleans and semantic limit; 1 = booleans without source caveat; 0 = calls the original a verified edge export.

EX019 — Collection receipt. Objective: make a derived claim traceable. Write a receipt for L5-original and a separate one for L5-altered with object name, origin claim, authority, collector, collection time, byte count or check result, method, digest role, storage/access rule and relationship between versions. Leave any unknown source fields explicitly unknown. Evidence: two Markdown receipts. Rubric: 2 = versioned, distinguish original from variant and avoid false provenance; 1 = hashes only; 0 = rewrites the first receipt as if no change occurred.

EX020 — Evidence-package review. Objective: catch a misleading claim. A peer writes “sha256 matched, therefore r-201 never reached API.” Identify at least three separate inference errors and rewrite the conclusion in a source-bounded sentence. Name one approved discriminator and one privacy boundary. Evidence: review note. Rubric: 2 = byte equality, source completeness and ID semantics separated; 1 = generic uncertainty; 0 = retains the unsupported universal claim.

Subject synthesis

Authority controls what may be collected; provenance controls what may be claimed; a digest controls only a defined byte comparison. A technically clean result can still be outside scope or epistemically weak. Chapter 6 will use these distinctions to model service impact and compare response choices without executing them.