OpenCyber AcademyDay 32 — Preserve and plan two independent eradication contracts
Learning task. Build separate task and identity workstreams at 09:54, with permission, preservation, checks and pending fields. First account for the intervening authority event: C21 at 09:46:30 is fresh service-owner/incident-lead approval to extend the S42-only hold to 10:07, followed by the application operator's 09:46:45 g-23 receipt. It continues the limited scope, monitoring and rollback ownership and sets a 10:06 review. It is not task-removal authority or an automatic consequence of C20. The longer business interruption has its own impact decision; C16's initial tolerance does not supply it.
Next release C22 at 09:50: a separately retained configuration-audit source reports a recovery-method addition to svc-enroll at 08:52, with a blank actor. This is not recovered C08 sign-in detail and carries no inference that all identity evidence shares C08's 10:00 retention limit. An added method may provide a continuing access path, but its active/functioning state is untested. At 09:54 C23 records owner comparisons against the approved task inventory and official change ledger: neither change is approved through that checkpoint. This supports unapproved configuration change, not malware, theft, a named actor or a shared author of both changes.
Mechanism of the contract. Map each observed concern to a prospective intervention and a test that can contradict it. Baseline preservation must precede destructive modification where the authorized procedure permits it. Preserve the minimum task definition/schedule and bounded run evidence, inventory version, request semantics and source pointers; preserve the identity configuration history and method identifier without publishing secrets. A collection receipt should identify the acquired object, custodian, time, scope and integrity/provenance checks actually performed. A later change receipt must identify what was altered. “Saved and fixed” merges two different evidentiary obligations and hides ordering.
Lesson table; scroll horizontally to read all columns →
| Contract field at 09:54 | Scheduler task | Identity recovery method |
|---|---|---|
| Supported concern | C20 mechanism plus C23 task-inventory comparison. | C22 configuration addition plus C23 approval comparison; functionality untested. |
| Proposed action | Preserve configuration/run baseline; seek approval to disable only sync-override. |
Preserve bounded audit/settings; identity owner assesses active state and seeks scoped method/session/credential decisions. |
| Authority and operation | Task/application/service decision with incident coordination; authorized application operator, rollback plan. | Identity and service owners determine permitted targets, operator and dependency-aware reversal. |
| Intended effect check | Disabled status and no invocation at a known next scheduled opportunity. | Specific method absent/inactive after approved action; separately scoped session/credential effect where authorized. |
| Legitimate-service control | Approved batch-17 S40/S41 path remains functional. |
Approved integration still authenticates/operates after any change. |
| Reopen and gap | Re-registration, unexpected run/write; unseen runners and author remain unknown. | Unexpected method/access or broken integration; other methods/sessions and actor remain unresolved. |
Worked contrast. A correct 09:54 worksheet marks both eradication changes proposed. It can separately mark the S42 hold extension authorized/reported from C21. A single green “persistence removed” box would invent execution in both tracks. Disabling the whole account to make both rows appear quiet exceeds the narrow proposals, risks approved jobs and prevents distinguishing the task fix from an availability failure. A broader control might later be justified, but it needs a separate decision and evidence.
Offline practice. Complete both rows without importing a later result. For each, write the source package, approving capacity, expected operator receipt, effect check, legitimate-service check and an unavailable-result branch. A missing preservation digest remains missing; planned collection does not create a receipt. If immediate harm conflicts with lengthy collection, refer a bounded preservation/action sequence and stop condition to the owners rather than delaying indefinitely or granting yourself access. No recovery secret, live command or test traffic belongs in this exercise.
Limits and decision. Submit EX032, then inspect its worked answer. Task evidence does not prove the identity concern fixed, and method absence would not prove every session invalid. Preserve those two independent completion gates for the later task-only decision.
Previous: Day 31 · Week 7 index · Course index · Next: Day 33.
Exercise for this lesson
EX032 — Two-path eradication contract. Objective: plan distinct task and recovery-method changes with preservation before modification. Inputs: C20–C23 through 09:54 and Day 32. Produce separate rows for source/baseline, proposed target/action, approving capacity, operator/rollback, effect and legitimate-service checks, expected observation opportunity, monitoring and reopen trigger. Distinguish C21's already approved/reported hold extension from both pending eradication operations; do not claim method functionality, removal or secret collection. Rubric: 0 = invented remediation or shared actor; 1 = two paths with missing authority, preservation or verification fields; 2 = usable independent contracts with honest pending results and source-specific limits. Worked answer.