Chapter 12 — Operating systems
Lesson map
Lesson 12 published. Map, example, EX023.
flowchart TD
N0["Learning outcomes and connection"]
N1["12.1 What an operating system does"]
N2["12.2 Real-time operating systems"]
N3["12.3 OS security mechanisms"]
N4["12.4 Patching under availability constraints"]
N5["12.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX023"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["12.1 What an operating system does"]
N2["12.2 Real-time operating systems"]
N3["12.3 OS security mechanisms"]
N4["12.4 Patching under availability constraints"]
N5["12.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX023"]
[Learning outcomes and connection]
|
v
[12.1 What an operating system does]
|
v
[12.2 Real-time operating systems]
|
v
[12.3 OS security mechanisms]
|
v
[12.4 Patching under availability constraints]
|
v
[12.6 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX023]
Learning outcomes and connection
After this chapter you can (1) explain processes, threads, scheduling, memory management and file systems; (2) distinguish general-purpose and real-time operating systems and choose between them; (3) apply OS security mechanisms — accounts, permissions, isolation, logging, patching — to control-centre servers and engineering workstations; and (4) plan patching and hardening under the availability constraints of operational technology. It builds on Chapter 8 and prepares Chapters 18 and 39.
12.1 What an operating system does
An OS multiplexes hardware among programs and provides abstractions: processes (isolated address spaces), threads (concurrent execution within a process), virtual memory, files and devices. The kernel runs privileged; applications request services through system calls. The scheduler decides which thread runs; its policy determines latency.
For LRWA, the SCADA servers and engineering workstations run general-purpose operating systems, while the pump protection logic runs on the RTUs and PLCs at each station. Knowing which code runs where tells you which machines need real-time guarantees and which need hardening, patching and logging of the kind described below.
12.2 Real-time operating systems
A real-time OS guarantees bounded response: tasks with deadlines are scheduled so that, if the analysis says they fit, they meet their deadlines. Fixed-priority scheduling with rate-monotonic priority assignment is a classic approach; Liu and Layland's analysis gives a sufficient utilisation bound for periodic tasks under that policy. General-purpose OSes (Windows, desktop Linux) optimise throughput and fairness; their worst-case latency is not bounded without special configuration. Rule: protection functions run on real-time controllers; supervisory functions (HMI, historian) can run on general-purpose systems.
12.3 OS security mechanisms
- Least privilege: services run under dedicated accounts with only needed rights; no shared administrator accounts. Saltzer and Schroeder (1975) set out least privilege, fail-safe defaults, complete mediation and economy of mechanism as design principles that still hold.
- Access control: file and object permissions; mandatory access control where available.
- Application allowlisting: only approved executables run — practical on single-purpose OT hosts whose software rarely changes.
- Logging: authentication, privilege use, service changes and process creation, forwarded off-host.
- Hardening: remove unused services, close unused ports, disable removable-media autorun.
- Patching: apply security updates, tested and scheduled.
12.4 Patching under availability constraints
OT systems often cannot be rebooted at will, and vendors may support only specific patch levels. Patching is therefore risk-based: assess each vulnerability's exploitability in your architecture (is the vulnerable service reachable?), its consequence, and the availability risk of applying it; then patch, mitigate (block the port, disable the feature) or accept with a review date. Keep a test system that mirrors production to validate patches. The NIST OT guide (SP 800-82 Rev. 3) discusses these tradeoffs.
12.5 Worked example: hardening the SCADA servers (synthetic)
LRWA's two SCADA servers run a general-purpose OS. The TMRP baseline: dedicated service accounts; operators log in with named accounts; local administrator disabled except a break-glass account whose password is sealed and whose use alarms; allowlisting enabled after a two-week learning period in a test environment; USB storage blocked; logs forwarded to the DMZ collector; a monthly patch window alternating between servers so one always runs. The residual risk — the vendor certifies patches 30 days after release — is mitigated by network rules that expose only the SCADA application ports to the field and the DMZ.
12.6 Practical activity
On a Linux virtual machine you own, list listening services (ss -tulpn), local accounts with login shells, and enabled services. Write a hardening note: which services you would disable on a single-purpose historian host and why. Do not run this against any system you do not own.
Record the output with the date and the machine's name, and for each service you would disable, note what would break if you were wrong. A historian host at LRWA would need its database service and log forwarding, but rarely a mail server or a file-sharing service. Compare your list with the hardening measures in the SCADA example and explain any difference. The exercise trains the habit of asking why each service is running before deciding whether it should.
12.7 Common errors and limits
- Running protection logic on a general-purpose OS.
- Shared accounts that destroy accountability.
- Patching by calendar without assessing exploitability — or never patching because "OT is special".
- Logs kept only on the host an attacker controls.
- Allowlisting switched on in production without a learning period.
LRWA's SCADA hardening avoids each of these: named accounts replace shared ones, logs leave the host, allowlisting followed two weeks of learning in a test environment, and the monthly patch window alternates between the two servers. The residual risk is recorded.
Exercises — chapter 12
EX023 — Rate-monotonic check. Objective: test schedulability with the Liu–Layland bound. Inputs: three periodic tasks on an RTU: (C=2 ms, T=10 ms), (C=4 ms, T=40 ms), (C=10 ms, T=100 ms). Steps: compute utilisation; compute the bound $n(2^{1/n}-1)$ for $n = 3$; conclude. Expected evidence: numbers and conclusion. Rubric: 3 = U = 0.40, bound ≈ 0.780, schedulable by the sufficient test with the caveat that failing the bound would not prove unschedulability; 2 = caveat missing; 1 = arithmetic error; 0 = none.
EX024 — Patch decision. Objective: make a risk-based patch decision. Inputs: a remote-code-execution vulnerability in the OS file-sharing service; the service is enabled on the historian but blocked by the control-zone firewall from all zones except the engineering zone; vendor certification of the patch is 30 days away. Steps: recommend patch / mitigate / accept, with interim controls and a review date. Expected evidence: decision note. Rubric: 3 = mitigation (disable service or restrict further) now, patch after certification, monitoring, date; 2 = no interim control; 1 = "patch immediately" ignoring vendor support or "accept" without reasoning; 0 = none.
Chapter synthesis
The OS determines both timing and the security baseline. Put deadlines on real-time platforms. Apply least privilege, allowlisting, hardening and off-host logging. Patch on assessed risk with tested procedures and compensating controls when you cannot patch yet, and keep a mirror environment to make that possible.
Continue studying — chapter 12 of 50
← Chapter 11 · Course chapter index · Chapter 13 →
Continue to the next authored lesson.