Chapter 21 — Systems, endpoints and hardware security: requirements
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 From objectives to requirements"]
N2["21.2 Boot integrity"]
N3["21.3 Operations"]
N4["21.4 Accessibility"]
N5["21.5 Priorities"]
N6["Requirement attributes"]
N7["Avoiding solution bias"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 From objectives to requirements"]
N2["21.2 Boot integrity"]
N3["21.3 Operations"]
N4["21.4 Accessibility"]
N5["21.5 Priorities"]
N6["Requirement attributes"]
N7["Avoiding solution bias"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 From objectives to requirements]
|
v
[21.2 Boot integrity]
|
v
[21.3 Operations]
|
v
[21.4 Accessibility]
|
v
[21.5 Priorities]
|
v
[Requirement attributes]
|
v
[Avoiding solution bias]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) write security requirements from objectives; (2) make them testable; (3) prioritise them.
21.1 From objectives to requirements
Each objective yields requirements. O1 yields R4 nightly restore of the patron area and R8 staff disk encryption. O2 yields R5 application control in enforce mode and R3 USB storage blocked.
Mateo works through each objective and asks what must be true for it to be met. The links run both ways: every requirement names its objective, and every objective has at least one requirement. A requirement that serves no objective is questioned before it is kept. Marta reviews the full list with him.
21.2 Boot integrity
R1 Secure Boot enabled and R2 firmware password set protect the restore mechanism itself.
These two come first in the numbering because everything else depends on them. If the firmware or boot order could be changed, an altered system could start in place of the approved one, and the nightly restore might never run or might run from a tampered copy. Mateo writes them as outcomes that a script can check on every PC: Secure Boot reports as on, and the firmware reports that a password is set. Both checks run daily.
21.3 Operations
R6 automatic logoff after 15 minutes idle; R7 remote logging of security events; R9 alert on restore failure.
Each of these keeps the system working day to day. The idle logoff closes sessions that patrons forget, which is a common route by which files are left for the next person. Remote logging means events survive the nightly restore. The restore alert lets staff fix a failed PC before opening. Mateo chose fifteen minutes after watching how long patrons typically step away to collect printing or ask a question at the desk.
21.4 Accessibility
R10 approved accessibility tools available on every PC.
The approved set includes a screen reader, a magnifier and an on-screen keyboard, chosen with patrons who use them and with the librarian who supports them. Each tool must start without staff help, which the worked example added after review. The requirement is tested on every release, since application control or a new image setting could block a tool by accident. Failing this test blocks the release just as a security failure would.
21.5 Priorities
R1, R4 and R5 are must-haves; R9 and R10 are must-haves for safe operation and fairness.
Must-have means a release cannot go to branches without the requirement met. Mateo lists the remaining requirements as important but allowed to lag briefly with a recorded plan, such as remote logging during a supplier change. Treating accessibility and the restore alert as must-haves reflects ethics as well as engineering: a design that excludes some patrons, or fails silently, is not acceptable however secure it is.
Requirement attributes
Each requirement has an identifier, statement, source objective, priority, verification method and owner. For example, R4: the patron area is restored to the golden state every night; source O1; must-have; verified by test; owner Marta. Recording attributes makes later traceability simple and lets anyone see why a requirement exists.
Requirements are reviewed with stakeholders before design starts, and any change later needs a recorded reason.
Avoiding solution bias
Mateo phrases requirements as outcomes, not products, so different solutions can be compared in chapter 26.
Reviewing requirements
Requirements are reviewed again after the studio in chapter 25, when patron guidance about saving work is added as a new requirement linked to O1 and O3.
Traceability start
A traceability table links each requirement to its objective now, and later to design, tests and evidence. Starting it early is much easier than building it at the end.
Worked example
Mateo reviews the ten requirements with Marta and a librarian. The librarian adds that the accessibility reader must be available without staff help, refining R10.
Synthetic case. Synthetic.
Errors and limits
Requirements written only by engineers often miss user needs.
Exercises
- EX061 — Boot requirements. Which requirements protect boot? Rubric: 3 = R1 Secure Boot, R2 firmware password; 2 = partial; 1 = vague; 0 = none.
- EX062 — O2 requirements. Which requirements implement O2? Rubric: 3 = R5 app control, R3 USB block; 2 = partial; 1 = vague; 0 = none.
- EX063 — R10 refinement. How was R10 refined? Rubric: 3 = reader available without staff help; 2 = partial; 1 = vague; 0 = none.
Synthesis
Testable requirements trace back to objectives and users.
Continue studying — chapter 21 of 50
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →