Chapter 20 — Systems, endpoints and hardware security: foundational cases
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 Lost devices"]
N2["20.2 Patch delays"]
N3["20.3 Misconfiguration"]
N4["20.4 Lessons for Bramley"]
N5["20.5 Using cases"]
N6["Turning cases into actions"]
N7["Evaluating sources"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 Lost devices"]
N2["20.2 Patch delays"]
N3["20.3 Misconfiguration"]
N4["20.4 Lessons for Bramley"]
N5["20.5 Using cases"]
N6["Turning cases into actions"]
N7["Evaluating sources"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 Lost devices]
|
v
[20.2 Patch delays]
|
v
[20.3 Misconfiguration]
|
v
[20.4 Lessons for Bramley]
|
v
[20.5 Using cases]
|
v
[Turning cases into actions]
|
v
[Evaluating sources]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) learn from public cases of endpoint failures; (2) extract lessons; (3) apply them to Bramley.
20.1 Lost devices
Many reported breaches involve lost or stolen unencrypted laptops; the lesson is encryption by default.
Bramley's own incident fits this pattern exactly: a laptop stolen from a car, unencrypted, holding tenant records. Aisha uses the pattern to argue that encryption should be the default on every laptop, not only on those known to hold tenant data. Gareth's decision in chapter 6 to encrypt every laptop follows the same lesson. Aisha uses this lesson in her board summary later, where the main message is that every laptop is now encrypted.
20.2 Patch delays
Nappa et al. (2015) found that shared code leaves vulnerable copies unpatched long after fixes; Li and Paxson (2017) found vulnerabilities often persist for years before fixes.
Aisha takes one general point from both papers: a fix being released does not mean it has reached every device. Bramley's own data show the same pattern on a small scale, with ten laptops taking over 30 days to install an update. She uses the papers to explain why the tail matters, not to predict Bramley's figures.
20.3 Misconfiguration
Dietrich et al. (2018) found operators link misconfigurations to time pressure and unclear responsibility.
Bramley shows both conditions Dietrich et al. (2018) describe. One IT officer handles all requests, so urgent changes happen quickly, and the old application server was left to the contractor without a clear owner. Aisha's response is a short checklist for urgent changes and a named owner for each server in the role documents. The checklist has four items: what is changing, who approved it, how to roll it back, and where the change is recorded.
20.4 Lessons for Bramley
Encrypt all laptops, measure patch tails, clarify responsibilities.
Each of the three lessons becomes a measure that Aisha can track month by month. Encrypting all laptops is tracked as laptops verified encrypted out of 45. Measuring patch tails is tracked as laptops over 30 days. Clarifying responsibilities is tracked through role documents that name an owner for each of the four servers. Each of the three lessons also has an owner, Gareth for all three, with the contractor responsible for the server role documents.
20.5 Using cases
Cases are used to learn, not to blame.
Aisha applies this rule to Bramley's own incident card as well as the public cases. The card describes what was lost and which controls were missing, without naming the staff member whose laptop was stolen. Staff respond by admitting they had also left laptops in cars, which would have been less likely if the card assigned blame. Each card also ends with an action staff can take, such as keeping laptops out of parked cars, so the discussion leads somewhere practical.
Turning cases into actions
Each lesson card links a public lesson to a Bramley action. Lost laptops: encryption on every device, verified monthly. Patch delays: measure the tail and investigate each late device. Misconfiguration under pressure: a short checklist for urgent changes and a clear owner for each server.
Aisha discusses the cards at a staff meeting. Staff find the lost-laptop card most relevant because of Bramley's own incident, and two staff admit they had left laptops in cars before. The discussion leads to a simple rule: laptops go home with staff or stay locked in the office, never in a parked car.
She avoids using cases to scare people. Each card ends with what staff can do, not what attackers might do.
Evaluating sources
Aisha notes that research papers like Li and Paxson (2017) describe large software ecosystems; their findings support the general point that fixes take time to reach users, but their numbers do not apply directly to Bramley.
Note
Each card is reviewed yearly.
Project log entry
Staff say the card about Bramley's own stolen laptop, which also records what has changed since, is the most persuasive, because they recognise the office, the people and the consequences, including the letters sent to affected tenants.
Worked example
Aisha writes three lesson cards for Bramley's staff, each with a plain example and action.
Synthetic case. Synthetic.
Errors and limits
Cases from large firms may not fit small charities directly.
Exercises
- EX058 — Lost device lesson. What lesson comes from lost-laptop cases? Rubric: 3 = encryption by default; 2 = partial; 1 = vague; 0 = none.
- EX059 — Nappa. What did Nappa et al. (2015) find? Rubric: 3 = shared code leaves copies unpatched; 2 = partial; 1 = vague; 0 = none.
- EX060 — Dietrich. What did Dietrich et al. (2018) find? Rubric: 3 = time pressure, unclear responsibility; 2 = partial; 1 = vague; 0 = none.
Synthesis
Learn from cases and adapt lessons to context.
Continue studying — chapter 20 of 40
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →