Chapter 10 — Control configuration
Lesson map
Lesson 10 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Config findings"]
N2["10.2 Code findings"]
N3["10.3 Safe proposals"]
N4["10.4 Owner verification"]
N5["10.5 Baselines"]
N6["10.6 Drift"]
N7["10.7 Rollback tested"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX037"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Config findings"]
N2["10.2 Code findings"]
N3["10.3 Safe proposals"]
N4["10.4 Owner verification"]
N5["10.5 Baselines"]
N6["10.6 Drift"]
N7["10.7 Rollback tested"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX037"]
[Learning outcomes]
|
v
[10.1 Config findings]
|
v
[10.2 Code findings]
|
v
[10.3 Safe proposals]
|
v
[10.4 Owner verification]
|
v
[10.5 Baselines]
|
v
[10.6 Drift]
|
v
[10.7 Rollback tested]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes
You will (1) read common secure config baselines; (2) distinguish config finding from code finding; (3) propose safe config changes; (4) verify with the owner.
10.1 Config findings
TLS settings, cookie flags, security headers, VPN cipher suites and the AD password policy are configuration, and are often fixed without code releases. Config findings, such as a missing cookie flag or an open 8080 listener, name the file or listener, the expected baseline and the owner. Config tickets quote the baseline line and the observed drift, for example a missing Secure flag on a session cookie, with the journey planner owner named. Vague "harden servers" lines are rewritten before tickets open, because nobody can verify a fix for a sentence that names no setting.
10.2 Code findings
Logic bugs in authorization need developer changes and regression tests.
When the ROE allows read access to NMT app code or config, Sam cites the file and the line or key in the finding, so the developer can go straight to the place that needs changing. Fare vendor binaries are a different matter: decompiling them stays forbidden under ENG-512, whatever a tool suggests. Findings in that area are described from observed behaviour on staging and routed to the fare owner instead of being backed by reverse engineering.
10.3 Safe proposals
A safe proposal names the setting, the system, the risk if wrong and a rollback. Never apply production config yourself unless the ROE and change process say so. Sam's proposals prefer staging config changes with a rollback, and each includes a staging patch path and a rollback note. He never proposes a production-only tweak that cannot be tested first in the amber zone; production-only ideas wait for change windows Sam does not own. Writing the risk-if-wrong line forces him to think about which riders or staff would notice a bad change first.
10.4 Owner verification
Owners apply changes through their pipeline; Sam verifies.
Verification starts with the owner. The journey planner owner must confirm the fix in the ticket thread and tick the owner checkbox before Sam retests anything. Sam leaves that box blank until the lead has written the confirmation, and a fix with no owner name attached stays open. Unowned fixes therefore cannot reach FIXED in lab_retest language, which stops a change nobody is accountable for from being reported as closed. The ticket history then shows who confirmed the change and when.
10.5 Baselines
NMT's hardening baseline is the checklist; deviations need tickets.
Baselines for TLS versions and cookie flags live in the runbook tag that the ROE names. Sam writes findings as drift from that baseline, quoting the expected value and the observed value, and any "looks bad" wording is rewritten before the report goes out. Drift language gives the owner a concrete target to restore and gives the retest a clear pass condition, which an opinion about appearance cannot provide. The same tag is used again at retest, so both runs measure against one baseline.
10.6 Drift
Config drift after emergency changes is a recurring finding source.
After a CDN change, Sam compares staging against the dated model. If cookie flags have regressed, a ticket is opened mid-week, even when no new ENG window is booked, because waiting for the next Saturday slot would leave a known regression unnamed for days. The ticket quotes the baseline and the observed values, so the owner can see exactly which change introduced the drift and where it needs to be reversed.
10.7 Rollback tested
A config proposal without a tested rollback is incomplete. Sam asks the owner how they would undo the change in fifteen minutes.
Sam will not agree that a risky config change is the fix until its rollback has been drilled on staging and the drill is attached to the ticket as evidence. An untested rollback is recorded as a risk note and keeps the ticket open. Nobody claims production readiness before that drill exists, because a fix that cannot be reversed quickly can turn a minor finding into an outage during the change window.
10.8 Staging first
Production config findings are reproduced on staging when possible before urging a production change.
For ENG-512 config work, staging first is absolute. Sam finishes the amber-zone verification before any production change is discussed, and production changes then wait for the owners' change windows, which Sam does not control. Until those windows run, the retests stay amber, and Sam does not write production-ready wording in the report or the ticket. The status changes only when the amber retests pass and the owner has applied the change in production.
10.9 Field discipline
Sam keeps a personal library of good config proposals (HSTS, cookie flags, VPN ciphers) written in NMT's change-ticket style. Reusing the structure speeds work, but he still fills in system-specific risk and rollback each time. Copy-pasting a proposal meant for staging into a production ticket without changes is how wrong ciphers get proposed, so he treats each proposal as new writing. Field discipline for config is baseline, owner, staging first and a tested rollback; a rollback never run on staging counts as untested however simple it looks on paper, and peer review rejects tickets missing any of the four.
10.10 Closing note
Sam also asks whether a config change needs a maintenance window. Header changes on the reverse proxy may be instant; VPN cipher changes may drop staff sessions and need a bulletin. Timing is part of a complete proposal. Config work at NMT protects riders by staying off fare gear and by naming owners. ENG-512 success is verified baselines on web and API, not a long list of unverified tool noise, and closing config work never includes a promise about fare gear Sam did not touch.
Worked example (synthetic NMT)
Sam finds staging API missing Strict-Transport-Security. He files a config finding with the recommended header and asks app-sec to apply it via their reverse-proxy config.
Synthetic case — Northline Municipal Transit (NMT). The transit agency, Sam Park and all figures are invented for teaching.
Errors and limits
Live transit systems and fare equipment are never tested without a separate, specialised authorization. This book uses synthetic data only and grants no authority to test real systems.
Exercises
- EX037 — Config vs code. Classify: missing HSTS header; rider A can read rider B's journeys. Rubric: 3 = config; code/logic; 2 = swapped; 1 = both config; 0 = none.
- EX038 — Proposal contents. What four things go in a safe config proposal? Rubric: 3 = setting, system, risk if wrong, rollback; 2 = three; 1 = one; 0 = none.
- EX039 — Who applies. Who applies production config changes? Rubric: 3 = owner via change process; not the tester alone; 2 = partial; 1 = tester freely; 0 = none.
- EX040 — Drift. Why do emergency changes create findings later? Rubric: 3 = baselines bypassed; not reverted; 2 = partial; 1 = no reason; 0 = none.
Synthesis
Config findings need clear proposals and owner-applied changes; testers verify.
Continue studying — chapter 10 of 18
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →