Chapter 14 — Critical infrastructure and sector security: methods I
Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes and connection"]
N1["14.1 Configuration baselines"]
N2["14.2 Change control that people will use"]
N3["14.3 Planning a change in an operational environment"]
N4["14.4 Evidence of change"]
N5["14.6 Practical activity: write a normal-change plan"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX040"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["14.1 Configuration baselines"]
N2["14.2 Change control that people will use"]
N3["14.3 Planning a change in an operational environment"]
N4["14.4 Evidence of change"]
N5["14.6 Practical activity: write a normal-change plan"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX040"]
[Learning outcomes and connection]
|
v
[14.1 Configuration baselines]
|
v
[14.2 Change control that people will use]
|
v
[14.3 Planning a change in an operational environment]
|
v
[14.4 Evidence of change]
|
v
[14.6 Practical activity: write a normal-change plan]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes and connection
After this chapter you should be able to:
- write a configuration baseline for a class of host and keep it under version control;
- run change control that is proportionate: standard, normal and emergency changes;
- plan a change in an operational environment with pre-checks, a window, a rollback and a verification step;
- link every change to evidence that it was made as approved.
Chapters 1–13 described systems, data and risks. This chapter and Chapter 16 are about methods: the routines a technologist runs every week. Methods I covers baselines and change, because nearly every other control depends on knowing what a system should look like and controlling how it changes.
14.1 Configuration baselines
A baseline is the approved configuration for a class of system: installed packages and versions, enabled services and their listening addresses, accounts and groups, file permissions, logging and time settings, and security parameters. NIST's guide to security-focused configuration management describes establishing baselines, controlling changes to them and monitoring for deviation (NIST SP 800-128). Write the baseline as a file in version control, not a document in someone's folder: Chapter 22 uses it to detect drift automatically.
14.2 Change control that people will use
Change control exists to stop unreviewed changes causing outages or weakening security. Overly heavy processes get bypassed; that is how debug listeners and unexplained helper scripts appear (Chapter 6). A proportionate scheme has three kinds of change:
- Standard changes — pre-approved, low-risk, repeatable (adding a station to the allowlist from an approved request). They follow a written procedure and are logged.
- Normal changes — reviewed and approved before implementation, with a plan and rollback.
- Emergency changes — made quickly to restore service or contain an incident, approved by a named on-call authority, and reviewed afterwards.
In OT, the approval for any change that could affect the physical process includes the operations owner, not only IT.
14.3 Planning a change in an operational environment
A change plan for LANTERN states: what will change and why; affected systems and customers; pre-checks (backups taken, rollback staged, operations informed); the window (agreed with operations — not during the morning demand peak or a scheduled report run); step-by-step implementation; verification (how you will know it worked — specific checks, not "test the service"); rollback criteria and steps; and who to call. Chapter 27 extends this to deployments with canaries.
Moving RLY-02's SSH listener is a typical case: the rollback must not depend on SSH.
14.4 Evidence of change
After a change, three things should agree: the change record (what was approved), the version-controlled baseline (what should now be true) and the system itself (what is true, verified by the integrity check of Chapter 6 and the drift check of Chapter 22). When they disagree, either the change was not made as approved or the record is wrong. Both are findings.
After CHG-118, all three agreed for allow.list and disagreed for the debug listener.
For the debug listener there was no change record at all, so the disagreement itself was the finding, and it led to the investigation in Chapter 6.
14.5 Worked example: adding PS-11 (synthetic)
Water operations commissions a new station, PS-11. Adding it to LANTERN is a standard change with a written procedure: (1) receive the commissioning request with station ID, address and owner; (2) confirm the conduit already covers the station subnet; (3) add PS-11 to the allowlist in version control, reviewed by a second technologist; (4) deploy the allowlist to the relays; (5) verify: PS-11's first messages appear as accept in the relay log; the integrity check shows allow.list changed under CHG-118 and nothing else; (6) update the inventory and data-flow register. In Chapter 6's lab, this was the one approved difference. The other three differences had no change record — which is how the method revealed them.
14.6 Practical activity: write a normal-change plan
Write a full change plan for: "Move RLY-02's SSH listener from all interfaces to the management interface only." Include every element of Chapter 14 ("Planning a change in an operational environment"). Pay attention to the risk that you lock yourself out: how will you reach the host if the change fails?
For the RLY-02 change, a safe plan keeps a second way in: console access through the hypervisor, or an open session on the management interface, tested before the listener is moved. Verification is specific: SSH answers on the management address, does not answer on the station-facing address, and the drift check shows only the intended line changed. Choose the window with Water operations, avoiding the morning demand peak and the weekly report runs on days 6 and 7.
14.7 Common errors and limits
- Baselines kept as documents that nobody compares with systems.
- Change processes so heavy that people bypass them.
- Change windows chosen for IT's convenience rather than operations'.
- "Verify the service works" as the verification step.
- Rollback plans that were never tested.
- Emergency changes never reviewed afterwards, so they become permanent.
Change control controls authorized change. It does not detect unauthorized change; that is the job of integrity and drift checks.
The NTP merge in Chapter 25 is the fourth error in practice: its acceptance criterion said only "update NTP servers".
Exercises — chapter 14
EX040 — Classify changes. Objective: apply proportionate change control. Inputs: (a) add a station to the allowlist; (b) upgrade the relay software to a new minor version; (c) disable a compromised vendor account at 02:00; (d) change the historian retention from 730 to 365 days; (e) rotate the relay's HMAC key. Constraints: standard, normal or emergency for each, with one reason. Steps: classify and say who approves. Expected evidence: table. Rubric: 3 = (a) standard, (b) normal, (c) emergency with on-call approval and review, (d) normal with data-owner approval because it affects records and obligations, (e) normal (or standard once a tested procedure exists) coordinated with stations; approvers sensible; 2 = one misclassified; 1 = all normal; 0 = none.
EX041 — Verification steps. Objective: write specific verification. Inputs: the change "relay forwards to HIST-01 over TLS 1.3 instead of TLS 1.2". Constraints: at least four checks; each observable. Steps: list the checks and the evidence each produces. Expected evidence: list. Rubric: 3 = for example connection log shows negotiated TLS 1.3, historian receives readings from all stations within normal latency, no rise in relay errors or rejects, certificate validation still enforced, integrity check shows only the approved file changed; 2 = three; 1 = "test it"; 0 = none.
EX042 — Review an emergency change. Objective: close the loop on emergency change. Inputs: during an outage at 03:00 an engineer opened tcp/22 from the corporate zone directly to all relays "temporarily". Constraints: post-change review within one working day. Steps: (1) list the questions the review asks; (2) decide what happens to the rule; (3) say what process change prevents a repeat. Expected evidence: review note. Rubric: 3 = asks why the jump host route failed, who approved, what was accessed during the window (logs), removes or narrows the rule with a change record, fixes the jump host resilience or emergency access design; 2 = rule removed but no root cause; 1 = rule kept; 0 = none.
Chapter synthesis
Write approved configurations as baselines in version control. Run change control proportionately — standard, normal and emergency — with operations approving changes that can affect the physical process. Plan changes with pre-checks, an agreed window, specific verification and a tested rollback. After every change, the record, the baseline and the system should agree; when they do not, you have a finding.
Continue studying — chapter 14 of 30
← Chapter 13 · Course chapter index · Chapter 15 →
Continue to the next authored lesson.