Chapter 9 — Host and network evidence collection methods

Lesson map

Lesson 09 published. Map, example, EX033.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["9.1 The K9–K13 workshop boundary"]
  N2["9.2 Order by volatility, value and side effects"]
  N3["9.3 A byte-level receipt on an offline packet"]
  N4["9.4 Review a collection proposal"]
  N5["Subject synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX033"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["9.1 The K9–K13 workshop boundary"]
  N2["9.2 Order by volatility, value and side effects"]
  N3["9.3 A byte-level receipt on an offline packet"]
  N4["9.4 Review a collection proposal"]
  N5["Subject synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX033"]

[Learning outcomes and connection]
    |
    v
[9.1 The K9–K13 workshop boundary]
    |
    v
[9.2 Order by volatility, value and side effects]
    |
    v
[9.3 A byte-level receipt on an offline packet]
    |
    v
[9.4 Review a collection proposal]
    |
    v
[Subject synthesis]
    |
    v
[Worked example] --> [Exercise EX033]

Learning outcomes and connection

The learner will choose a collection order for host, gateway and application records, specify a narrow authority request, distinguish a network observation from an application outcome, and write a receipt for the bytes actually supplied. Chapter 8 compared failure explanations; Chapter 9 asks what evidence can test them before a volatile source disappears. Chapter 10 will use the resulting limits to evaluate a reversible containment proposal. NIST SP 800-86 describes files, operating systems, network traffic and applications as forensic data sources from an IT perspective. Published in 2006, it is neither a current command recipe nor legal advice. The collection packet below is original, fictional training material.

9.1 The K9–K13 workshop boundary

Chapters 9–13 share workshop K, an isolated classroom sequence. It is separate from the main N01–N06/I01–I02/H01/A01 LLR case and from the L8 packet. K records use new identifiers; similar service names do not merge those cases. AUTH-K permits a trainee to inspect the literal in-memory records printed in this book and to propose a collection plan. It does not permit a query, snapshot, capture, session change or reboot in any real environment. A real collector would need a named incident decision, approved system/field/time scope, a custodian, a privacy limit, a method and an expiration.

The synthetic question is: did a reservation write complete, and what might be lost if the runner restarts? At 12:06 UTC, the workshop provides the following claims:

Lesson table; scroll horizontally to read all columns →

An HTTP error, a nonzero byte count and a queued task can coexist. None answers whether a correct reservation exists in the authoritative store. Ask the database custodian for an approved, bounded write receipt and the service owner for a user-outcome check. Treat the two as separate questions: a database row might exist but be unavailable to a patron, and a successful display might be stale.

9.2 Order by volatility, value and side effects

For each possible source, write five fields before proposing a tool: decision value, loss window, owner, method/side effects, and authority state. The host's process list, live token reference, socket state and in-memory queue are volatile, but the packet supplies no measured expiry. The gateway ring is claimed to retain detailed flow entries for ten minutes after event time; if its claim applies to K-G1, the calculated deadline is 12:10:03. The application sample is claimed to retain 24 hours from ingestion, but its ingestion time is not supplied. A schedule at 12:07 raises urgency for owner contact without proving a reboot will occur. A volatile host request and a timed gateway request can be sent in parallel under an approved incident process. “Capture everything” is neither a collection order nor a privacy-bounded scope.

Different collection forms support different claims. A host status snapshot can show a process and boot identifier at collection time, not its whole lifetime. A process dump can contain secrets and alter host state; it needs a separate, more restrictive decision and method review. A flow summary can show reported endpoints, timing, volume and direction, not the application message or the principal behind it. A packet capture may contain more information, but access, storage, minimization and capture effects must be approved. An application access log might report an HTTP outcome while missing queue or database semantics. A database write audit may answer a commit question only if its producer, route coverage and transaction identifiers are validated.

The proposed K-REQ-1 asks the host owner for runner-02, process 420, boot b7, the 11:59:50–12:00:10 UTC interval and the current 12:06 status, with source clock and collection method. The proposed K-REQ-2 asks the gateway owner for only r-601/u-601 in 12:00:00–12:00:10, original object IDs, mapping semantics, event/ingestion times and ring-retention anchor. K-REQ-3 asks the application owner for u-601 queue disposition and the database owner for a bounded, authorized commit/rollback outcome. All three requests are pending; AUTH-K permits only planning with these already printed rows. If an owner cannot provide a source, record who answered, when, the attempted window and the resulting uncertainty.

9.3 A byte-level receipt on an offline packet

Run the following Python 3 listing offline. The literals are newly created classroom bytes. The script hashes the exact two supplied strings and prints lengths. It does not collect host memory or traffic. The full digest is useful for comparing these two copies later only if the expected digest is kept through a trusted path; it cannot authenticate a gateway or establish a complete export. Python's hashlib interface is the reference for the operation, not a claim about K-G1's origin.

from hashlib import sha256

packet = {
    "K-H1": b"boot=b7,process=420,started=11:59:54Z\n",
    "K-G1": b"edge=r-601,upstream=u-601,to_api=840,from_api=120\n",
}
for object_id, raw in packet.items():
    print(object_id, len(raw), sha256(raw).hexdigest())

In a receipt, record object ID, asserted producer, source custodian, authorized collector, approved method and scope, collection time, raw byte count, digest, copy identifier, access rule, parser/version and uncertainties. For this code, the producer is “exercise publisher,” the method is “literal in-memory copy,” and production origin is not claimed. Do not silently write “gateway export” as the producer. A derived table or screenshot needs its own object name and relationship to the raw input. If an approved live collection later used a different line ending, a digest difference could be caused by transformation; keep both bytes and explain the path rather than call it hostile alteration.

9.4 Review a collection proposal

Consider the tempting action “image runner-02 before the 12:07 restart and search all identity sessions.” It exceeds AUTH-K and may contain unrelated personal data, disrupt the runner, and consume time that could be used to preserve a narrow gateway record. Replace it with a two-track paper request: ask the host owner whether an approved, minimally invasive volatile-state capture is possible and ask the gateway custodian to preserve the stated short-window object under incident-lead approval. Ask the service owner whether delaying the scheduled restart is tolerable; a calendar entry alone is no permission to intervene. The collector must log side effects and keep a pre-change baseline. If the system is already down, a proposed capture method may differ from a live production method, but the authority and provenance questions remain.

Two negative controls keep the reasoning honest. First, compare a known in-range gateway control transaction with r-601 under the same source path; if it is missing, a negative r-601 result is weak. Second, ask whether boot b7 is present in a before/after inventory from the same host; a changed label in a different host is not evidence of a restart of runner-02. A control has to be documented and permitted; an analyst-created row in a spreadsheet is not a producer receipt. This is the boundary between a useful collection plan and an attractive narrative.

Common errors and limits

• Treating gateway bytes as proof that the API accepted or committed a reservation.
• Treating a scheduled reboot or claimed retention duration as an observed event or guaranteed deadline.
• Hashing a derived report while labeling the digest as the raw source object's digest.
• Prioritizing every volatile source without considering its decision value, invasiveness and owner.
• Expanding a proposed read to a live memory image or all-user identity export without approval.

Exercises — subject 9

EX033 — Collection matrix. Objective: choose evidence sources by decision. Using K-H1, K-G1/G2, K-A1 and the missing database outcome, write a four-row matrix with decision question, producer, owner, loss risk, approved method proposal and one inference each source cannot support. Evidence: Markdown matrix. Rubric: 2 = source limits and missing commit explicit; 1 = sources listed without loss/authority; 0 = claims the flow proves a commit.

EX034 — Priority and authorization. Objective: prepare a bounded 12:06 handoff. State which host and gateway owners to contact first, how the calculated 12:10:03 gateway deadline depends on an unverified retention claim, and why the host source has an unknown rather than infinite lifetime. Draft K-REQ-1 and K-REQ-2 with scope and approval status. Evidence: two requests and an order rationale. Rubric: 2 = parallel urgency, privacy and pending authority; 1 = order without scope; 0 = orders a live image under AUTH-K.

EX035 — Byte receipt. Objective: reproduce §9.3. Run the literal program, record both exact output lines, and write a classroom receipt for K-G1 with origin claim, count, digest role, method, access and limits. Change one byte in a separate copy and explain what a mismatch proves. Evidence: transcript and two version labels. Rubric: 2 = exact outputs and bounded integrity claim; 1 = hashes without provenance; 0 = calls the packet an authenticated production capture.

EX036 — Network-versus-outcome review. Objective: reject an overclaim. A peer says “840 bytes reached the API, so the reservation was committed and no host evidence matters.” Write a corrected claim ladder from K-G1 through K-A1 to the missing database receipt; add one positive and one negative source-coverage control and an owner-approved next request. Evidence: short review memo. Rubric: 2 = transport, queue and commit separated; 1 = uncertainty without discriminator; 0 = retains the commit claim.

Subject synthesis

Collection starts with a decision and a permitted scope. K9 supplies two byte strings and four producer claims, not a certified incident package. The result is a collection plan and classroom receipt; the reservation outcome remains unknown. Chapter 10 will ask which reversible control could be considered if a harmful action is confirmed and authority is granted.