Chapter 15 — Security fundamentals
Lesson map
Lesson 15 published. Map, example, EX043.
flowchart TD
N0["Learning outcomes"]
N1["15.1 Goals"]
N2["15.2 Threats"]
N3["15.3 Principles"]
N4["15.4 Controls"]
N5["15.5 Risk"]
N6["Threats in plain words"]
N7["Measuring security"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX043"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["15.1 Goals"]
N2["15.2 Threats"]
N3["15.3 Principles"]
N4["15.4 Controls"]
N5["15.5 Risk"]
N6["Threats in plain words"]
N7["Measuring security"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX043"]
[Learning outcomes]
|
v
[15.1 Goals]
|
v
[15.2 Threats]
|
v
[15.3 Principles]
|
v
[15.4 Controls]
|
v
[15.5 Risk]
|
v
[Threats in plain words]
|
v
[Measuring security]
|
v
[Worked example] --> [Exercise EX043]
Learning outcomes
You will (1) apply confidentiality, integrity and availability to public PCs; (2) describe threats and vulnerabilities; (3) use security principles.
15.1 Goals
Confidentiality: patrons' data must not be left for others. Integrity: PCs must run only approved software and settings. Availability: PCs must be ready when the library opens.
Mateo writes each goal in terms librarians would recognise, then links it to the measure that shows whether it is met. The three can pull against each other: stricter controls may block a tool patrons need, and a long restore could delay opening. The design is judged on all three together, not on whichever is easiest to improve.
15.2 Threats
Threats include careless users, curious users, malicious software from websites or USB devices and equipment failures.
Most of Fernhill's actual problems came from the first two. Patrons forgot to sign out or installed something to make a game work, without any intent to harm. Malicious software was rarer in the records but more damaging when it appeared. Equipment failures cause no harm to data but leave patrons without a PC. Mateo's design addresses each, and he lists which control handles which threat.
15.3 Principles
Saltzer and Schroeder (1975) set out design principles including least privilege, fail-safe defaults and economy of mechanism. A public PC that resets to a minimal, locked image applies all three.
Mateo explains each principle with a library example. Least privilege is the standard account. Fail-safe defaults means a new USB device is blocked unless it is a keyboard or mouse. Economy of mechanism means one image and one restore process for every public PC, which is easier to check than many custom setups.
15.4 Controls
CIS Controls v8 groups safeguards such as inventory, secure configuration and data recovery, each relevant to the project.
Mateo uses the controls as a checklist rather than a target. Inventory comes first because Fernhill cannot protect PCs it does not know about. Secure configuration is the golden image. Data recovery is the nightly restore, used here to remove patron data rather than to recover lost files. Safeguards that do not fit a public PC are noted as not applicable, with a reason.
15.5 Risk
Risk combines likelihood and impact; chapter 23 ranks scenarios.
Mateo uses a simple scale for both parts at first, with three levels each, so that librarians and managers can join the discussion. A leftover bank statement is fairly likely and serious for the patron; a failed restore is likely but minor if caught at the morning check. The ranking shows where to spend effort first. More careful methods come later, once the scenarios are written out and measured. Each ranking is dated.
Threats in plain words
Mateo explains threats to librarians without technical detail: some patrons try to install games or toolbars; some websites offer harmful downloads; USB sticks can carry malicious files; and equipment sometimes fails. Each threat links to a control in the design. This helps librarians understand why some restrictions exist and makes them allies rather than critics.
He avoids describing how attacks work and focuses on what the controls do.
Measuring security
Each goal has a measure: leftover files found, unapproved programs blocked and PCs ready at opening.
Linking goals to requirements
Each goal is later linked to requirements in chapter 21, so every requirement can be traced back to a security goal and forward to evidence.
Residual risk
No design removes all risk. A patron could still photograph a screen or misuse a website; these are outside what PC controls can address.
Worked example
Mateo maps each Saltzer and Schroeder principle to a design feature: least privilege (standard users), fail-safe defaults (USB storage blocked by default), economy of mechanism (one image for all public PCs).
Synthetic case. Synthetic.
Errors and limits
Principles guide design but do not replace testing.
Exercises
- EX043 — Three goals. Apply the three goals to public PCs. Rubric: 3 = data not left, approved software only, ready at opening; 2 = two; 1 = one; 0 = none.
- EX044 — Principles. Map three principles to features. Rubric: 3 = least privilege, fail-safe, economy; 2 = two; 1 = one; 0 = none.
- EX045 — CIS Controls. Name three relevant CIS Controls areas. Rubric: 3 = inventory, secure configuration, data recovery; 2 = two; 1 = one; 0 = none.
Synthesis
Classic principles map directly onto a hardened public PC design.
Continue studying — chapter 15 of 50
← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →