OpenCyber Academy
Professional · Lesson 28 · English
Course code: OCA-039Lesson 28: OCA-039-A028

Maintain separate authorization, execution and verification records

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

Permanent link

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 28 — Maintain separate authorization, execution and verification records

Learning task. Reconstruct four checkpoints without promoting a receipt into a stronger state. An approval answers who permitted which action and until when. An execution receipt answers what an operator reports changing. Verification asks what independent or otherwise authorized observations support the intended property, with their time, scope and blind spots. Even when one person holds multiple local roles, preserve the records and their meanings separately. The teaching method is an evidence chain, not a requirement to invent people or signatures.

At 09:35 the S42 hold is proposed under C13–C16. At 09:37 C17 supplies the case approval: S42-only, automatic expiry 09:47, named operator and rollback owner, monitoring/preservation and alternate-route escalation. Account disablement and S40/S41 modification are outside that scope. At 09:39 C18 reports g-22 enabled. At 09:42 C19 observes q-147 denied on one S42 application route and q-148 accepted for S40. The case contains no learner-generated write and no S41 outcome at that checkpoint. A plan requiring S40/S41 continuity may remain only partially evidenced even though one legitimate control passed.

Worked record. Use distinct fields: requested action and rationale; approval reference/window; operator report/configuration; observation source/request/route/time; untested routes/service operations; next gate. At 09:42 write “C17 authorized S42 hold until 09:47; C18 reports g-22 enabled at 09:39; C19 selectively observes one denied S42 and one accepted S40 request; alternate paths and S41 outcome unverified.” This lets a reviewer ask a precise missing-evidence question. “Containment green” cannot reveal whether an approval, a deployment or a coverage check is missing.

Clock and contrast. The interval from 09:37 approval to 09:47 expiry is ten minutes; from 09:39 reported enablement to expiry is eight minutes. Neither calculation proves continuous enforcement for that duration. “Give the operator ten minutes from deployment” silently changes the expiry to 09:49 without a new approval. “Approval at 09:37 proves no writes after 09:37” confuses authority with effect. Preserve the fixed 09:47 boundary and record missing actual activation/expiration evidence rather than resetting it. The later C21 development is outside this checkpoint.

Offline laboratory W6-TIME — a fixed boundary, not an approval engine. Python 3 standard library only, in-memory, no file or network operations. Inputs are explicitly supplied teaching timestamps on the same date and UTC clock, not authenticated receipts. The half-open interval includes activation and excludes expiry. A local rule rejects an observation before reported activation or at/after the stated expiry; it cannot decide whether a real control was active. Predict all five lines before running:

from datetime import datetime

def minute6(value):
    return datetime.strptime(value, "%H:%M")

approved6 = minute6("09:37")
reported6 = minute6("09:39")
expires6 = minute6("09:47")
print("W6 approval-to-expiry-minutes=", int((expires6-approved6).total_seconds()/60))
print("W6 reported-to-expiry-minutes=", int((expires6-reported6).total_seconds()/60))
for value in ("09:38", "09:42", "09:47"):
    state = "IN_REPORTED_WINDOW" if reported6 <= minute6(value) < expires6 else "OUTSIDE_REPORTED_WINDOW"
    print("W6 " + value + ": " + state)

Expected transcript, reproduced during publication validation:

W6 approval-to-expiry-minutes= 10
W6 reported-to-expiry-minutes= 8
W6 09:38: OUTSIDE_REPORTED_WINDOW
W6 09:42: IN_REPORTED_WINDOW
W6 09:47: OUTSIDE_REPORTED_WINDOW

The pre-activation and exact-expiry rows are adverse controls against treating a plausible clock as permission. “IN_REPORTED_WINDOW” means only interval membership under supplied values. It does not authenticate C17, confirm deployment or authorize a test. It also assumes same-day minute-resolution UTC; dates, clock error and time zones need explicit handling in a real record.

Practice and limits. Reproduce C6 and W6-TIME, then annotate each line as planning, permission, report or observation. Submit EX028 and compare its worked answer. Preserve blank actual rollback fields and unknown route coverage. A request for stronger verification must go to the owner; it is not permission for the learner to send test traffic.

Previous: Day 27 · Week 6 index · Course index · Next: Day 29.

Exercise for this lesson

EX028 — Approval-to-effect record. Objective: keep permission, reported execution and observations separate. Inputs: C13–C19 through 09:42, C6 and Day 28 W6-TIME. Make four timestamped status lines with source/scope, the fixed 09:47 expiry and unverified routes/service checks. Reproduce both transcripts and explain ten versus eight minutes, including the pre-activation and exact-expiry controls. No new operation, renewal or all-route result may be asserted. Rubric: 0 = backdated authority, changed expiry or invented effectiveness; 1 = correct states but missing interval/observation limits; 2 = all four transitions and exact outputs with fixed expiry and a bounded one-route verdict. 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.

EX028

Opens in 30 days: — · browsers: —

Checking for a reviewed five-choice question…

Worked answers

EX028 — Model action-state timeline. 09:35: analyst proposes a S42-only temporary hold based on C13–C16; no change yet. 09:37: C17 records incident-lead/service-owner approval for S42 only, expiry 09:47, operator and rollback owner named. 09:39: C18 reports g-22 enabled by the application operator; execution receipt is distinct from approval. 09:42: C19 shows q-147 denied on one S42 application route and q-148 accepted for S40. The observed route supports partial effect; direct database or alternate API coverage is not verified. The account remains enabled. The next gate is the 09:47 expiry or an earlier observed bypass/legitimate harm.

Additional professional worked reasoning: Use this precise provenance sequence: 09:35 C16 impact tolerance and analyst proposal; 09:37 C17 scoped approval expiring 09:47; 09:39 C18 operator reports g-22 enabled; 09:42 C19 observes one S42 denial q-147 and one S40 acceptance q-148. Neither 09:37 approval nor 09:39 report proves all-route enforcement. The apparent effective interval from 09:39 to 09:47 is eight minutes under a hypothetical continuous-activation assumption, not an automatically verified ten-minute block. C21 renewal belongs to the next chapter.

Week 6 Day 28 — worked fixed-window controls. C6 reproduces five lines: proposal, authorized, reported-enabled and observed-one-route each with all-routes unknown, then separate V6 FAIL. W6-TIME reproduces five lines: approval-to-expiry 10; reported-to-expiry 8; 09:38 OUTSIDE_REPORTED_WINDOW; 09:42 IN_REPORTED_WINDOW; 09:47 OUTSIDE_REPORTED_WINDOW. The interval is half-open under same-day UTC teaching assumptions. A 09:38 observation cannot validate this reported activation window, and 09:47 is already its excluded boundary. Even 09:42 membership is not proof of deployment or continuous enforcement. C19 supports one S42 denial and one S40 acceptance, not S41 or alternate routes. Do not shift the expiry to 09:49 or import C21.