Model a service transaction before a security signal | Professional 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.

Day 1 — Model a service transaction before a security signal

Learning decision. Given a reported change to a class slot, decide which state transition would be acceptable and which dependency could explain a deviation. An event feed cannot answer this until the expected business behavior is written down. NIST CSF 2.0 provides high-level risk-management outcomes, while NIST SP 800-61 Rev. 3 places response within that wider process. The transaction model below is OpenCyber Academy's teaching construction, not a NIST-prescribed schema or a verified CTN implementation.

For the separate W1 rehearsal, suppose a training class has one seat remaining. A client sends reservation request q-A; an unreliable network makes the client retry the same request; another client sends q-B. Specify the intended behavior before seeing logs: exactly one successful reservation may consume the remaining seat, a retry of q-A must not consume it twice if the service promises idempotency, and a rejected request must not decrement availability. Whether CTN has an idempotency key, a serial transaction or a version check is unknown. The model is a question for the application owner, not a reason to assert that CTN satisfies it.

The write path and the observation path have different failure points:

flowchart LR
  C["Client request q-A"] --> A["Enrollment API"] --> D["Authoritative slot state"]
  A -. "proposed audit event" .-> P["Source audit producer"] --> K["Collector"] --> X["Scoped export"]
  I["Identity service"] -. "session evidence, if emitted" .-> K
  O["Service owner"] -. "defines acceptable transition" .-> D

The solid path represents the proposed business transaction; dotted paths represent claims to test. Even a complete export from X would not, by itself, establish that D committed a valid result. A reservation receipt might be returned before a delayed write, and a notification could be queued before a rollback. Ask the service owner which record is authoritative, which request or version key joins client and write records, and how an authorized isolated test would distinguish a duplicate retry from a second successful booking. If no stable key exists, do not substitute a shared minute or account label for identity of an operation.

Worked example. Under the hypothetical contract, start at one available seat. If q-A succeeds, availability becomes zero and its retry returns the same reservation reference without another decrement. q-B then fails with an unchanged zero. A displayed success for both requests would violate the contract or indicate that the assumed contract is wrong; a single application log line cannot choose between those explanations. The first supervisor question is therefore “Is idempotency promised on this route, and which authoritative state/version verifies it?” rather than “Which attacker booked twice?” This is an example of deriving a testable question from an invariant, not an observation about C01.

Practice. Complete EX001 using C01, but add to its five-row map one proposed W1 invariant and label every graph edge data, evidence, authority or recovery. Give one possible falsifier for the API-audit edge and one for the backup-to-restore edge. The existing worked answer supplies the decision/owner pattern; your extra W1 contract may differ if it states its assumptions and does not assert deployment facts. Limit: a diagram documents what to verify; it cannot verify it. Previous: chapter start · Week index · Next: Day 2.

Exercise for this lesson

EX001 — Service dependency map. Input: C01 and the six CTN dependencies above. Produce a table with at least five dependencies, a decision each might support, custodian role and one unverified assumption. Assessment: 0 = missing decision/owner; 1 = map with vague assumptions; 2 = actionable, bounded map that does not claim the source is already verified.

EX001 — Model service map. A sufficient table includes (1) API audit → identify slot S42 write/request ID → application custodian → scheduled-route coverage unknown; (2) IdP → sign-in/session fields → identity custodian → detailed retention unknown; (3) support → symptom and receipt → support lead → reporter's observation not verified state; (4) change calendar → approved slot scope → service owner → addendum process unknown; (5) backup → candidate restore copy → recovery lead → last isolated restore unknown. This is a readiness map. It does not assert that S42 was changed or that these sources were collected at 08:40. Two points require a decision and a real gap in every row; “IT owns everything” earns at most one.

Additional worked reasoning (EX001 — Why each dependency supports a different decision.): A reviewable map should include five or more rows such as: API audit → “which request changed S41?” → application custodian → scheduled/manual coverage unverified; IdP → “which account/session fields can be produced?” → identity custodian → no after-hours alternate; support → “what was reported and received?” → support lead → no authoritative backend state; change ledger → “was S41 in a permitted task version?” → service owner → addendum process unknown; backup → “can selected slot values be reconstructed?” → recovery lead → restore correctness untested. Every row states how to falsify readiness: a missing scheduled route, unusable key, unavailable alternate or failed isolated restoration. C01 does not supply results for these tests. A table simply saying “SIEM: green” has no operational decision linkage.

Week 1 Day 1 extension — worked result. A possible W1 invariant is “with one seat left, the first accepted q-A consumes one seat, its retry consumes none, and rejected q-B consumes none.” Label client → API → slot store as data, API → source audit → collector as evidence, service owner → acceptance criterion as authority, and backup copy → isolated restore as recovery. The API-audit edge would fail if an authorized scheduled q-A test produced no stable request key; the restore edge would fail if a permitted isolated restore returned a slot count different from the approved target. These are proposed falsifiers, not executed findings. A response earns the second rubric point only when it distinguishes the intended transaction from a measured implementation and names owners for its proposed checks.