Chapter 21 — Critical infrastructure and sector security: requirements

Chapter 21 — Critical infrastructure and sector security: requirements

Lesson map

Lesson 21 published. Map, example, EX041.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["21.1 Sources of requirements"]
  N2["21.2 Requirements for degraded operation"]
  N3["21.3 Security levels and component requirements"]
  N4["21.4 Conflicts and negotiation"]
  N5["21.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX041"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["21.1 Sources of requirements"]
  N2["21.2 Requirements for degraded operation"]
  N3["21.3 Security levels and component requirements"]
  N4["21.4 Conflicts and negotiation"]
  N5["21.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX041"]

[Learning outcomes and connection]
    |
    v
[21.1 Sources of requirements]
    |
    v
[21.2 Requirements for degraded operation]
    |
    v
[21.3 Security levels and component requirements]
    |
    v
[21.4 Conflicts and negotiation]
    |
    v
[21.6 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX041]

Learning outcomes and connection

After this chapter you can (1) elicit security and resilience requirements from consequences, stakeholders, regulations and threat information; (2) write performance-based requirements for degraded operation, recovery and safety, not only for protection; (3) derive component requirements from system requirements using security levels; and (4) negotiate requirement conflicts explicitly. It applies Chapters 5 and 16 to the sector and prepares Chapter 22.

21.1 Sources of requirements

Infrastructure security requirements come from five sources, and a good set traces to all of them: consequences (what must never happen, and what must be restored how fast); stakeholders (operators, customers such as hospitals, emergency services, regulators); regulations and standards (e.g., AWIA risk assessments, NERC CIP, NIS2 risk-management measures); threat information (adversary capabilities documented in sources such as MITRE ATT&CK for ICS and CISA advisories); and constraints (legacy equipment, budget, staffing, safety certification).

21.2 Requirements for degraded operation

A system that is either "secure" or "compromised" is badly specified. Write requirements for the states in between: During loss of the telemetry network, each pumping station shall continue in local automatic control within its configured limits for at least 72 h. During suspected compromise of the SCADA servers, operators shall be able to run PS3 and PS4 in local manual mode with documented procedures and staffing within 1 h of the decision. After an incident, remote operation shall be restored within 8 h of the decision to restore, from verified offline backups. These are the requirements that keep people supplied.

21.3 Security levels and component requirements

IEC 62443-3-3 and 62443-4-2 express system and component requirements against security levels (SL 1–4) that reflect the capability of the adversary to be resisted, from casual or coincidental violation up to sophisticated, well-resourced attack (ISA/IEC 62443 series overview). The risk assessment for design (IEC 62443-3-2, catalogue page) partitions the system into zones and conduits and assigns a target level to each. A target level then becomes concrete component requirements — for example, authentication of all human users, or protection of communication integrity. The standard text is not freely available; cite clauses only from a copy you have lawfully obtained.

21.4 Conflicts and negotiation

Requirements conflict: fast operator access versus strong authentication; frequent patching versus availability; detailed logging versus storage at remote sites; vendor support versus network isolation. Do not resolve conflicts silently in design. Record each, its options, and the decision with its owner — usually the person who owns the operational risk.

TMRP's first recorded conflict is between R4's local manual mode and R1's authentication, resolved with a key switch, an alarm and a local log. The owner is operations, which carries the risk of slower manual access.

21.5 Worked example: TMRP requirement set v1.0 (synthetic)

Conflict recorded: R4's local manual mode creates a path that bypasses R1's authentication. Resolution: manual mode requires physical key-switch at the panel, is alarmed at SCADA, and is logged locally.

21.6 Practical activity

Choose one degraded state not yet covered (e.g., loss of the chlorine supplier for 7 days) and write a requirement, its source, and verification method.

Write the requirement in the same form as the TMRP table: an identifier, a single verifiable statement, its source and a verification method. A seven-day loss of chlorine supply, for example, might lead to a minimum on-site chemical stock with an inspection, and a procedure for an alternative supplier tested by exercise. Check that your requirement does not conflict with an existing one, and if it does, record the conflict and who should decide it.

21.7 Common errors and limits

• Requirements for protection only, none for degradation and recovery.
• Security levels assigned without a documented risk assessment.
• Citing standard clauses without access to the text.
• Conflicts resolved silently by whoever writes the design.
• Requirements that cannot be verified within the programme's means.

TMRP's set avoids the first error by including R4, R5 and R6 for degraded operation and recovery, and avoids the fourth by recording the local manual conflict openly. Every requirement in the set can be verified with the programme's own bench, trial or demonstration.

Exercises — chapter 21

EX041 — Degraded-state requirements. Objective: specify behaviour under stress. Inputs: LRWA, scenario "SCADA servers encrypted by ransomware". Steps: write three requirements covering continued service, detection/containment and restoration, each with source and verification. Expected evidence: table. Rubric: 3 = measurable, cover all three phases, realistic verification; 2 = one phase missing; 1 = protection only; 0 = none.

EX042 — Conflict record. Objective: document a conflict. Inputs: operators want the HMI to stay logged in all shift; R-new requires re-authentication after 15 min inactivity. Steps: write a conflict record with options, recommended resolution and owner. Expected evidence: record. Rubric: 3 = options include compensating controls (physical access control of the control room, view-only lock with quick re-auth for control actions), owner named by role; 2 = no owner; 1 = picks a side without options; 0 = none.

Chapter synthesis

Derive requirements from consequences, stakeholders, regulations, threats and constraints. Specify degraded operation and recovery as carefully as protection. Translate target security levels into concrete component requirements through a documented risk assessment, and record every conflict with options, decision and owner.

Continue studying — chapter 21 of 50

← Chapter 20 · Course chapter index · Chapter 22 →

Continue to the next authored lesson.