Chapter 20 — Systems, endpoints and hardware security: engineering context
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 Context"]
N2["20.2 Stakeholders"]
N3["20.3 Constraints"]
N4["20.4 Objectives"]
N5["20.5 Standards context"]
N6["Success measures"]
N7["Project risks"]
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 Context"]
N2["20.2 Stakeholders"]
N3["20.3 Constraints"]
N4["20.4 Objectives"]
N5["20.5 Standards context"]
N6["Success measures"]
N7["Project risks"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 Context]
|
v
[20.2 Stakeholders]
|
v
[20.3 Constraints]
|
v
[20.4 Objectives]
|
v
[20.5 Standards context]
|
v
[Success measures]
|
v
[Project risks]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) describe the public PC service as an engineering problem; (2) identify stakeholders and constraints; (3) set project objectives.
20.1 Context
Fernhill's 300 public PCs serve about 2,000 sessions a day. Staff are librarians, not IT specialists. The IT team is Marta and one technician. Budget is limited.
These facts shape every choice. Two thousand sessions a day means the PCs must be ready and reliable, since a queue forms quickly when several are down. A small IT team means designs must run themselves and report clearly. Librarians need to understand what the PCs do without technical training. A limited budget favours reusing existing hardware and standard tools.
20.2 Stakeholders
Patrons want working, private PCs. Librarians want fewer problems to handle. Marta wants less manual work. The board wants cost control and no data incidents.
Mateo interviewed members of each group and recorded what they said in their own words. Patrons mostly wanted PCs that work and do not show other people's files. Librarians wanted fewer interruptions. The board's questions were about cost and reputation. The interviews also revealed that some patrons valued keeping files between sessions, which the design cannot offer, so the notices explain alternatives.
20.3 Constraints
Existing hardware must be reused; changes must not disrupt opening hours; accessibility tools must work.
Each constraint rules out options. Reusing hardware excludes designs that need new devices. Avoiding disruption means changes happen overnight or at one branch first. Accessibility tools must keep working, which shapes the allowlist. Mateo lists the constraints at the front of the requirements so that reviewers can check a proposed design against them before considering anything else. Marta added one more constraint: changes must be explainable to librarians in a single short briefing.
20.4 Objectives
O1: no patron data persists beyond one day. O2: only approved software runs. O3: PCs are ready at opening. O4: manual effort falls.
Each objective is short enough to remember and points to a measure. Mateo checked them with Marta and the board's representative. The first draft included an objective to make the PCs secure, which was dropped as unmeasurable; the four that remain can each be checked against data the project already collects. Each objective has a named owner who reports on it quarterly.
20.5 Standards context
The design draws on CIS Benchmarks, Microsoft security baselines, NIST SP 800-123 and SP 800-40r4.
Mateo uses these as references rather than recipes. The baselines provide tested settings; SP 800-123 provides principles for keeping systems minimal; SP 800-40r4 guides patch planning. Where a recommended setting conflicts with a library need, such as accessibility, he records the deviation with its reason and a compensating control. Each reference is listed with the version used. Deviations are reviewed with Marta each year, and removed when the underlying need disappears.
Success measures
Each objective gets a measure: O1, leftover files found in spot checks; O2, unapproved programs executed; O3, PCs out of service at opening; O4, staff hours spent on PC problems per month. Baselines are collected for a month before changes, so improvement can be shown later.
The baseline month shows 42 PC failures needing manual repair, 31 leftover-file reports and about 60 staff hours on PC issues.
Project risks
Main risks are staff time, hardware age and patron acceptance of restrictions.
Constraints shaping design
Reusing existing hardware rules out designs needing new devices this year, which later shapes the choice in chapter 26. Accessibility constraints shape the allowlist approach in chapter 31. Recording constraints early prevents designs that cannot be used.
Baseline evidence
The baseline month's figures are stored with collection dates for later comparison in chapters 32 and 42.
Worked example
Marta asks whether O4 conflicts with security. Mateo shows that automation of restore and updates serves both: less manual work and more consistent security.
Synthetic case. Synthetic.
Errors and limits
Objectives that are not measurable cannot be verified.
Exercises
- EX058 — Constraints. List the three constraints. Rubric: 3 = reuse hardware, no disruption, accessibility; 2 = two; 1 = one; 0 = none.
- EX059 — Objectives. State the four objectives. Rubric: 3 = no data beyond a day, approved software, ready at opening, less manual effort; 2 = three; 1 = two; 0 = none.
- EX060 — O4 reconciliation. How does automation serve both security and effort? Rubric: 3 = consistent and less manual; 2 = partial; 1 = vague; 0 = none.
Synthesis
Clear objectives frame the engineering work.
Continue studying — chapter 20 of 50
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →