◇ OpenCyber Academy
Engineering · Chapter 21 · English

Chapter 21 — Network and communications security: requirements

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 — Network and communications security: requirements

Lesson map

Lesson 21 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["21.1 Security requirements"]
  N2["21.2 Operational requirements"]
  N3["21.3 Prioritisation"]
  N4["21.4 Verification methods"]
  N5["Requirement quality checks"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["21.1 Security requirements"]
  N2["21.2 Operational requirements"]
  N3["21.3 Prioritisation"]
  N4["21.4 Verification methods"]
  N5["Requirement quality checks"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX061"]

[Learning outcomes]
    |
    v
[21.1 Security requirements]
    |
    v
[21.2 Operational requirements]
    |
    v
[21.3 Prioritisation]
    |
    v
[21.4 Verification methods]
    |
    v
[Requirement quality checks]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) write security and operational requirements; (2) prioritise them; (3) assign verification methods.

21.1 Security requirements

Kofi writes requirements such as: R1 guest devices cannot initiate connections to internal zones; R2 traffic between zones is denied unless explicitly permitted; R3 device management is only possible from the management zone via an authenticated jump host; R4 inter-office VPNs use IKEv2 with certificate authentication; R7 CCTV cameras can reach only the video recorder.

Each security requirement is linked to the threat it addresses and the test that will verify it.

Vague wording is replaced with testable statements before review.

21.2 Operational requirements

Others address operations: R5 firewall and VPN logs are retained for ninety days; R6 VPN failover completes within sixty seconds; R8 device configurations are backed up daily. Operational requirements are often forgotten in security designs but determine whether the design survives contact with daily work.

Operational requirements cover what staff need to run the network: monitoring, change procedures, backup of configurations, and acceptable maintenance windows. They matter because a secure design that operators cannot manage will drift back to an insecure state.

21.3 Prioritisation

Requirements are ranked as must, should or could, with stakeholders. Must requirements are those tied to the guest incident and supplier access; could requirements include finer segmentation of staff by department, deferred to a later phase.

Not all requirements can be met at once, so engineers rank them. Common methods label each as must, should or could, based on risk reduction, legal need and cost. Ranking is agreed with the council, so if time or budget runs short, the least important work is dropped first, rather than whatever happens to be last.

21.4 Verification methods

Each requirement has a verification method: test, inspection, analysis or demonstration. R1 is verified by test, R4 by inspection of configuration, R6 by a failover test.

Each requirement is verified by one of four methods: inspection of configuration or documents, analysis such as a reachability model, demonstration in normal use, or a test with defined inputs and expected results. Choosing the method when writing the requirement makes sure it is checkable, and recording the result as evidence closes the loop between promise and proof.

Requirement quality checks

Kofi checks each requirement against simple quality rules: it states one thing, is testable, avoids describing a solution where a need will do, and has a named owner. R2, for example, originally said that a particular firewall model would block traffic between zones; he rewrote it to describe the behaviour, so that the requirement survives a change of equipment. A peer reviews the set using the same rules, and two requirements are split because each combined two separate needs that would be verified differently.

Worked example

The requirements table has eight rows with ID, text, priority, owner and verification method.

Synthetic case. Requirements are synthetic.

Errors and limits

Requirements without verification methods often turn out to be untestable late in the project.

Exercises

Synthesis

Clear, prioritised requirements with verification methods anchor design and testing.

Continue studying — chapter 21 of 50

← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →