Chapter 18 — Supervised technical incident case and handoff | Technical Incident response and cyber resilience

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 18 published. Map, example, EX069.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["18.1 Stage the case without backdating knowledge"]
  N2["18.2 Required dossier and evidence manifest"]
  N3["18.3 Supervised walkthrough and peer challenge"]
  N4["18.4 Closing the loop"]
  N5["Subject synthesis"]
  N6["Subject 1: EX001–EX004"]
  N7["Subject 2: EX005–EX008"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX069"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["18.1 Stage the case without backdating knowledge"]
  N2["18.2 Required dossier and evidence manifest"]
  N3["18.3 Supervised walkthrough and peer challenge"]
  N4["18.4 Closing the loop"]
  N5["Subject synthesis"]
  N6["Subject 1: EX001–EX004"]
  N7["Subject 2: EX005–EX008"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX069"]

[Learning outcomes and connection]
    |
    v
[18.1 Stage the case without backdating knowledge]
    |
    v
[18.2 Required dossier and evidence manifest]
    |
    v
[18.3 Supervised walkthrough and peer challenge]
    |
    v
[18.4 Closing the loop]
    |
    v
[Subject synthesis]
    |
    v
[Subject 1: EX001–EX004]
    |
    v
[Subject 2: EX005–EX008]
    |
    v
[Worked example] --> [Exercise EX069]

Learning outcomes and connection

The learner will integrate the course's architecture, evidence, parser, timeline, control and recovery methods into a supervised, versioned case dossier. The assessment is not whether the learner can tell the most confident story; it is whether another operator can reproduce the evidence trail, see an unresolved question, find the correct decision owner and safely continue. Chapter 17 gave candidate tests; Chapter 18 separates evidence released at different times and asks the learner to update conclusions without hindsight. The exercise structure draws on incident coordination in NIST SP 800-61 Rev. 3 and exercise design in NIST SP 800-84, an older publication used here for planning/evaluation concepts, not for a current tool procedure.

18.1 Stage the case without backdating knowledge

K18 remains a fictional continuation of the K workshop, not a new fact about the main LLR case. The instructor releases four cards in order. Learners must preserve a dossier version after each release. Do not use a later card to make an earlier decision appear obvious.

Lesson table; scroll horizontally to read all columns →

Card and release	Supplied classroom material	What it can and cannot establish
C18-A, start	K12 raw/derived manifest, I1/I2/H1/A1 accepted, A2 and duplicate A1 rejected; K13 AL13-A/B	Exact parser and rule outputs; neither DB commit nor human attribution.
C18-B, after first note	IdP/app custodians validate that s-7 denotes the same session namespace for I1 and A1 in the bounded interval; they do not map s-8 to s-7	Strengthens one session association, not a DB outcome or a malicious-intent claim.
C18-C, after revised timeline	In an explicitly synthetic variant, the DB owner provides a versioned receipt that r-601 rolled back; a read-only check finds R40/R41 unchanged in that snapshot	Resolves r-601's stored outcome in this branch; does not prove why D15's patron report occurred or whether other routes were affected.
C18-D, final review	Service owner says the patron-visible booking discrepancy persists in the lab UI despite the C18-C DB state; index/cache telemetry and a matching patron-reservation ID are not supplied	Requires an application/index investigation; cannot be erased by the rollback receipt.

C18-C is a new branch release for assessment. It must not be retroactively described as a K12 database receipt. The original K12 packet still lacks one. C18-D may be a delayed projection or a different booking; without a validated mapping, neither is a conclusion. The defender's response at each stage is a bounded request and decision, not a production command. At C18-A and B, the safe control state is pending. At C18-C, do not claim “resolved”: a particular rolled-back request is narrower than service correctness. At C18-D, the next test is a privacy-bounded, owner-approved patron/reservation mapping and index/cache lineage check.

18.2 Required dossier and evidence manifest

Write a cover sheet with case ID, revision, time zone, decision lead, technical lead and purpose. Then attach a source manifest: object ID, source custodian, source claim, version, method/authority, supplied event and collection times, original-byte digest if measured, access rule and known limitation. A training packet can say “not supplied”; it must not fabricate a hash or a chain-of-custody event. Make an accepted-versus-rejected ledger with K12's three app raw rows, one accepted and two rejected. If a derived K14 flag appears, link it to its accepted input row and algorithm version, never to “system truth.”

The timeline has four columns at minimum: observed record, producer and clock confidence, relationship to another record, and unresolved alternative. Keep D15's support-desk report in its own lane. The hypothesis log should name at least two alternatives: an application/index projection issue and a write-path or authorization problem. For each, list a discriminating read-only source and a result that would weaken it. State the difference between no receipt supplied, receipt says rollback, and no write occurred anywhere. Only the middle claim is supported after C18-C, and only for r-601 in this branch.

The decision log uses explicit verbs: requested, approved, simulated, executed, verified, rejected. Do not write “contained” for a K10/K17 toy predicate. A safe entry might be “Requested DB outcome for r-601; pending C18-A,” later “C18-C simulated DB receipt reviewed; this branch shows rollback; no production action executed.” Store source, reviewer and time of the change. A handoff must include the previous and next case version, why a hypothesis changed, stop condition, privacy boundary, service acceptance state and next owner's name. This is especially important when a night shift inherits an impressive looking but incomplete dashboard.

18.3 Supervised walkthrough and peer challenge

Allocate one learner as operator, one as evidence reviewer, one as service owner and one as incident lead. The operator may work only with released cards. The reviewer asks whether every factual assertion has a source pointer and whether exceptions survived transformation. The service owner tests R40/R41 and patron read as separate outcomes. The incident lead distinguishes a classroom plan from any real approval. Run a short tabletop: at each release, pause, file the current version and name one decision you would not make yet. The peer then introduces a falsifier, such as a failed in-range app control or a cache record from a different patron. Revision must be additive; retain the earlier version.

Assess the dossier on five dimensions, each scored 0–2: provenance (raw/derived and exceptions traceable), inference (literal versus validated joins), safety (authority, stop and rollback states), service verification (R40/R41/patron outcome) and handoff (versioned next test and owner). Maximum 10. A score of 8 with zero on safety or provenance does not pass: those are mandatory gates. An assessor should accept different hypotheses if their discriminating tests and uncertainty are explicit. A polished narrative with no source IDs scores poorly. This capstone measures technical reasoning in a controlled learning packet, not professional certification.

18.4 Closing the loop

The best final statement is intentionally limited: “In the C18 branch, I1/A1 session namespace is validated; the supplied C18-C DB receipt reports r-601 rolled back; the reported patron discrepancy remains unresolved; no production containment or recovery is evidenced here.” The team can recommend an approved index/cache and patron-mapping check, with careful handling of personal data. If that test later contradicts the rollback receipt, open a new version and ask the DB/application owners to reconcile source semantics; do not delete the contradiction. The case is ready for handoff, not for a claim of universal resolution.

The course's 18 subject drafts and 72 worked exercises form an initial technical manuscript. They do not meet the required 300 verified A4 pages or complete the source, technical, language and accessibility reviews. Work through the answer appendix as a checking tool after attempting the tasks. Then use the chapter index to continue the larger curriculum in the next course; do not treat its plan chapters as finished lessons.

Exercises — subject 18

EX069 — Staged case versions. Produce v1 after C18-A, v2 after C18-B, v3 after C18-C and v4 after C18-D. Each version must name newly supported claims, claims still unsupported and one owner-approved next observation. Evidence: four dated, source-linked entries. Rubric: 2 = no hindsight and preserved versions, 1 = good final note but earlier versions overwritten, 0 = calls C18-C a K12 fact.

EX070 — Manifest and exception reconciliation. Build a seven-row minimum manifest/ledger covering I1, I2, H1, accepted A1, rejected A2, rejected duplicate A1 and the separate C18-C receipt. Include method, version, raw/derived status, authority and unknown fields. Explain why the K14 output digest cannot authenticate the DB receipt. Evidence: manifest and exception table. Rubric: 2 = source lineage and no invented metadata, 1 = rows without version/authority, 0 = silently accepts rejected rows.

EX071 — Safety and service peer review. Given a peer claim “C18-C rollback proves the incident ended; revoke svc-book just in case,” write a two-paragraph review with the exact narrower finding, unresolved D15/C18-D discrepancy, approval status, R40/R41 and patron checks, stop condition and a falsifiable next test. Evidence: peer review. Rubric: 2 = rejects both unsupported resolution and unsupported action with a concrete alternative, 1 = caution without test, 0 = approves broad revocation.

EX072 — Final handoff and rubric. Submit a 250–350-word shift handoff with case/version, evidence manifest pointer, accepted/rejected counts, validated and unvalidated joins, C18-C scope, service status, action inventory, decision owner, privacy rule, next test and rollback/stop status. Self-score the five 0–2 dimensions and ask a peer to mark one difference. Evidence: handoff and scored review. Rubric: 2 = complete reproducible handoff and honest gate, 1 = useful summary missing one required transition, 0 = claims a course or incident finished from a plan.

Subject synthesis

A technical responder finishes a handoff by making uncertainty usable: another operator knows what was seen, which copy was checked, what was rejected, who may decide, what changed and what to test next. This closes the authored chapter sequence, while substantial expansion and editorial validation remain before the book can be published as complete.

EX001 — Model service map. A complete map lists edge → api (gateway owner; decide whether the user request reached upstream; static health coverage unverified), api → idp,db (application/identity/database owners; decide authorization and stored reservation outcome; fallback/clock coverage unverified), worker → idp,db (job owner; decide whether scheduled work can continue; retry behavior unverified), backup → db (recovery owner; decide whether new copies can be made; isolated restore not demonstrated), and idp/db as producers with no further dependencies supplied. That is six rows if idp and db are separate. A reviewer should reject a diagram that reverses the arrows or calls the simplified graph complete. Two points require an owner and a falsifiable unknown for every row; a valid alternative owner title is acceptable if its decision right is specified.

EX004 — Model change comparison. “At 12:04 the edge error and unfinished worker run are reports, not proof that svc-reserve is malicious. A targeted pause of one verified out-of-scope task might limit unwanted changes while preserving the approved worker; its target and scheduler scope must first be confirmed. Revoking the shared principal would affect api/worker dependency paths and may stop legitimate R40/R41 work. I request read-only owner-approved API, IdP and job records before any change. If a continuing harmful task is confirmed, the service and identity owners should approve the exact target, operator, expiry, rollback owner and expected effect. The request must record who observed the task, when the observation was made, and which evidence would falsify the concern. Positive test: no further out-of-scope R42 changes in a stated window. Negative/business test: approved R40/R41 operation continues. Approval, execution and verification remain pending.” Different prose can pass if it names both options, risks, boundaries and falsifiable checks.

EX005 — Model claim ladder. N01: one supplied resolver answer; not proof the browser used it. N02: client-to-edge TCP completed; not proof the API was reached. N03: edge reports TLS completion; not proof of app authorization. N04: edge returned 503 for GET /rooms, first observed failure of the expected room-list outcome; not proof of API crash or attack. N05: no r-201 in the supplied 10-second API sample; not proof the API never received a request. N06: static /health returned 200 at 12:03; not proof the affected /rooms function recovered. Six bounded pairs and N04 as failure stage earn two points. A learner may note that client certificate validation is not supplied; that is a useful limitation, not a contradiction.

EX008 — Model cautious handoff. “At 12:00:00 a supplied resolver row gave portal.example.test a 60-second TTL; this does not prove which resolver answer the browser used throughout that minute. At 12:00:01–03, the edge recorded a connection, TLS completion and a 503 for GET /rooms with r-201 and an upstream-timeout label. The supplied API sample has no r-201, but source coverage and ID mapping are unknown. A 12:03 static /health 200 tests a different endpoint and does not establish room-list or write-path recovery. Under the owners' read-only permission, request bounded edge upstream and API logs with producer clocks and request-ID semantics. Record the query window and the custodian's coverage statement. Do not restart a service or name an attacker from this packet.” A result may use different wording but must keep event times, endpoint distinction and an owner-led discriminator.

EX069 — Model four-version ledger. V1/C18-A: literal K12/K13 observations, three raw app rows/one accepted/two rejected; no validated cross-producer session or DB outcome; request bounded mapping and DB receipt. V2/C18-B: owner-validated I1/A1 s-7 namespace; I2 s-8 remains separate; DB outcome and D15 mapping unknown; request DB outcome. V3/C18-C: a new branch receipt reports r-601 rolled back, R40/R41 unchanged in its snapshot; D15 remains unjoined and other routes unknown; request patron/reservation and projection lineage. V4/C18-D: service owner reports a still-visible UI discrepancy in the lab; no ID/cache/index telemetry; investigate the privacy-bounded projection and reconcile with DB owner. Each version retains earlier sources and its release time; do not backfill V1 with C18-C.

EX070 — Model manifest. Seven rows: K12 raw idp I1 and I2 (accepted by K12-derived-v1); raw host H1 (accepted); raw app A1 (accepted); raw app A2 (bad time, rejected); raw later app A1 (duplicate source ID, rejected); C18-C DB receipt (new assessment branch source and version, not K12). For each, fill custodian, claimed source object, permitted method/authority, raw/derived status and supplied times; where the prompt gives no byte digest, collection time or actual access receipt, write not supplied. Keep the derived K12 view and K14 review packet as separately linked artifacts, rather than calling them originals. The K14 digest fingerprints K14's canonical derived bytes; it cannot prove who produced the C18-C DB receipt or authenticate raw K12 objects.

EX071 — Model peer review. “The C18-C branch receipt, if validated under its stated source semantics, reports r-601 rolled back. It does not show that all routes had no unauthorized writes or that the incident ended. D15 and C18-D describe a patron-visible discrepancy without a matching reservation ID or projection source. I would request an incident-lead-approved, privacy-minimized mapping and an app/index/cache lineage check with in-range source controls; a matching healthy projection would weaken the lag hypothesis, while a mismatched owner-approved ID would change the question. No production containment has been approved or executed in this exercise. Broad svc-book revocation would endanger R40/R41 work, as the K17 simulated test showed, and lacks a validated continuing-harm trigger. The owners should preserve raw receipts, confirm current R40/R41 authoritative state and patron read, and stop a proposed change if mapping, telemetry, approval or rollback is missing. An owner may consider a revised, bounded control only after evidence and service tests are documented.” Equivalent two paragraphs pass if they give that narrower outcome and falsifiable next step.

EX072 — Model final handoff. “K18 v4, supervised classroom case; previous versions v1–v3 retained. Evidence pointers: K12 raw manifest and K12-derived-v1, K13 AL13-A/B predicate notes, K14-v1 review packet, K15 chronology, and new C18-B/C/D branch cards. K12 app intake contains three raw rows, one accepted A1 and two rejected rows (A2 bad time, later duplicate A1); I1/I2 and H1 are separately accepted. I1 and A1 share s-7 and C18-B validates their bounded session namespace. I2 reports denied s-8; it is not a confirmed block of A1. C18-C's separately versioned DB receipt reports r-601 rolled back and R40/R41 unchanged in the checked snapshot. D15's support-desk statement and C18-D's UI discrepancy are still not mapped to that reservation. No production control or recovery was executed, approved or verified by this classroom packet. The acceptance ledger shows R40/R41 unchanged only in the C18-C snapshot, not in any current live service; patron-visible correctness remains unresolved. Source clocks and D15 identity mapping are not verified. A2's rejected time also makes an absence claim from the accepted app view unreliable. Any proposed control needs a mapped route, expiry, authorized operator, prior version, authoritative R42 check, legitimate R40/R41 and patron tests, and a practiced rollback. Next, incident lead and privacy owner authorize a minimized patron/reservation match; application/index owner supplies projection lineage and source-health controls, while the DB owner reconciles the matched authoritative state. Stop any change if target, evidence, rollback or owner approval is absent. Reopen the outcome if a new validated receipt contradicts C18-C; preserve both versions. The shift owner must report the next bounded test and its deadline, not announce resolution.” A defensible self-score is 2 provenance, 2 inference, 2 safety, 1 service verification and 2 handoff = 9/10: patron-visible correctness remains unverified. A peer may score service verification 0 if the submission omits C18-D; then the dossier does not pass that gate and must be revised. A different 250–350-word handoff passes if source IDs, exceptions, branch limits, pending authority, owner, stop state and peer rationale are explicit.