Chapter 2 — Computing systems
Lesson map
Lesson 02 published. Map, example, EX003.
flowchart TD
N0["Learning outcomes and connection"]
N1["2.1 Layers and trust"]
N2["2.2 IT and OT"]
N3["2.3 The device life cycle"]
N4["2.5 Practical activity"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX003"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["2.1 Layers and trust"]
N2["2.2 IT and OT"]
N3["2.3 The device life cycle"]
N4["2.5 Practical activity"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX003"]
[Learning outcomes and connection]
|
v
[2.1 Layers and trust]
|
v
[2.2 IT and OT]
|
v
[2.3 The device life cycle]
|
v
[2.5 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX003]
Learning outcomes and connection
After this chapter you can (1) describe the layers of a computing system — hardware, firmware, operating system, applications, data and people — and say where security decisions are made in each; (2) distinguish information technology (IT) from operational technology (OT) and explain why their priorities differ; (3) describe the life cycle of a device in a critical service, from procurement to disposal; and (4) explain why the oldest component in a system often sets its security. It builds on Chapter 1's habit of explicit quantities and prepares Chapter 3, where you will write code to inspect a device inventory.
2.1 Layers and trust
A computer is a stack. At the bottom is hardware: processor, memory, storage and interfaces. Above it is firmware, the low-level code stored on the device that starts it and controls hardware. The operating system (Chapter 11) shares the hardware between programs and enforces who may do what. Applications do the work people care about — an infusion-pump drug library, a dispatch system, a payment switch. Data is what applications create and consume. People configure, use and maintain all of it. Each layer trusts the layers below it: an application cannot be more trustworthy than the operating system it runs on, and an operating system cannot detect firmware that lies to it. This is why secure boot, signed firmware and vendor support matter so much in critical services (Chapter 17).
2.2 IT and OT
Information technology handles information: email, records, payments, scheduling. Operational technology monitors and controls physical processes: valves, breakers, pumps, signals, ventilators. NIST describes OT as systems that "interact with the physical environment (or manage devices that interact with the physical environment)" (NIST SP 800-82 Rev. 3). The distinction matters because the consequences differ. When an IT system fails, information is unavailable or wrong; when an OT system fails, water may stop, a breaker may not open, or a train may not receive a signal. OT devices are typically expected to run for 15–25 years, may not tolerate a reboot during operation, and are often certified in a particular configuration so that patching requires vendor approval. Healthcare adds a third category, medical devices, which are regulated products whose software cannot simply be changed by the hospital.
2.3 The device life cycle
Security is decided long before an attack. At procurement, a buyer can require supported software, a vulnerability-disclosure process and a software bill of materials (SBOM — a list of software components, see CISA SBOM). At installation, defaults can be changed and the device placed in the right network zone. During operation, it needs monitoring, patching where possible and compensating controls where not. At end of support, the vendor stops issuing fixes; the device still works, which is exactly why it stays in service. At disposal, data must be removed. A hospital imaging workstation bought in 2014 on an operating system whose support ended in 2020 is not a careless anomaly; it is the normal consequence of a 15-year medical device on a 10-year operating system.
2.4 Worked example: Calder Valley Hospital imaging (synthetic)
This case is synthetic. CVH's imaging department runs workstation IMG-01, attached to a scanner certified by its manufacturer with a specific operating system that reached end of support in 2020. The manufacturer offers an upgrade only with a new scanner (£400,000). Options are: (a) replace now; (b) keep it and isolate it — allow only the connections it needs to the image archive, remove email and web browsing, monitor its traffic; (c) do nothing. Option (c) leaves a known-unpatched machine on a flat clinical network. Option (a) removes the risk but costs a capital budget the hospital does not have this year. Option (b) is the usual answer: a compensating control that reduces exposure until replacement, with a named owner and a replacement date. The decision record says which risk remains — a malicious file arriving through the archive connection — and how it is monitored.
2.5 Practical activity
Choose one device you use daily (a phone, a home router, a laptop). Without opening it or changing anything, find from the vendor's public pages: its firmware or OS version, whether it is still supported, and how updates are delivered. Write a five-line life-cycle note: procurement, installation, operation, end of support, disposal. Do the same for one imagined device in a critical service — a CVH infusion pump — and list what you would need to ask its vendor.
For the pump, ask the vendor about the drug-library update process, the support end date for its firmware and who may install updates.
2.6 Common errors and limits
- Assuming "it still works" means "it is still safe": unsupported devices accumulate unfixed vulnerabilities.
- Treating OT like IT: rebooting a controller during operation, or scanning it aggressively, can disrupt the physical process.
- Ignoring firmware: it is code, it has vulnerabilities, and it is rarely inventoried.
- Forgetting people as a layer: most systems are configured by someone under time pressure.
At CVH the four errors meet in IMG-01: it still works, so it stayed on the clinical network; its scanner certification makes it OT-like in its patch constraints; nobody listed its firmware; and the radiographers who use it chose the shared desktop settings. The limit of this chapter is that it names layers without measuring how many devices sit in each.
Exercises — chapter 2
EX003 — Locate the decision. Objective: connect layers to controls. Inputs: five controls: signed firmware updates, operating-system user accounts, an application's drug-library limits, database backups, staff training. Steps: assign each to a layer and state one failure each control does not address. Expected evidence: a five-row table. Rubric: 3 = correct layers and a plausible gap for each; 2 = one error; 1 = layers only; 0 = none.
EX004 — IT or OT? Objective: reason about consequences. Inputs: CPN's billing system, CPN's feeder RTU, CVH's patient-administration system, CVH's BMS that controls theatre ventilation. Steps: classify each as IT, OT or medical device; name the worst plausible consequence of its failure; say whether a vendor-approved patch window is likely needed. Expected evidence: table and two sentences on the BMS. Rubric: 3 = correct classes, consequences tied to physical effects for OT; 2 = minor slip; 1 = classes only; 0 = none.
Chapter synthesis
Computing systems are stacks of trust, from hardware to people. OT and medical devices control physical outcomes, live for decades and cannot always be patched, so security relies on procurement terms, placement and compensating controls. The oldest, least-supported component often defines the real exposure.
Continue studying — chapter 02 of 40
← Chapter 01 · Course chapter index · Chapter 03 →
Continue to the next authored lesson.