Chapter 27 — Critical infrastructure and sector security: verification
Lesson map
Lesson 27 published. Map, example, EX053.
flowchart TD
N0["Learning outcomes and connection"]
N1["27.1 Verification and validation"]
N2["27.2 Kinds of test"]
N3["27.3 Evaluating detectors"]
N4["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX053"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["27.1 Verification and validation"]
N2["27.2 Kinds of test"]
N3["27.3 Evaluating detectors"]
N4["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX053"]
[Learning outcomes and connection]
|
v
[27.1 Verification and validation]
|
v
[27.2 Kinds of test]
|
v
[27.3 Evaluating detectors]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX053]
Learning outcomes and connection
After this chapter you can (1) distinguish verification ("built right") from validation ("right thing built") for security controls; (2) design a test that could show a control does not work; (3) evaluate a detector with precision and recall and choose a threshold with explicit trade-offs; and (4) report verification results with their conditions and limits. It builds on Chapters 8, 12, 15 and 24 and prepares Chapter 29 (operations) and Laboratory II (Chapter 30).
27.1 Verification and validation
Verification checks that a control does what its specification says: the firewall blocks port 3389 from corporate to control; the setpoint validator rejects NaN. Validation checks that the control achieves its purpose in the real setting: corporate users cannot reach control systems by any path; operators cannot send unsafe setpoints. A control can pass verification and fail validation (the firewall rule works, but a dual-homed engineering laptop bypasses it). Good verification is falsifiable: it is designed so that a broken control would fail the test. A test that would pass whether or not the control works proves nothing.
27.2 Kinds of test
Configuration review compares settings with a baseline. Functional tests exercise the control with expected and forbidden inputs (Chapter 8's boundary tests). Flow tests confirm that disallowed paths are blocked (Chapter 7, under authorisation). Restore drills verify recovery controls end to end (Chapter 15). Detection tests replay labelled synthetic or benign-but-suspicious activity to see whether monitoring alerts. In OT, testing on the live process is restricted; use test benches, offline replicas or planned windows agreed with operations.
For CW's corporate-to-control rule, a flow test from an authorised corporate host to control addresses in a planned window is functional; a configuration review alone is not.
27.3 Evaluating detectors
A detector produces scores; a threshold turns them into alerts. Compare alerts with ground truth labels: true positives (TP), false positives (FP), false negatives (FN). Precision = TP/(TP+FP): of the alerts, how many were real? Recall = TP/(TP+FN): of the real events, how many were caught? Raising the threshold usually increases precision and decreases recall. With rare malicious events (Chapter 12's base rate), precision can be poor even with excellent per-event error rates. Choose a threshold by asking what each miss and each false alarm costs the service — and remember that labelled evaluation data seldom matches live conditions (Arp et al., 2022).
27.4 Worked example and Lab 10 (synthetic)
This case is synthetic. Calder Mutual evaluates an anomaly detector on 5,025 labelled events, 25 of them malicious (seed 10).
# Lab 10 - detection evaluation on a labelled synthetic event set (offline)
import random
random.seed(10)
events = [] # (score from a detector, truly malicious?)
for _ in range(5000):
events.append((random.gauss(0.30, 0.12), False))
for _ in range(25):
events.append((random.gauss(0.70, 0.15), True))
for thr in (0.5, 0.6, 0.7):
tp = sum(1 for s, m in events if s >= thr and m)
fp = sum(1 for s, m in events if s >= thr and not m)
fn = sum(1 for s, m in events if s < thr and m)
prec = tp / (tp + fp) if tp + fp else 0
print(f"threshold {thr}: TP={tp:2} FP={fp:3} FN={fn:2} precision={prec:.2f} recall={tp/(tp+fn):.2f}")
Expected output:
threshold 0.5: TP=23 FP=215 FN= 2 precision=0.10 recall=0.92
threshold 0.6: TP=20 FP= 36 FN= 5 precision=0.36 recall=0.80
threshold 0.7: TP=18 FP= 2 FN= 7 precision=0.90 recall=0.72
At 0.5 the team catches 23 of 25 but wades through 215 false alerts; at 0.7 nearly every alert is real but 7 attacks are missed. Neither is "correct". A defensible choice might use 0.7 for paging the on-call analyst and 0.5 for a daily review queue — two thresholds for two costs. The report states the conditions: synthetic scores, one seed, 25 positives (so recall estimates are coarse — Chapter 37), and unknown similarity to live traffic.
27.5 Common errors and limits
- Tests that cannot fail.
- Reporting accuracy on imbalanced data (99.5% "accuracy" by never alerting here).
- Choosing thresholds without stating costs.
- Evaluating on data that resembles training data more than reality.
- Verifying in a lab and claiming validation in production.
Lab 10 shows the second error numerically: never alerting scores 99.5 % accuracy. Choosing 0.5 or 0.7 without saying what a missed attack or an extra 215 false alerts cost is the third. A firewall rule tested only from the lab replica is the fifth. A test that would report "blocked" because the test host was switched off is the first.
Exercises — chapter 27
EX053 — Make it falsifiable. Objective: design a meaningful test. Inputs: claim "the CW firewall prevents corporate users from reaching the control zone". Steps: design a verification test and a validation test, each with a result that would show the claim false, and the authorisation needed. Expected evidence: two test designs. Rubric: 3 = rule-level test from a corporate host to control addresses on all ports in a planned window, plus validation looking for alternative paths (dual-homed hosts, remote access, wireless) via configuration and flow review; authorisation stated; 2 = one test; 1 = non-falsifiable; 0 = none.
EX054 — Accuracy trap. Objective: see why accuracy misleads. Inputs: Lab 10. Steps: compute accuracy for threshold 0.7 and for a detector that never alerts; explain why both look "excellent". Expected evidence: two numbers and explanation. Rubric: 3 = (5025−2−7)/5025 ≈ 0.9982 and 5000/5025 ≈ 0.9950; explains class imbalance and recommends precision/recall; 2 = numbers only; 1 = one number; 0 = none.
Chapter synthesis
Verification asks whether a control works as specified; validation asks whether it achieves its purpose. Design tests that could fail, evaluate detectors with precision and recall at thresholds chosen for stated costs, and report conditions and limits alongside the numbers.
Continue studying — chapter 27 of 40
← Chapter 26 · Course chapter index · Chapter 28 →
Continue to the next authored lesson.