◇ OpenCyber Academy
Technologist · Chapter 27 · English

Chapter 27 — Deployment and validation

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

Chapter 27 — Deployment and validation

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Validation is a test of the fix"]
  N2["Lab I — retest status"]
  N3["27.2 Three statuses"]
  N4["27.3 Same custody"]
  N5["27.4 Risk acceptance"]
  N6["27.5 Partial fixes"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Validation is a test of the fix"]
  N2["Lab I — retest status"]
  N3["27.2 Three statuses"]
  N4["27.3 Same custody"]
  N5["27.4 Risk acceptance"]
  N6["27.5 Partial fixes"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Validation is a test of the fix]
    |
    v
[Lab I — retest status]
    |
    v
[27.2 Three statuses]
    |
    v
[27.3 Same custody]
    |
    v
[27.4 Risk acceptance]
    |
    v
[27.5 Partial fixes]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) decide VALIDATED, REOPENED or NOT RETESTED from retest observations; (2) refuse to mark a finding closed on a verbal "we fixed it"; (3) record validation evidence under the same custody rules; (4) feed failures back into the risk tracker.

27.1 Validation is a test of the fix

Remediation validation asks whether the agreed fix removed the problem under the same scope and method constraints. It is not a brand-new engagement, and it is not a rubber stamp.

For ENG-712 the retest uses the same scope list and method cards as the original engagement. Using the visit to probe the excluded fare-payment hosts would be a safety failure, however convenient it might seem. The lab's three status labels keep the language honest by making testers say exactly what was checked and what was not.

Lab I — retest status

"""Lab I (ch 27): decide remediation-validation status from synthetic retest observations."""
retests = [
    ("F-01", "shared admin account", True, True),
    ("F-07", "ex-contractor VPN accounts", True, False),
    ("F-09", "plaintext password on wiki", False, None),
]
for fid, title, fix_claimed, check_passed in retests:
    if not fix_claimed:
        status = "NOT RETESTED - no fix declared"
    elif check_passed:
        status = "VALIDATED"
    else:
        status = "REOPENED"
    print(f"{fid} {status:30} {title}")

Run with python3 lab_retest.py. Verified output:

F-01 VALIDATED                      shared admin account
F-07 REOPENED                       ex-contractor VPN accounts
F-09 NOT RETESTED - no fix declared plaintext password on wiki

27.2 Three statuses

VALIDATED: fix claimed and the check passed. REOPENED: fix claimed but the check failed. NOT RETESTED: no fix declared, so no check yet. Closing a ticket without one of the first two (or an explicit risk acceptance) is a process defect.

The lab output gives one example of each: F-01 VALIDATED, F-07 REOPENED and F-09 NOT RETESTED. Words such as resolved or mostly fixed are rewritten into one of the three labels before the report goes to the CISO. An explicit risk acceptance is the only other way a ticket can close, and it is recorded separately.

27.3 Same custody

Retest evidence — a new configuration export, a new log excerpt — gets hashed and filed like the original. "Looks fine on my screen" is not evidence.

For F-01 the new evidence is filed as E-101 with its own digest, next to the original discovery evidence in the same vault layout. A peer who opens the finding can then compare the before and after files directly. An agreement on a screen share that the setting looks fine leaves nothing that can be verified later.

27.4 Risk acceptance

Sometimes an owner accepts a residual risk with a named approver and a review date. That is a legitimate close path; silence is not.

An acceptance in the tracker needs two fields to be valid: the name of the person accepting the risk and a review date. Priya's team turns each review date into a calendar reminder two weeks before it falls due. An acceptance with either field empty is reopened, because nobody can be held to a decision that has no owner.

27.5 Partial fixes

Sometimes an owner fixes two of three accounts and asks to close the ticket. Priya's rule is to validate what was claimed, reopen or split the finding for what remains, and never let a partial fix erase the whole issue. The tracker should show residual work, not a green checkbox that hides it.

The worked example shows why: F-07 reopened because ex-contractor accounts could still authenticate after a claimed fix, so closing it on the owner's word would have hidden live access. A child ticket split off for any remaining account keeps the parent finding identifier so an examiner can follow the history.

Worked example

Three findings enter retest. F-01 validates. F-07 reopens because ex-contractor accounts still authenticate. F-09 was never declared fixed. Priya updates the tracker: F-01 closed with evidence E-101; F-07 severity remains high and due date resets; F-09 stays open awaiting a fix claim.

Synthetic case. The three retest outcomes are invented.

Errors and limits

Retesting only the happy path and ignoring alternate entry points can falsely validate. Stay inside the original scope unless a new agreement says otherwise.

Exercises

Synthesis

No fix claim, no retest; no evidence, no close; acceptance is explicit or it did not happen.

Continue studying — chapter 27 of 30

← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →