Chapter 7 — Controls and verification | Professional Authorized offensive security and red team

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 7 — Controls and verification

Lesson map

Lesson 07 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["7.1 Match control to finding"]
  N2["7.2 Compensating controls"]
  N3["7.3 Retest design"]
  N4["7.4 Verified means"]
  N5["7.5 Tracking"]
  N6["7.6 Partial fixes"]
  N7["7.7 Verification owners"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["7.1 Match control to finding"]
  N2["7.2 Compensating controls"]
  N3["7.3 Retest design"]
  N4["7.4 Verified means"]
  N5["7.5 Tracking"]
  N6["7.6 Partial fixes"]
  N7["7.7 Verification owners"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]

[Learning outcomes]
    |
    v
[7.1 Match control to finding]
    |
    v
[7.2 Compensating controls]
    |
    v
[7.3 Retest design]
    |
    v
[7.4 Verified means]
    |
    v
[7.5 Tracking]
    |
    v
[7.6 Partial fixes]
    |
    v
[7.7 Verification owners]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) suggest controls that match findings; (2) distinguish compensating controls; (3) plan a retest; (4) know when a control is verified.

7.1 Match control to finding

A shared admin password finding wants named accounts and vaulting; an open redirect wants allow-listed destinations; a missing cookie flag wants the flag set and checked in CI. Leo writes each recommendation to match the finding: named VPN accounts and a vault for shared passwords; allow-listed destinations for an open redirect; Secure and HttpOnly flags checked in CI for the session cookie. App-sec owns Secure and HttpOnly for the cookie-flag finding, and the recommendation line carries that name and a due date. Generic advice such as "harden the app" or "harden sessions" does not tell an owner what to change.

7.2 Compensating controls

When the ideal fix is months away, a compensating control reduces risk now — for example, VPN admin paths restricted to jump hosts while password reuse is being eliminated. Leo records the compensating control as temporary, with an owner and a date to revisit the ideal fix, so it does not become permanent by neglect. Temporary network restrictions around an outdated banner are acceptable on the same terms: after the banner is patched, the access rules come off the ticket with a retest note and a retire timestamp. Open-ended compensations become forgotten debt.

7.3 Retest design

Retest only the agreed findings, with the same or equivalent method, after the owner says the fix is live. Record pass or fail with evidence. After the owner says the cookie flags are live on staging, Leo repeats the same check with the recorded tool version, and pass or fail goes on the ticket with a fresh screenshot. He confirms hostnames, ports and build versions against the owner's change note before calling a retest a failure. A retest that touches a host outside the original ENG-440 list waits for a written scope update, and retesting unrelated findings wastes the window.

7.4 Verified means

Verified means Leo reproduced the original symptom as fixed (or confirmed the compensating control works), not that the owner said they fixed it. Owner confirmation of deployment is necessary but not sufficient. Leo or another tester must see the original symptom gone, or the compensating control working, before the ticket is marked verified. Before-and-after cookie screenshots are hashed into the vault and linked from T-15, so verification is evidence in the record, not a verbal assurance that someone thinks it is fixed.

7.5 Tracking

Findings become tickets with owners and dates; verification closes them. Each HCU finding becomes a ticket with an owner and a due date, and verification evidence closes it. Tickets without owners or dates hide risk in the backlog, which is why Chapter 10's lab_ticket flags incomplete fields: it marks T-15 incomplete for owner and verified, and T-18 incomplete for due date, and those never count as closed-ready. Every Friday Leo opens the tracker, and blanks on owner or due date escalate the same week rather than aging into exam findings.

7.6 Partial fixes

Sometimes owners fix one path and leave another open. Leo's retest checklist names each path from the original finding. A ticket is not closed until every listed path fails to reproduce the issue or an accepted compensating control is verified. For an open redirect, Leo lists each parameter and path from the original finding; closing after fixing only one leaves members exposed on the others. If one redirect path remains after a partial fix, the CISO accepts it in writing with an expiry or the ticket stays open on the tracker until the residual is owned or removed.

7.7 Verification owners

The person who applies a fix should not be the only person who marks it verified. Leo or another tester retests; the owner confirms deployment. Separation keeps wishful closures out of the metrics: "fixed because I deployed it" does not survive a separate retest. The same rule applies to Leo, so a colleague verifies any compensating control he applied and closure never rests on the same hands that made the change. Metrics that count verified tickets only after a separate tester signs keep the numbers honest for the CISO and examiners.

7.8 Regression watch

After a fix, Leo asks whether related paths were checked by the owner. A patched open redirect that leaves a second parameter untouched is a common regression; the retest plan names siblings when they exist. When the owner patches one redirect parameter, Leo's retest plan already names the sibling parameters from the finding, and regressions are cheaper to catch in the same window than in the next exam cycle. Regression watch after ENG-440 also checks that cookie flags and redirect fixes stay in later builds. A fix that vanishes in the next staging deploy reopens the ticket with the build id attached.

Worked example (synthetic HCU)

For the shared VPN admin password, HCU enables MFA and named accounts in two weeks (ideal) and, meanwhile, restricts admin paths to the jump host (compensating). Leo retests both.

Synthetic case — Harborline Credit Union (HCU). The credit union, Leo Okonkwo and all figures are invented for teaching.

Errors and limits

Local policies and laws differ; follow HCU's authorization and your jurisdiction. This book never authorizes testing of real systems.

Exercises

EX031 — Control match. Suggest a control for open redirect. Rubric: 3 = allow-list redirect targets / remove parameter; 2 = partial; 1 = "firewall"; 0 = none.
EX032 — Compensating example. Give one compensating control for password reuse on VPN admin. Rubric: 3 = restrict admin to jump host / MFA / monitoring; 2 = partial; 1 = ignore; 0 = none.
EX033 — Retest trigger. When does retest start? Rubric: 3 = after owner confirms fix live / in agreed window; 2 = partial; 1 = immediately always; 0 = none.
EX034 — Not verified. Owner emails "we fixed it" with no details. Is it verified? Rubric: 3 = no; need retest evidence; 2 = no; 1 = yes; 0 = none.
EX035 — Retest scope. May Leo test unrelated new URLs during retest? Rubric: 3 = no; only agreed findings unless scope extended; 2 = no; 1 = yes; 0 = none.

Synthesis

Controls match findings; compensating controls buy time; verification is a retest with evidence.

Continue studying — chapter 07 of 12

← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →