OpenCyber Academy
Technical · Chapter 10 · English
Course code: OCA-062Chapter 10: OCA-062-C010

Chapter 10 — Containment control configuration in a lab

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

Lesson map

Lesson 10 published. Map, example, EX037.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["10.1 Specify a control contract before a command"]
  N2["10.2 Offline before/after/rollback simulation"]
  N3["10.3 Security effectiveness and business acceptance"]
  N4["Subject synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX037"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["10.1 Specify a control contract before a command"]
  N2["10.2 Offline before/after/rollback simulation"]
  N3["10.3 Security effectiveness and business acceptance"]
  N4["Subject synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX037"]

[Learning outcomes and connection]
    |
    v
[10.1 Specify a control contract before a command]
    |
    v
[10.2 Offline before/after/rollback simulation]
    |
    v
[10.3 Security effectiveness and business acceptance]
    |
    v
[Subject synthesis]
    |
    v
[Worked example] --> [Exercise EX037]

Learning outcomes and connection

The learner will define a temporary rule's exact subject, action and expiration, simulate its security effect, test a legitimate workflow and rollback, and document evidence needed before any real change. Chapter 9 established an incomplete record: K-G1 traffic and K-A1 queue acceptance do not prove a commit, actor or compromise. Chapter 10 therefore uses a separate K10 sandbox proposal, not a response order for the K9 packet. Chapter 11 will verify clocks and record integrity before stronger temporal claims. NIST SP 800-61 Rev. 3 frames response choices within risk management; the rule, test accounts and expected results here are original teaching artifacts.

10.1 Specify a control contract before a command

The fictional sandbox holds four requests. S10-1 uses session sess-K9 for a write to R42 and is labeled suspect for the exercise, not proven malicious. S10-2 is the authorized worker's sess-W1 write to R40. S10-3 is a patron read of room availability under sess-P1. S10-4 is a read by sess-K9. All four use an invented shared service architecture; their principal labels are not human identities. The response question is whether a rule can stop S10-1 without stopping S10-2 or S10-3. A session-specific write deny is a narrower candidate than revoking the entire svc-book principal. It also has a limitation: it does not stop sess-K9 reading or using a different session.

A control contract states: trigger evidence (source-linked harmful write, scope and continuing risk); decision authority (incident lead, identity/application owner and service owner as applicable); target (one session ID plus write route, after namespace validation); lifetime (short expiry and review time); operator; expected security effect; expected service effect; baseline; positive and negative tests; rollback; and reopen condition. A rule identifier and change-log version make an action inspectable. If the service uses independent worker paths, the negative test must include them. A green read-only page does not prove that writes still work. If session IDs can be refreshed or aliased, an identity custodian must validate the scope before the rule is proposed.

In the AUTH-K10 classroom card, the trainee may run the pure Python simulation below and draft a change ticket. Approval to change a real identity service, gateway, API or host is pending. A proposed denial can preserve evidence less well than a read-only observation if it terminates a session or rotates logs, so the incident lead should consider capture needs and time pressure. Conversely, delaying a verified harmful action has a cost. The contract makes that tradeoff visible rather than hiding it inside a command.

10.2 Offline before/after/rollback simulation

The listing models only route admission. It has no network access, no credentials and no database. The baseline allows all four requests; the scoped rule rejects just one session on the write route; rollback restores the baseline. The word “allowed” below means this function's Boolean, not that an HTTP request completed, a reservation was committed or a real policy engine behaved the same way.

requests = [
    ("S10-1", "sess-K9", "write"),
    ("S10-2", "sess-W1", "write"),
    ("S10-3", "sess-P1", "read"),
    ("S10-4", "sess-K9", "read"),
]

def admitted(session, route, mode):
    return not (mode == "scoped" and session == "sess-K9" and route == "write")

for mode in ("baseline", "scoped", "rolled_back"):
    active = "baseline" if mode == "rolled_back" else mode
    results = [f"{label}={admitted(session, route, active)}"
               for label, session, route in requests]
    print(mode + ": " + " ".join(results))

The expected transcript has S10-1 false only under scoped; S10-2, S10-3 and S10-4 remain true. The rollback line matches baseline exactly. That is a unit test of a toy predicate. It does not establish that the gateway enforces the same route, that all client routes are enumerated, or that a token cannot change. A stronger isolated integration test would present known positive and negative transactions at every relevant route, capture the actual policy version and decision logs, and compare authoritative application/database outcomes. Production testing requires separate authority and safety constraints.

10.3 Security effectiveness and business acceptance

A useful test matrix has four columns: target route, expected policy decision, observed application result and owner-approved business result. For S10-1, the desired policy decision is deny; the system should show an unambiguous denial on the intended route and no subsequent R42 write in a bounded authoritative data check. For S10-2, the worker write should still complete and reconcile correctly. For S10-3, the patron should still read valid availability. For S10-4, the read remains allowed under this particular rule; that limitation must be documented, not concealed. If the harmful activity can move to another session, the plan needs broader detection and another decision, not an unsupported declaration of containment.

Compare an alternative: revoking the shared svc-book principal. In the simplified dependency graph from Chapter 1, that may stop both the suspect task and the approved worker. The wider control might still be warranted under stronger evidence and risk, but the service owner must understand the cost. A temporary gateway rule might affect only one path while the worker uses a different route; conversely a route-level rule could miss direct API access. Scope is a property of the actual enforcement points and observed tests, not of a label such as “targeted.”

The ticket should retain a pre-change baseline, who approved the exact version, when it was activated, its expiration, the operator and policy artifact digest, the test receipts and a rollback owner. A rollback is not complete because someone removed a rule: rerun the legitimate R40 write and patron read, check for queued retry effects, and retain the before/after state. If the rule never takes effect, the incident lead should reopen the hypothesis rather than claim success. If it blocks a legitimate workflow, the owner may need to roll back or replace it under the agreed emergency criteria. Chapter 6's route model helps predict which negative tests matter; Chapter 9's provenance rules say which observations can support the decision.

Common errors and limits

Exercises — subject 10

EX037 — Control contract. Objective: make an action reviewable. Draft the eleven contract fields in §10.1 for the K10 rule. Explicitly leave real approval pending and distinguish S10-1 from K9 observations. Evidence: versioned change ticket. Rubric: 2 = scope, authority, expiry, baseline, tests and rollback with a concrete trigger; 1 = target and test but no owner/expiry; 0 = authorizes a real change from AUTH-K10.

EX038 — Simulation and counterfactual. Objective: test the predicate. Run §10.2 and record all three exact output lines. In a copy, change S10-4 from read to write and predict its scoped result without changing the original transcript. Explain what a policy-engine integration test would still need. Evidence: two transcripts and limit statement. Rubric: 2 = exact booleans and variant separation; 1 = correct original only; 0 = describes the toy result as deployment evidence.

EX039 — Positive/negative acceptance matrix. Objective: compare security effect with service risk. Build four rows for S10-1–S10-4 naming expected decision, authoritative outcome to check, custodian and failure interpretation. Add the approved worker's retry/queue state after rollback. Evidence: matrix. Rubric: 2 = R42 stop and R40/patron continuity plus route limitation; 1 = denial only; 0 = equates HTTP status with database correctness.

EX040 — Broad-control review. Objective: critique an alternative. A peer proposes revoking svc-book for all routes and declares the incident over because the portal still loads. Use Chapter 1's graph and K10's tests to explain at least three untested effects, one condition under which broader control might be justified, and a safer next decision. Evidence: decision note. Rubric: 2 = graph, route coverage and owner-led tradeoff; 1 = generic “too broad”; 0 = accepts static portal load as full recovery.

Subject synthesis

An isolated predicate can make a control's intended scope explicit, but only a source-linked trigger, authorized deployment and service-aware tests can support a real response decision. K10 leaves all real approvals and executions pending. Chapter 11 will examine whether cross-source times and retained bytes could reliably order the claims that would feed such a decision.

Worked answers

EX037 — Model control contract. Ticket K10-v1: trigger = a future source-validated continuing harmful R42 write, not the K9 byte count; decision authority = incident lead plus identity/application and service owners, pending; target = confirmed sess-K9 namespace, write route only; operator = named approved responder, pending; lifetime = short, reviewed at a specified time before automatic expiry; baseline = S10-1–4 route results and authoritative R40/R42 state; expected effect = deny S10-1 while not asserting that every route is covered; service effect = S10-2 worker write and S10-3 patron read continue; tests = policy decision, authoritative R42 no-new-write check, R40 commit/reconciliation, patron read and S10-4 known limitation; rollback = restore prior version under a named owner and rerun business checks; reopen = alternate session, route bypass or worker failure. The exact expiry and operator must be filled by the owner before a real change. The offline card approves only simulation and a draft ticket.

EX038 — Model predicate transcript.

baseline: S10-1=True S10-2=True S10-3=True S10-4=True
scoped: S10-1=False S10-2=True S10-3=True S10-4=True
rolled_back: S10-1=True S10-2=True S10-3=True S10-4=True

Changing S10-4 from read to write in a copy yields S10-4=False on the scoped line, because it now matches both the session and route conditions. Baseline and rolled-back remain True. That is a new input, not an amendment to the original K10 record. Integration testing must check the real enforcement point, route enumeration, policy/version propagation, token refresh behavior, decision logs and authoritative business outcomes in an authorized isolated environment. The Python predicate proves none of those.

EX039 — Model acceptance matrix. S10-1: expected deny on sess-K9/write; identity/application owner verifies decision log and DB owner checks no new R42 write in a bounded interval; a Boolean or HTTP denial alone is incomplete. S10-2: expected allow on sess-W1/write; job owner and DB owner verify R40 reaches the authoritative state, including retries. S10-3: expected allow on sess-P1/read; service owner checks patron-visible availability with correct data. S10-4: expected allow on sess-K9/read under this rule; identity owner records that continued read as a residual capability rather than calling full containment. After rollback, compare queued task state and R40 reconciliation with the pre-change baseline, not just the rule list. Approval, execution and all production observations remain pending.

EX040 — Model broad-control review. Revoking svc-book could remove the approved worker's ability to process R40, block an API authorization dependency, and prevent backup or reconciliation workflows that rely on the same principal. A static portal load tests neither reservation writes nor queue state. It also says nothing about another session, direct API path or whether the suspect R42 write stopped. A broader revocation could be justified if a source-linked, continuing harmful action and its urgency outweigh these measured business effects under owner approval. The safer current decision is to request a bounded identity/session map and service dependency test, preserve evidence, then compare a targeted and broad control contract with positive and negative checks. No production revocation is authorized by the workshop.