Chapter 23 — Network and communications security: methods I | Bachelor's Network and communications 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 23 — Network and communications security: methods I

Lesson map

Lesson 23 published. Map, example, EX067.

flowchart TD
  N0["Learning outcomes"]
  N1["23.1 Requirements from needs"]
  N2["23.2 Threat analysis"]
  N3["23.3 Prioritising"]
  N4["23.4 Assumptions"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX067"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["23.1 Requirements from needs"]
  N2["23.2 Threat analysis"]
  N3["23.3 Prioritising"]
  N4["23.4 Assumptions"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX067"]

[Learning outcomes]
    |
    v
[23.1 Requirements from needs]
    |
    v
[23.2 Threat analysis]
    |
    v
[23.3 Prioritising]
    |
    v
[23.4 Assumptions]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX067]

Learning outcomes

You will (1) gather requirements; (2) analyse threats systematically; (3) prioritise controls.

23.1 Requirements from needs

Priya turns clinic needs into security requirements that can be tested. Each requirement states what must be true, not how to achieve it. Her list includes: R1, guest devices cannot reach staff, clinical or management groups; R2, inter-group traffic is denied unless listed as a needed flow; R3, network devices are managed only from the management zone; R4, staff wireless uses individual accounts; R5, clinic services use TLS 1.2 or later; and R6, logs are kept centrally for ninety days. Numbering requirements lets later tests and evidence refer to them exactly.

23.2 Threat analysis

A systematic threat analysis asks, for each group and boundary, what could go wrong. Priya walks through the model: an infected visitor phone attempting to reach clinical carts; a former staff member using the shared passphrase from the car park; a supplier's forgotten remote access; an attacker intercepting lab results over an old protocol; a misconfigured rule opening guest to management. For each threat she notes which requirement addresses it. Threats with no matching requirement reveal gaps in the requirement list.

23.3 Prioritising

Not everything can be done at once. Priya rates each threat by likelihood and impact using the simple scale from chapter 5, then orders controls by how much risk they remove for their cost. Separating the guest network removes the most risk cheaply and comes first. Individual staff accounts come second. TLS upgrades for lab results come third because they protect sensitive data but depend on the supplier. Central logging is started early because it supports evidence for everything else. She explains the order to managers in one page.

23.4 Assumptions

Every analysis rests on assumptions, and stating them lets others check them. Priya assumes the clinics' internet provider links are reliable, that the booking service provider secures its own systems, and that clinical carts cannot be modified by staff. If any assumption is wrong, the priorities might change. She lists them in the design document and asks the IT lead to confirm or correct each one. One assumption proves false: some carts do allow staff to install apps, which raises the risk of infected carts.

Worked example

The threat table maps five threats to six requirements; the false assumption about carts raises one threat from medium to high.

Synthetic case. The analysis is synthetic.

Errors and limits

Requirements written as solutions, such as "buy a firewall", cannot be tested and limit design options.

Exercises

EX067 — Requirement form. Rewrite "install a firewall" as a testable requirement. Rubric: 3 = states outcome such as inter-group traffic denied unless listed;; 2 = outcome;; 1 = keeps solution;; 0 = none.
EX068 — Gap detection. How does threat analysis reveal missing requirements? Rubric: 3 = threats without matching requirement;; 2 = unmatched threats;; 1 = vague;; 0 = none.
EX069 — False assumption effect. What changed when the cart assumption proved false? Rubric: 3 = infected cart risk raised; priorities revisited;; 2 = risk up;; 1 = vague;; 0 = none.

Synthesis

Testable requirements, systematic threat analysis and stated assumptions guide prioritised controls.

Continue studying — chapter 23 of 40

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