Convert an impact observation into a measurable containment objective

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

Public activity · 30d

—Participating browsers

—Page views

—Reading sessions

—Exercise opens

Counts reflect browsers that allowed analytics. A reading session requires 30 seconds on a visible page. Browsers are not people.

Day 26 — Convert an impact observation into a measurable containment objective

Learning task. Produce an impact ledger that supports a limited decision without turning state evidence into attribution. A containment objective must describe a change to prevent, the protected service to retain, a window and an observation that could contradict success. The verb “contain” alone supplies none of these. An intervention can prevent a further mutation while leaving an already wrong value unchanged. Conversely, restoring a display can hide a symptom while the harmful write path remains available. Prevention, correction and diagnosis require different evidence.

At 09:35, C13 is the strongest supplied source for S42's stored state: an owner-approved custodian read finds version 19 unavailable, with last recorded request q-144; the separately preserved 08:30 snapshot has version 18 open. This supports a state difference between observations, not the exact instant of every intervening transition. C05's reported 09:01 edit and C02's approximate 09:00 symptom remain separately sourced. Do not move either clock to make a smooth account. C10 depicts a page with incomplete capture/cache context; it can remain relevant to user experience while being weaker than C13 for backend state. Those sources answer different questions rather than competing for one universal reliability score.

Separate impact, authorization and origin. C15's official-ledger check through 09:33 finds no S42 addendum; it bounds the visible approval evidence, not all possible emergency conversations. C14 supplies a complete manifest for one approved batch-17 run in the API request namespace: q-140/S40 and q-141/S41. Its exclusion of q-144 defeats the claim that this specified run manifest contains that request. It does not inventory every job or identify a human. C16 contributes an initial ten-minute S42 delay tolerance. Neither a harmful state nor tolerable delay signs an action approval.

Worked example. A useful objective at 09:35 is: “Request a temporary S42 write hold to prevent further accepted in-scope S42 mutations during an explicitly approved window, while preserving permitted S40/S41 operations. Obtain the route inventory and approval before execution; check route-labelled request outcomes and authoritative state/audit evidence, record unknown coverage, and review service cost and expiry.” This is a proposed property, not a report of deployment. The planned acceptance record should list accepted S42 writes on tested routes (target zero), successful permitted S40/S41 checks (required), observation times, source pointers and missing tests. No actual denominator of CTN routes is supplied. A count of zero accepted writes in a silent log is not equivalent to a successful denial test: there may have been no attempts or no logging.

Contrast. “Return S42 to open, block the attacker and announce containment complete” mixes a data-repair objective with an unproven actor and an unmeasured global result. C13 does not authorize restoration or establish the correct current business value for every enrollment. The defensible note names the next change to prevent and leaves restoration and actor identification pending. A hold might freeze the wrong value; that cost belongs in the owner's decision.

Offline practice. Make four rows on paper: stored state, displayed symptom, approval evidence and actor/origin. For each, write the strongest supplied claim, source/release, one boundary and the question that could change the proposed control. Add a fifth planning annotation for C16 without turning it into an approval row. In a second column test this adverse claim: “Because q-144 is absent from batch-17, the shared account user is malicious.” Identify the unsupported transition from a bounded exclusion to intent. No lookup or tenant access is needed.

Limits and decision. Neither affected learner count nor all-route exposure is measured. Unknown impact is not zero impact; unknown origin is not safety. Submit EX026, then compare the four-row model and Day 26 worked extension. Carry a conditional S42 proposal into the next lesson, with route and owner questions attached.

Previous: Week 5, Day 25 · Week 6 index · Course index · Next: Day 27.

Exercise for this lesson

EX026 — Updated impact statement. Objective: derive a measurable containment proposal without attribution. Inputs: C05/C10/C13–C16 and Day 26 at 09:35. Produce four rows for stored state, displayed symptom, approval evidence and actor/origin, each with source, release, bounded claim and unresolved question. Outside the ledger add the proposed prevention/service property, observation window/denominator questions and C16 tolerance annotation. No control approval or learner execution may be asserted. Rubric: 0 = invented actor/authority or repaired chronology; 1 = sourced ledger but incomplete measurable property or uncertainty; 2 = all four boundaries, a falsifiable proposal and tolerance kept distinct from permission. Worked answer.

Practice the exercises

Open a prompt, write your response, then compare it with the worked answer. Five-choice practice appears where a reviewed question is available.

EX026

Open the prompt →Compare with the worked answer →

Opens in 30 days: — · browsers: —

Checking for a reviewed five-choice question…

Worked answers

EX026 — Model impact ledger. Stored state: C13's owner-approved read shows S42 version 19 unavailable, last request q-144, while its 08:30 comparison shows version 18 open; unknown is the extent of affected enrollments. Display symptom: C10 depicts an unavailable page at a conditional 09:21 UTC; capture clock and cache remain unverified. Approval: C15's official ledger through 09:33 has no S42 addendum, narrowing C11's possible claim; an unrecorded emergency process is still a question. Actor: C05 gives an account label and C14 excludes q-144 from the approved batch-17 run, but neither identifies a human. A ledger that states “attacker used svc-enroll” loses the evidence-boundary point.

Additional professional worked reasoning: Preserve four separately sourced cells: C13's owner-approved S42 version-19 read, C14's one-run exclusion of q-144, C15's official-ledger check through 09:33, and C16's ten-minute tolerance only. A recommended S42 hold is conditional and requires incident lead/service owner approval; the shared account is not yet connected to q-144 by a trusted session key. A defensible impact ledger explicitly marks affected learner count and human operator unknown, not zero or malicious.

Week 6 Day 26 — worked objective ledger. Four cells remain separate: C13's owner-approved state read released 09:29 (version 19 unavailable versus preserved 08:30 version 18 open); C10's display/capture limits; C15's official-ledger absence through 09:33 with unrecorded authority still an open question; C05/C14's bounded account/run evidence without a human attribution. C14 excludes q-144 from one complete manifest in a comparable namespace, not every job. C16 at 09:35 supplies initial delay tolerance only. Propose zero accepted in-scope S42 mutations during the eventual approved window, required permitted S40/S41 behavior, route-labelled observations and authoritative state/audit pointers. The route denominator, actual window/effect and learner impact count are not yet supplied. No attempts in a log does not prove a tested denial. A hold would not itself repair the stored state; restoration requires a different decision.