Chapter 21 — Security architecture and engineering: requirements
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Verifiable requirements"]
N2["21.2 Abuse cases"]
N3["21.3 Selecting controls"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 Verifiable requirements"]
N2["21.2 Abuse cases"]
N3["21.3 Selecting controls"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 Verifiable requirements]
|
v
[21.2 Abuse cases]
|
v
[21.3 Selecting controls]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) write verifiable security requirements; (2) derive requirements from protection needs and abuse cases; (3) select controls from catalogues with justification.
21.1 Verifiable requirements
A requirement such as the system shall be secure cannot be verified. Sofia learns to write requirements that can be tested: refund approvals above fifty euros shall require a second approver distinct from the requester; tap records shall be signed by the validator and rejected by the back office if the signature fails; administrative access shall require multi-factor authentication. Each requirement names who or what, the condition and the expected behaviour. She adds a verification method to each, such as test, inspection or analysis, so that the team knows from the start how compliance will be shown.
21.2 Abuse cases
Use cases describe what legitimate users do; abuse cases describe what attackers or careless insiders might do. Sofia writes abuse cases for the back office: a fraudster replays signed tap records to create fake journeys for refund claims; an insider exports journey histories to sell; a compromised vendor account pushes a malicious tariff table. Each abuse case leads to requirements, such as replay detection with unique record identifiers, export logging and approval, and signed tariff tables verified before use. Abuse cases make requirements concrete and help stakeholders understand why each exists.
21.3 Selecting controls
NIST SP 800-53 Rev. 5 provides a catalogue of controls; ISO/IEC 27002:2022 provides another. Sofia uses them to check her requirements for gaps rather than copying them wholesale. For example, the catalogue's audit and accountability family reminds her to require log protection and review, which she had missed. For each selected control she records the requirement it supports and the reason. Selecting controls with justification avoids both gaps and bloated designs that implement controls nobody needs, consuming budget that could address real risks.
Worked example
Sofia writes twelve verifiable requirements with verification methods, three abuse cases with derived requirements and uses SP 800-53 Rev. 5 to find a missing log-review requirement.
Synthetic case. Requirements and abuse cases are synthetic; SP 800-53 Rev. 5 and ISO/IEC 27002:2022 are real.
Errors and limits
Requirements can conflict, such as logging versus privacy. Catalogues are broad; tailoring requires judgement.
Exercises
- EX061 — Verifiable rewrite. Rewrite the system shall be secure as a verifiable requirement for refunds. Rubric: 3 = refunds above 50 euros require a second approver distinct from the requester, verified by test;; 2 = verifiable;; 1 = vague;; 0 = none.
- EX062 — Abuse case derivation. Which requirement follows from the replayed tap record abuse case? Rubric: 3 = unique record identifiers with replay detection;; 2 = replay detection;; 1 = vague;; 0 = none.
- EX063 — Catalogue use. How did Sofia use SP 800-53 Rev. 5? Rubric: 3 = to check for gaps, finding a missing log protection and review requirement;; 2 = gap check;; 1 = copied all;; 0 = none.
Synthesis
Good security requirements are verifiable, grounded in abuse cases and checked against catalogues with justification.
Continue studying — chapter 21 of 50
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →