Chapter 21 — Information security: requirements | Engineering Information security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 21 — Information security: requirements

Lesson map

Lesson 21 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["21.1 Sources of requirements"]
  N2["21.2 Testable wording"]
  N3["21.3 Prioritising"]
  N4["21.4 Conflicts"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["21.1 Sources of requirements"]
  N2["21.2 Testable wording"]
  N3["21.3 Prioritising"]
  N4["21.4 Conflicts"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]

[Learning outcomes]
    |
    v
[21.1 Sources of requirements]
    |
    v
[21.2 Testable wording]
    |
    v
[21.3 Prioritising]
    |
    v
[21.4 Conflicts]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) derive security requirements from risks and obligations; (2) write testable requirements; (3) prioritise requirements by impact.

21.1 Sources of requirements

Lindiwe gathers Saltmarsh's security requirements from several sources: risk assessments, customer contracts, data protection law, insurance conditions and the management system scope. A large retail customer requires suppliers to use multi-factor authentication for remote access and to report incidents within twenty-four hours. The insurer requires tested offline backups. She records each requirement with its source, so later readers know why it exists and whether it can change if the source changes, for example when a contract ends. She keeps the list in a shared register.

21.2 Testable wording

Many requirements arrive vague, such as systems must be secure. Lindiwe rewrites them so a test can show pass or fail: remote access to internal systems requires a second factor; server disks are encrypted; security patches rated critical are applied within fourteen days. Prof. Hale asks her to avoid words like adequate and appropriate unless a measurable threshold follows. She learns that testable requirements are the bridge between policy and verification, which later chapters depend on. Each rewritten requirement names its owner as well.

21.3 Prioritising

Not every requirement matters equally. Lindiwe ranks them by the impact of failure, using the FIPS 199 categories from earlier: requirements protecting high-impact systems such as payroll and dispatch come first. Requirements imposed by contracts with penalties also rank high. She produces a list of twenty requirements in three priority bands. The security lead uses it to plan the year's work, accepting that lower-band items may wait while high-band gaps are fixed. She marks each requirement with its band and source in the register, so the plan can be traced back to the reasons behind it.

21.4 Conflicts

Requirements sometimes conflict. The retail customer wants detailed logs kept for a year; data protection principles push towards keeping personal data only as long as necessary. Lindiwe proposes keeping security logs for a year with access restricted to the security team and personal fields minimised where possible. Prof. Hale notes that resolving conflicts openly, with reasons recorded, is better than letting one team quietly ignore a requirement it finds inconvenient. The data protection officer and the security lead both sign the agreed approach, and Lindiwe records it in the decision log with a review date.

Worked example

Lindiwe collects requirements from risks, contracts, law and insurance, rewrites them as testable statements, ranks them in three bands and resolves a retention conflict.

Synthetic case. Requirements are synthetic.

Errors and limits

A requirement without a measurable threshold cannot be verified.

Exercises

EX061 — Customer demands. What does the retail customer require? Rubric: 3 = MFA for remote access and 24-hour incident reports;; 2 = partly correct;; 1 = vague;; 0 = none.
EX062 — Patch requirement. How quickly must critical patches be applied? Rubric: 3 = within fourteen days;; 2 = partly correct;; 1 = wrong;; 0 = none.
EX063 — Retention conflict. How is the log retention conflict resolved? Rubric: 3 = a year with restricted access and minimised fields;; 2 = partly correct;; 1 = vague;; 0 = none.

Continue studying — lesson 21 (chapter 21 of 50)

← Chapter 20 · Course chapter index · Chapter 22 →

Continue to the next authored lesson.