Chapter 16 — Critical infrastructure and sector security: methods II
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes and connection"]
N1["16.1 Vulnerability intake and applicability"]
N2["16.2 Prioritization"]
N3["16.3 Treatment when you cannot patch quickly"]
N4["16.4 Verification"]
N5["16.5 Backups and restore tests"]
N6["16.7 Practical activity: vulnerability record"]
N7["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["16.1 Vulnerability intake and applicability"]
N2["16.2 Prioritization"]
N3["16.3 Treatment when you cannot patch quickly"]
N4["16.4 Verification"]
N5["16.5 Backups and restore tests"]
N6["16.7 Practical activity: vulnerability record"]
N7["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes and connection]
|
v
[16.1 Vulnerability intake and applicability]
|
v
[16.2 Prioritization]
|
v
[16.3 Treatment when you cannot patch quickly]
|
v
[16.4 Verification]
|
v
[16.5 Backups and restore tests]
|
v
[16.7 Practical activity: vulnerability record]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes and connection
After this chapter you should be able to:
- run a vulnerability-handling routine: intake, applicability, prioritization, treatment and verification;
- prioritize fixes using exploitation evidence, exposure and asset consequence rather than severity score alone;
- plan patching where the device cannot be patched quickly, using compensating controls with an end date;
- design, run and record backups and restore tests that prove recovery within a target time.
Methods I (Chapter 14) controlled change. Methods II covers the two routines that most often decide how bad a bad day becomes: dealing with vulnerabilities before they are exploited, and recovering when something is lost anyway.
16.1 Vulnerability intake and applicability
Advisories arrive from vendors, national agencies and security mailing lists. The first question is applicability: do we run the affected product and version, in a configuration where the flaw matters? This depends on the inventory (Chapter 11) being accurate about versions. Record the decision — "applicable", "not applicable (reason)", "unknown (action to find out)" — for every advisory touching a product in the inventory. "Unknown" is common in OT and must have an owner.
For the Arlen 300 advisory, the inventory held both versions: PS04-PLC on 4.2 and PS07-PLC on 3.9.
16.2 Prioritization
A severity score describes the flaw in general; your priority depends on your situation. Three questions sharpen it. Is it being exploited? CISA's Known Exploited Vulnerabilities catalog lists flaws with evidence of active exploitation (CISA KEV); such entries move to the front. Is it exposed? A flaw reachable from the internet or from the corporate zone is more urgent than one reachable only from inside a well-controlled conduit. What is the consequence? A flaw on a criticality-1 asset in the station zone matters more than one on a depot kiosk. Patch management guidance treats this as risk-based scheduling with defined maintenance plans for different asset groups (NIST SP 800-40 Rev. 4).
16.3 Treatment when you cannot patch quickly
Station controllers may need vendor-certified firmware, a site visit, an outage window and re-testing of the process. Treatment then has two parts: compensating controls now (restrict the conduit further, disable the vulnerable function if not used, add monitoring for exploitation attempts, increase review of the device's configuration) and a dated plan for the fix. Record both, and the residual risk owner (Chapter 13). Remember Chapter 9: these long-open items must appear in your patch measures.
PS04-PLC and PS07-PLC are the Fallowmere case: disable the unused web interface, close the corporate→PS-04 path, alert on the web port, then firmware 4.3 at the next site visits.
16.4 Verification
A fix is complete when it is verified on the device: the version is confirmed (from the device or its engineering export, not from the ticket), the service works (Chapter 27's checks), and the compensating controls that are no longer needed are removed under change control — otherwise temporary rules accumulate.
For PS07-PLC, the version was read from the device on the site visit: 3.9, as recorded, so the fix is still open. When 4.3 is installed, the evidence is the engineer's export showing 4.3, and the alert on the PLC web port is kept or removed by its own change record.
16.5 Backups and restore tests
A backup that has not been restored is a hope. NIST's contingency planning guide covers backup and recovery planning and testing (NIST SP 800-34 Rev. 1), and NIST's guide to recovery from cyber events stresses preparing and exercising recovery in advance (NIST SP 800-184). For LANTERN:
- What is backed up: relay configuration and allowlist (in version control already), keys (in their protected store's own backup), historian database, controller programs and configurations (by Water's engineers), and the documentation needed to rebuild.
- Where: at least one copy offline or immutable, so that ransomware or an administrator mistake cannot delete every copy.
- Targets: a recovery time objective (RTO — how quickly service must be back) and a recovery point objective (RPO — how much data loss is tolerable). For HIST-01 at Fallowmere: RTO 4 hours, RPO 24 hours.
- Restore tests: scheduled, timed, recorded, with the result compared to the targets; Chapter 9 shows how to report them honestly.
16.6 Worked example: an advisory for the Arlen 300 (synthetic)
An advisory reports a flaw in the Arlen 300 PLC's web management interface, firmware below 4.3, now listed as exploited elsewhere (synthetic). Applicability: PS04-PLC runs 4.2 and PS07-PLC runs 3.9 — both applicable. Exposure: the web interface should be reachable only from the engineering jump path; but the Chapter 2 flow review found a corporate workstation talking directly to PS-04. Priority: high on all three questions. Treatment: today, confirm with Water's engineer whether the web interface is used and, if not, disable it; close the corporate→PS-04 path (already raised); add an alert for any connection to the PLCs' web port. Fix: firmware 4.3 at the next site visits, with Water's process testing. Verification: version read from engineering export; alert and conduit tested.
16.7 Practical activity: vulnerability record
Write the full record for the Chapter 16 ("Worked example: an advisory for the Arlen 300") advisory: applicability per asset, priority with reasons for each of the three questions, compensating controls with evidence, fix plan with dates and owners, verification steps, and the residual-risk owner.
Priority for PS04-PLC rests on three answers: applicable (4.2 is below 4.3), exploited elsewhere, and exposed, because the flow review saw a corporate workstation talking to PS-04. PS07-PLC is applicable and exploited, but no undeclared path has been seen, so its exposure reason is weaker. Name Water operations as residual-risk owner until 4.3 is verified on both.
16.8 Common errors and limits
- Prioritizing by severity score alone.
- Marking "not applicable" without checking versions.
- Leaving "unknown" without an owner.
- Compensating controls without an end date, so they become permanent.
- Closing the ticket when the patch is scheduled, not when it is verified.
- Backups stored where the same administrator account can delete all copies.
- Measuring backup success by job completion instead of restore tests.
Both PLCs show the fifth error's risk: the ticket would close at "firmware 4.3 scheduled", while 3.9 still runs at PS-07.
PS04-PLC's 4.2 would have been marked not applicable by anyone reading only the advisory's score.
Exercises — chapter 16
EX046 — Prioritize three advisories. Objective: apply exploitation, exposure and consequence. Inputs: (a) critical-severity flaw in the depot kiosk browser, no known exploitation, kiosk on the depot network with internet access; (b) medium-severity flaw in the relay's SSH server, listed in KEV, SSH reachable only from the jump host; (c) high-severity flaw in HIST-01's database, no known exploitation, reachable from the corporate zone. Constraints: rank and justify in one sentence each. Steps: rank, then give a target date for each. Expected evidence: table. Rubric: 3 = (b) first because of active exploitation and criticality despite medium score and restricted exposure; then a defensible ordering of (c) and (a) with reasons (consequence of historian vs internet exposure of kiosk); dates proportionate; 2 = ranking defensible, reasons thin; 1 = by severity only; 0 = none.
EX047 — Compensating-control plan. Objective: treat a vulnerability that cannot be patched quickly. Inputs: Chapter 16 ("Worked example: an advisory for the Arlen 300"); firmware 4.3 can be installed at PS-07 only in 10 weeks. Constraints: at least three controls, each with evidence and an end date. Steps: write the plan. Expected evidence: table. Rubric: 3 = disable web interface if unused (evidence: engineering export), conduit restriction verified by flow review, alert on web-port connections tested, increased configuration comparison; all ending when 4.3 is verified; 2 = no end dates; 1 = "monitor"; 0 = none.
EX048 — Restore test design. Objective: design a restore test that proves the RTO. Inputs: HIST-01, RTO 4 h, RPO 24 h. Constraints: must not disturb production; must be repeatable. Steps: (1) describe the test environment; (2) the steps and timing points; (3) the pass criteria; (4) what is recorded. Expected evidence: one page. Rubric: 3 = isolated restore target, starts from the offline/immutable copy, times from "decision to restore" to "operators can query data", checks data recency against RPO, records times, gaps and lessons, and is scheduled regularly; 2 = timing or RPO check missing; 1 = "check the backup job succeeded"; 0 = none.
Chapter synthesis
Handle vulnerabilities as a routine: decide applicability from the inventory, prioritize by exploitation, exposure and consequence, apply compensating controls with end dates where patching is slow, and verify fixes on the device. Back up what you need to rebuild, keep a copy that cannot be deleted by the same people who run production, set RTO and RPO, and prove them with timed restore tests.
Continue studying — chapter 16 of 30
← Chapter 15 · Course chapter index · Chapter 17 →
Continue to the next authored lesson.