Chapter 11 — Operating systems
Lesson map
Lesson 11 published. Map, example, EX021.
flowchart TD
N0["Learning outcomes and connection"]
N1["11.1 What the operating system does"]
N2["11.2 Kinds of OS in critical services"]
N3["11.3 Hardening"]
N4["11.4 Patching in operations"]
N5["11.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX021"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["11.1 What the operating system does"]
N2["11.2 Kinds of OS in critical services"]
N3["11.3 Hardening"]
N4["11.4 Patching in operations"]
N5["11.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX021"]
[Learning outcomes and connection]
|
v
[11.1 What the operating system does]
|
v
[11.2 Kinds of OS in critical services]
|
v
[11.3 Hardening]
|
v
[11.4 Patching in operations]
|
v
[11.6 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX021]
Learning outcomes and connection
After this chapter you can (1) explain processes, memory protection, file permissions and privilege; (2) describe how an operating system enforces least privilege and where it cannot; (3) compare general-purpose, real-time and embedded operating systems in critical services; and (4) build a hardening checklist and a patch decision for a device that cannot be rebooted at will. It builds on Chapter 2's layers and prepares Chapter 13 (identity) and Chapter 24 (controls).
11.1 What the operating system does
The operating system (OS) shares one machine between many programs and users. A process is a running program with its own memory; the OS uses hardware memory protection so one process cannot read or overwrite another's memory. The kernel is the privileged core that manages hardware; user programs ask it for services through system calls. Files carry permissions — on Unix-like systems, read, write and execute for the owner, a group and others — and the OS checks them on every access. Privilege is the ability to bypass such checks: the Unix root account, the Windows Administrator. Saltzer and Schroeder's principles of least privilege and complete mediation — every access checked, every program given only the rights it needs — remain the foundation (Saltzer and Schroeder, 1975).
11.2 Kinds of OS in critical services
General-purpose systems (Windows, Linux, macOS) run servers, operator workstations and office PCs; they are feature-rich, patched frequently and widely attacked. Real-time operating systems (RTOS) guarantee that tasks meet deadlines — a protection relay must act within milliseconds — and run in controllers, relays and medical devices; they are small and less often patched. Embedded firmware in sensors and simple devices may have no separation between programs at all. The consequence: the strongest OS protections exist on the machines that are easiest to replace, and the weakest on the machines that last longest.
11.3 Hardening
Hardening reduces what an attacker can use. A practical checklist: remove or disable unused services and software; change default accounts and passwords; run services as unprivileged accounts; enable logging and send logs off the host; restrict removable media; enable application allowlisting where the workload is stable (operator workstations are good candidates — they run the same few programs for years); keep time synchronised so logs can be correlated. Each item should be checkable — a hardening standard that cannot be verified is a wish.
11.4 Patching in operations
On office IT, patching is routine. On an operator workstation or controller, a patch may require vendor validation, a maintenance window and a rollback plan, because a failed update can stop the process. A risk-based patch decision asks: is the flaw exploitable on this device as deployed (reachable? requires local access?); is it known to be exploited; what does the device control; what compensating controls exist; when is the next window? The result is one of: patch now (emergency change), patch in the next window, mitigate and monitor until replacement, or accept with a named owner. NIST's OT guide discusses these trade-offs (SP 800-82 Rev. 3).
11.5 Worked example: CT signalling workstation (synthetic)
This case is synthetic. Calder Transit's signalling control workstation runs a general-purpose OS. A monthly update fixes a flaw that lets a local, low-privileged user become administrator. The workstation has no internet access, no email, application allowlisting enabled, and only three named signallers log in. The vendor validates OS updates quarterly; the next validated bundle is in seven weeks. Decision: patch in the next window, because exploitation needs a local account on a tightly controlled machine; meanwhile confirm allowlisting is enforced and review the three accounts. Had the flaw been remotely exploitable over a network service the workstation exposes, the answer would have been an emergency change or disabling that service.
11.6 Practical activity
On your own computer, list running processes and the account each runs as; find one service you do not use and find out how it could be disabled (do not disable anything you are unsure about). Write a five-item hardening checklist for a CEDC call-handling workstation, each item with how it would be verified.
For the CEDC workstation, write items such as "call handlers log in with individual accounts without administrator rights; check: list local administrators monthly" or "USB storage blocked; check: insert a test drive during the quarterly review".
11.7 Common errors and limits
- Running everything as administrator "to avoid permission problems".
- Hardening once and never verifying drift.
- Applying office-IT patch cadence to OT without validation and rollback.
- Assuming a device with no OS user interface has no OS.
The CT signalling workstation shows the alternatives: allowlisting and three named accounts instead of administrator use, a quarterly vendor-validated bundle instead of the office's monthly cadence, and a review that checks allowlisting is still enforced. The fourth error covers CVH's infusion pumps, which run an RTOS that needs vendor updates.
Exercises — chapter 11
EX021 — Patch decision. Objective: apply the risk-based questions. Inputs: a remotely exploitable flaw in the web interface of a CVH BMS controller; the interface is reachable from the corporate network; the vendor fix needs a 30-minute controller restart; theatre ventilation depends on the BMS. Steps: answer the five risk-based patch questions of this chapter and recommend. Expected evidence: answers and recommendation with interim controls. Rubric: 3 = restrict access to the interface immediately, schedule the restart with estates and theatres in a planned window, monitor; 2 = right outcome, weak interim controls; 1 = "patch immediately" with no consideration of ventilation; 0 = none.
EX022 — Verifiable hardening. Objective: make controls checkable. Inputs: three vague items: "secure the accounts", "turn on logging", "lock down USB". Steps: rewrite each as a specific, verifiable statement with the check. Expected evidence: three rewritten items. Rubric: 3 = specific, observable, with a check method; 2 = specific but no check; 1 = still vague; 0 = none.
Chapter synthesis
The OS enforces separation, permissions and privilege; least privilege and complete mediation are its guiding ideas. In critical services the most durable devices often have the weakest protections, so hardening must be verifiable and patching must be risk-based, scheduled and reversible.
Continue studying — chapter 11 of 40
← Chapter 10 · Course chapter index · Chapter 12 →
Continue to the next authored lesson.