Chapter 22 — Secure configuration management
Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 Changes"]
N2["22.2 Recording configuration"]
N3["22.3 Detecting drift"]
N4["22.4 Emergency changes"]
N5["Server role notes"]
N6["Versioned documents"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 Changes"]
N2["22.2 Recording configuration"]
N3["22.3 Detecting drift"]
N4["22.4 Emergency changes"]
N5["Server role notes"]
N6["Versioned documents"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 Changes]
|
v
[22.2 Recording configuration]
|
v
[22.3 Detecting drift]
|
v
[22.4 Emergency changes]
|
v
[Server role notes]
|
v
[Versioned documents]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) control changes; (2) record configuration; (3) detect drift.
22.1 Changes
NIST SP 800-128 describes security-focused configuration management: establishing baselines, controlling changes and monitoring. At the trust, each server change is recorded in a simple change log with date, who, what and why, and agreed with Dev beforehand.
The log is a shared spreadsheet rather than a ticketing system, because one technician with a few changes a week does not need more. Agreement beforehand means a second person knows a change is planned, which is how the 02:00 sign-in by the outside company could be explained quickly.
22.2 Recording configuration
The baselines from chapters 12 and 13, plus server role notes, form the documented configuration. They are stored in a shared folder with version history.
The documented configuration includes the four SSH settings, the fifteen laptop settings with their sources, and a role note for each of the six servers. Version history means an older baseline can be compared with the current one when a question arises about when a setting changed and why. The folder is readable by Dev, the business manager and the outside company, so whoever is covering can check what a server is supposed to look like.
22.3 Detecting drift
The weekly check scripts compare servers and laptops with their baselines. When drift appears, Dev finds out why before reverting, because drift sometimes reveals a real need.
The SSH lab script and the laptop compliance export are the drift checks; they are the same tools used for measurement, rerun weekly. A deviation is first compared with the change log, since a recorded change explains itself, and only unexplained drift needs investigation before anything is reverted. The X11 forwarding found re-enabled on mis01 is the trust's first example, explained by the change log entry for the graphical installer.
22.4 Emergency changes
Urgent changes during outages are allowed but recorded afterwards within one working day.
An emergency change might be reopening password sign-in on a server when a key is lost and teaching depends on that server. The person making the change records it within one working day with the reason, and the next weekly review checks whether it should be reversed or made permanent through the normal process. Without the one-day rule, an emergency setting can stay in place for months and then appear in a weekly check as unexplained drift nobody remembers making.
Server role notes
Each server has a short role note: what it does, who uses it, which services and ports it needs, who owns it and when it is patched. The notes make drift checks meaningful, because a check can only say something is wrong if it is clear what right looks like.
Writing the notes also surfaces surprises. The print server runs a web interface nobody uses, which is disabled after confirming with the school offices. The web server hosts an old test page that is removed.
Versioned documents
Baselines and server role notes are stored with version history rather than as files that are overwritten. When a setting changes, Dev can see when the document changed, who changed it and compare that with the change log. When an auditor asks why a setting has a particular value, the history and the log together answer the question, which is the evidence trail NIST SP 800-128 describes for configuration management. Tomás also adds a short summary of changes at the top of each document, so readers do not need to compare versions themselves. Old versions are kept, never deleted, because past configurations explain past incidents.
Worked example
A weekly check finds X11 forwarding re-enabled on mis01; the change log shows the outside company enabled it for a graphical installer, and it is turned off after installation.
Synthetic case. Events are synthetic.
Errors and limits
Unrecorded changes make every later problem harder to investigate.
Exercises
- EX064 — Change log fields. List four fields of a change log entry. Rubric: 3 = date, who, what, why;; 2 = three;; 1 = fewer;; 0 = none.
- EX065 — Drift reason. Why investigate drift before reverting? Rubric: 3 = may be legitimate need;; 2 = caution;; 1 = vague;; 0 = none.
- EX066 — Emergency rule. How should emergency changes be handled? Rubric: 3 = allowed, recorded within a day, reviewed;; 2 = recorded;; 1 = vague;; 0 = none.
Synthesis
Change control, documentation and drift checks keep systems as intended.
Continue studying — chapter 22 of 30
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →