Evidence readiness and the first case question

Lesson 01 — Evidence readiness and the first case question

Week 1, day 1. Work through the teaching and the worked checkpoint before attempting the assigned exercise(s). Compare your artifact with the final worked result only afterward.

1.1 Response is part of risk management

An incident response team does more than react to an alarm. It prepares contacts and authority, recognizes potentially harmful activity, preserves facts, makes proportionate decisions, restores services and learns from the result. NIST SP 800-61 Rev. 3 places incident response recommendations throughout cybersecurity risk management as described by the NIST Cybersecurity Framework 2.0. The framework's Govern, Identify, Protect, Detect, Respond and Recover functions are concurrent and continuous activities. A team should not wait for “Respond” to think about owners, backups, communications or evidence.

There is an important distinction between a function used to prepare for response and an action taken during a particular case. The model in NIST SP 800-61 Rev. 3, section 2.1 places Govern, Identify and Protect in broad preparation and risk management; Detect, Respond and Recover describe the case-facing response activities. Its improvement category connects lessons back to all of them. This is a model for organizing outcomes, not a requirement that every case move through six isolated steps. In Harbor Library, naming an authorized service owner belongs to readiness; checking today's booking edit belongs to investigation; deciding whether to restrict an account belongs to response. An improvement ticket after the exercise may change the owner's contact list before the next case.

A beginner can test readiness with four questions: What service might be harmed? Which records could show what happened? Who may approve a disruptive action? What result would show that normal service is safe to resume? A team that cannot answer them has work to do even if its alerting system is excellent. Conversely, answering them does not establish that a particular alert is malicious. The distinction prevents a control inventory from being mistaken for an incident finding.

Consider a small library that provides room reservations online. An alert may say that an administrator account signed in at an unusual hour. That is a signal worth examining. It does not by itself prove account compromise. A change to the reservation database may be an event with business effect. The team must assess context, evidence and impact before it labels the situation a confirmed incident. These are working definitions for this teaching case; an organization should use its own approved classification policy.

The first useful question is: Which service and people could be harmed, and what is known right now? A team that records uncertainty can act quickly without pretending to know a root cause. A team that labels every alert “breach” risks needless disruption; a team that dismisses every alert risks delayed containment.

1.2 A fictional service map

The course uses Harbor Library, a fictional organization. No personal records or real network are involved. Residents reserve study rooms through a website. Front-desk staff can edit bookings. A separate event-newsletter list contains contact addresses. The booking service depends on a web application, an identity service, a database, a nightly backup and a staff help desk.

This map is incomplete on purpose. It does not say whether the application uses third-party hosting, how clocks are synchronized, or who can approve a service outage. A response team should record those as readiness gaps before a crisis. If one dependency fails, the team can then ask the correct owner for evidence and options.

From dependency map to evidence-readiness contract

A service map names components and owners; it does not show that an investigator could answer a specific question on time. A useful next step is an evidence-readiness contract: a short, testable agreement about which source would record an event, what its fields mean, who may retrieve it, how long a useful record can remain available and how a second analyst could reproduce the selection. This is a OpenCyber Academy teaching device, not a required form from NIST SP 800-61 Rev. 3. NIST's incident-response guidance places preparation, service knowledge and response roles within broader risk management; the contract below turns that general orientation into a small fictional library exercise.

Begin with a decision question, rather than a product name. The practice records introduced in section 1.7 will include a cancelled booking B18 and the desk-a account; treat them as a preview here. “Do we have logs?” is too broad. “Was the B18 cancellation an approved staff action, and did the current booking state reflect it?” separates an activity question from a business-state question. A booking audit could record an edit, but an authoritative state comparison would be needed to confirm what users can book now. Similarly, an identity service could report that the account desk-a signed in, while neither the account label nor a timestamp identifies the human at the keyboard. The evidence plan should say what a source can discriminate and which tempting conclusion it cannot carry.

For each question, write six fields before the incident: (1) the producer and event it is supposed to emit; (2) identifiers that might connect records without silently merging different people or actions; (3) event time, collection time and clock or timezone assumptions; (4) the custodian, approved collection path and access limit; (5) expected retention and failure indicators; and (6) a small authorized rehearsal that could show whether the source actually works. Blank or untested fields remain unknown. A diagram that shows a log arrow without these details is an architectural hypothesis, not proof of coverage.

The following is a proposed D1 design card, written for an isolated training version of Harbor Library. It is a plan for what owners would test, not a new R-series record, a description of the library's actual logging configuration or evidence available at the 09:05 checkpoint. Field names such as request_id and session_id are candidate design fields; their existence and semantics must be checked before a real correlation.

The four-row card is a summary, not a completed six-field contract. For the first row, a fully specified proposed test record would read as follows. Its field names, times and expected observations are invented for a future isolated rehearsal; none is claimed to exist in R1–R8.

The four-row decision card is deliberately two-sided. It names a source, then names what would still be unknown after seeing it. That prevents the familiar slide from “log exists” to “question answered.” Its first row also distinguishes an activity record from a state-of-the-world record. If an application audit says B18 was cancelled but the restricted current-state copy is missing, the analyst can report the recorded cancellation and request the state comparison. The analyst cannot certify the live schedule from the audit alone. Its second row anticipates Module 2's correlation exercise: even a supplied exact session-key match narrows a record relationship, not the identity or authorization of a person.

Trace where an observation could be lost. A missing search result has several different causes. The producer might never emit the event; an emitted event might fail collection; a collected record might arrive after the query; an available record might already have aged out; access controls might deny the selected view; the query might use the wrong booking ID, timezone or time window; or a reviewer might misread a real row. The response to these failures differs. Repeating the same query cannot repair non-emission, and asking for a broad export is not a substitute for fixing a wrong filter. A readiness review therefore records the last confirmed point in the path from producer to learner and a named owner for the next check. Do not collapse every empty result into “the system had no activity.”

Make a rehearsal falsifiable. In an isolated, explicitly approved training copy, an owner could predeclare one synthetic booking change and one deliberately out-of-range control event. The application custodian would record the test request ID and UTC event time; the collector would record receipt time and source; the analyst would run a bounded query and save the exact filter and run time. The expected result is the in-range change and its agreed fields, with the out-of-range control excluded by the declared interval. If the expected row is missing, the team investigates emission, transport, retention, access and query scope in order. If the out-of-range row appears, the filter or time interpretation needs correction. Passing this small rehearsal shows only that the tested path and interval behaved as stated. It does not prove all future events will be collected, or that the event proves why a person acted.

Rehearsal evidence should include the negative and failure cases, not only a successful dashboard screenshot. A copy of a search result without its source, filters and collection boundary may be impossible to reproduce. A source timestamp and an analyst's discovery time should occupy separate fields; otherwise a delayed record can seem to have happened later than it did. The plan should also say how a source error is noticed: for example, a missing expected test event, a delayed collection receipt, a schema change or an expired retention window. Module 2 will exercise those distinctions with synthetic records. They belong in readiness because a responder cannot reconstruct a record that was never retained.

Scope and privacy follow the question. The booking question does not authorize opening the separate newsletter list. The D1 card names minimal booking and session fields to request, the custodians who could provide them and the approval to seek. If a later, supported observation raises a data-exposure concern, the incident lead and privacy contact can define a new purpose and boundary. Collecting an entire identity history or patron database merely because it is technically accessible would enlarge the case and the number of people exposed to those records. A good evidence plan makes the smallest useful selection reproducible and records what it excluded. The exact retention, access and privacy rules of a real organization must come from its own policy and applicable obligations; this fictional card does not supply them.

After reading the dataset in section 1.7, apply the contract to the actual Module 1 snapshot without importing D1 as evidence. R1 reports a desk-a sign-in, but no device, session-key semantics or person. R3 and R4 record booking edits, but the supplied table does not contain an owner-approved target or a fresh authoritative state comparison. R5 records a patron's report, not a count of all affected users. R6 schedules training, but does not list the approved booking tasks. R7 reports a completed backup job, not an isolated restore. R8 explicitly lacks destination detail, so it cannot establish absence of data transfer. At 09:05 the analyst can open a bounded case, preserve the supplied pointers and ask the named owners for the missing discriminators. The analyst cannot claim that the proposed D1 logging fields or rehearsals were already implemented.

An evidence-readiness contract is useful only if someone owns its maintenance. A service change may rename a booking field, split a write path, move a log producer or shorten retention. The owner would then re-run the authorized test and update the contract's source, meaning and collection route. The document should show its last tested scope and next review trigger; an old “green” status without those details is weaker than a current, explicit unknown. This connects Module 1's service map to Module 2's evidence handling, Module 3's control and recovery checks and Module 4's after-action improvements. It remains a preparation artifact, not a substitute for case evidence or a completed investigation.

Test whether readiness is usable

A response team may possess a policy, a contact list, monitoring software and nightly backups while still being unable to make a safe decision under pressure. The existence of a component says little about whether the team can use it correctly when a particular service is threatened.

A practical readiness claim should have five parts: capability, owner, permission, test, and failure response. For example, "we have booking logs" is an inventory statement. A verifiable readiness statement is: "the application custodian can, with the incident lead's approval, retrieve booking changes for a specified identifier and time interval; another reviewer can check the source, filters and output; if the expected test row is absent, the custodian investigates collection and retention rather than claiming no activity occurred."

This distinction matters because apparent technical success can hide failed business outcomes. A green web-health indicator may represent a responsive landing page while a reservation write fails. A successful backup-job status does not demonstrate that a restored database contains the correct schedule. A sign-in record establishes that the producing system reported an account event; it does not establish a human identity.

NIST Cybersecurity Framework 2.0 describes cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond and Recover. NIST SP 800-61 Revision 3 integrates incident-response recommendations with organizational risk management. Neither source authenticates Harbor Library's fictional observations or specifies this exercise's cards. The teaching implication is to examine whether the organization's desired outcomes can actually be demonstrated.

Consider the following contrasting rehearsal results:

Readiness tests should expose their own limitations. Passing one retrieval rehearsal validates the tested path and interval, not every collector, account or future day. A signed approval for one mock change does not establish authority to make any other change.

Week 1 review unit 1 — Check the input contract before interpreting the result

Objective and distinction

These five supplementary review units extend existing Lessons 01–05; they do not create new daily lessons or replace EX001–EX050. All cases and programs use fictional or in-memory fixtures. For each executable extension, run the complete named laboratory first in a fresh Python session. For AR1, also run its request-bound approval listing before the type gate. Do not connect to production systems or treat fixture results as authorization.

After this unit, explain why a program's correct calculation can still be irrelevant to the intended incident question. Identify three separate things: the selected source version, the declared input frame, and the exact proposition being tested.

Lesson 01 already teaches an evidence-readiness contract: name a useful question, a source, a custodian, collection conditions and a rehearsal. The additional step here is to test the boundary between that contract and the input actually handed to a checker. A table can be internally well formed yet belong to a different version or omit an object required by the decision.

A source pointer identifies where the reader should look. It does not by itself establish the truth, completeness or applicability of what is found. A declared input frame states which objects the current comparison is supposed to cover. It is not evidence that the frame includes every relevant production object. A test proposition states the narrow condition the program can evaluate once those inputs are accepted.

For example, the original BSL1 program can inspect supplied booking intervals. It cannot independently determine whether an exporter omitted a booking, whether its policy was approved for the relevant service, or whether the rows describe the current incident. Those questions do not become true because the overlap function executes correctly.

A three-stage review

Accept the declared input contract?
    no -> reject or request clarification; no business pass
    yes
     |
     v
Evaluate the stated model on those inputs
     |
     v
Report the result within that scope
    + name what the source and model cannot establish

Text explanation: the first stage checks whether the input can be used under this particular contract. The second applies the declared rule. The third prevents a narrow calculation from becoming an unsupported incident finding. None of the arrows authenticates a producer, establishes authorization or supplies a missing record.

Begin by freezing the expected frame before looking at the outcome. Suppose a reviewer is given a declared six-object BSL1 frame, S01–S06. A second file contains only S01 and reports no conflict. That result might be correct for S01 alone. It cannot answer the six-object question unless the missing five objects are accounted for. Silently redefining the expected frame to match the returned file would change the question after seeing the answer.

Next inspect field meaning, not only field presence. A field called confirmed might contain a Boolean, text, an integer or no value. A value that a programming language treats as true is not necessarily an affirmative statement under the exercise's schema. Unit 4 makes that difference executable.

Finally inspect the sentence the analyst writes. Even an authentic R4 pointer supports the fact that a cancellation was recorded; it does not supply approval, the human actor or a fresh owner-approved booking-state comparison. Type checking is not semantic proof. Conversely, a malformed input is not evidence that a malicious change happened. It is a reason to stop that comparison and seek a usable source.

Worked example

A proposed review note says: “The checker returned no findings, so all six bookings are safe.” The attached input contains only S01. The first error is a frame mismatch, before any question about whether the overlap calculation is correct. The second error is promoting a fixture result into service safety. A defensible replacement is: “No overlap was found in the declared one-row comparison; this input does not answer the six-row rehearsal question or establish a real service state.”

To answer the original question, the reviewer should retain the one-row input and its result, request the missing frame or an explicit owner-approved scope revision, and rerun the relevant comparison. Do not invent the absent rows, infer that they were deleted, or overwrite the first result.

Supplementary practice W1-R1

Objective: separate input admissibility from the meaning of a computed result. Inputs: the three reports below, the original R4 limitation, and the BSL1 six-object frame described above. Required artifact: three rows containing admissibility decision, narrow supported statement, missing evidence and next bounded request. Constraints: no new R-series facts; no production collection; retain both the submitted input and its declared scope.

Assessment: one point for each correctly reasoned row, one for distinguishing a missing frame from a negative finding, and one for preserving the canonical case boundary. Five points assess this supplementary task only. A claim of real approval, human attribution or safe production state requires correction regardless of the total. Worked answer.

Review synthesis

A usable input, a correct calculation and a justified operational conclusion are different achievements. Preserve the boundary between them.

Worked checkpoint

R1 records a successful account sign-in; R3 and R4 record booking changes. The records establish sequence, while the identity of the person and approval of the changes remain unknown. The first decision is a bounded question to the owner, not a compromise verdict.

Practice — Lesson 01

EX001 — Observation or inference

Objective: separate the content of a record from an explanation of that content. Inputs: R1, R3, R4, R5 and R7, all within the R1–R8 Round A release at 09:05. These are the exact source pointers for the four statements; do not use R9 or any later case result. Output: a four-row table with statement, classification, supporting record and one sentence describing the record's limit. Classify: (a) “R4 records a cancellation of B18”; (b) “desk-a was compromised”; (c) “R5 reports that B18 disappeared”; (d) “R7 proves the service can be restored in ten minutes.” Use the categories direct observation, hypothesis requiring confirmation and unsupported conclusion. A score of 2 requires distinguishing the fact of a patron report from independent proof of the patron's full experience.

Extension: For each original statement, rewrite any unsupported conclusion into the narrowest defensible wording. Add one source that would be needed to upgrade the claim.

For full credit: A 2-point answer must distinguish "R5 records a patron report" from "the booking interface was independently proved incorrect," and "R7 reports backup completion" from "recovery was tested." Merely selecting a label without a limiting sentence earns at most 1.

Worked answer: EX001 in the final appendix.

Continue studying — lesson 01 of at least 20

← Course overview · Course lesson index · Lesson 02 →

Continue to the next authored daily lesson.