Chapter 21 — Identity and access management: requirements | Engineering Identity and access management

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 — Identity and access management: requirements

Lesson map

Lesson 21 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["21.1 Security requirements"]
  N2["21.2 Lifecycle requirements"]
  N3["21.3 Operational requirements"]
  N4["21.4 Prioritisation"]
  N5["21.5 Verification methods"]
  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 Lifecycle requirements"]
  N3["21.3 Operational requirements"]
  N4["21.4 Prioritisation"]
  N5["21.5 Verification methods"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX061"]

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

Learning outcomes

You will (1) write security, lifecycle and operational requirements for identity; (2) prioritise them with the council; (3) choose a verification method for each.

21.1 Security requirements

Sana writes security requirements that can be tested. Examples: all staff sign-ins to integrated applications must use multi-factor authentication; administrators must use phishing-resistant authenticators as described in NIST SP 800-63B-4; tokens must expire within one hour and refresh only while the session is valid; no account may hold permissions that break a defined separation-of-duties rule. Each requirement names the threat it addresses from the threat table, so reviewers can see why it exists, and each avoids naming a product, leaving the design free to choose the best way to meet it.

21.2 Lifecycle requirements

Lifecycle requirements cover joiners, movers and leavers. A joiner must have access to their role's standard applications on their first day; a mover's old role access must be removed within five working days of the change; a leaver's access to every integrated application must be removed within four working hours of their HR end date. These numbers come from council policy and audit findings, discussed with HR and service owners. They are ambitious compared with the baseline of nineteen days, which is exactly why they need clear verification and regular measurement after rollout.

21.3 Operational requirements

Operational requirements describe what the identity team needs to run the system: monitoring of sign-in success and provider health, documented runbooks, backups of configuration, a test tenant that mirrors production, and a maintenance window for changes. They also cover the service desk: agents must be able to verify a caller's identity using a defined procedure before any reset or recovery. Operational requirements matter because a secure design the small team cannot operate will drift back to insecure habits within months of the project ending.

21.4 Prioritisation

Not everything can be delivered at once, so Sana and the council rank requirements as must, should or could, using risk reduction, legal duty and cost. Leaver removal and administrator authentication are musts, because audit findings and threat ranking put them highest. Self-service group requests are a could. Agreeing the ranking in a workshop with directors means that if time or budget runs short, the least important work is dropped first by decision, rather than whatever happens to be scheduled last being quietly abandoned.

21.5 Verification methods

Each requirement is verified by inspection, analysis, demonstration or test. Token lifetime is verified by inspecting configuration and testing a token after expiry; leaver removal by measuring time from HR date to removal across real cases; separation of duties by analysing all role assignments with a script. Choosing the method when writing the requirement makes sure it is checkable. The verification results become evidence in the dossier that Sana assembles at the end of the project for the council and her examiners.

Worked example

Sana's 60 requirements are ranked 22 must, 26 should and 12 could, each with a threat link, a source and a verification method recorded in the traceability matrix.

Synthetic case. Requirements and rankings are synthetic.

Errors and limits

Requirements without numbers, such as remove leavers promptly, cannot be verified and invite disagreement later.

Exercises

EX061 — Leaver target. What is the leaver removal requirement? Rubric: 3 = all integrated apps within four working hours of HR end date;; 2 = four hours;; 1 = 19 days;; 0 = none.
EX062 — Must examples. Which requirements are ranked must? Rubric: 3 = leaver removal and administrator authentication;; 2 = one;; 1 = self-service;; 0 = none.
EX063 — SoD verification. How is separation of duties verified? Rubric: 3 = analysing all role assignments with a script;; 2 = analysis;; 1 = interview;; 0 = none.

Synthesis

Testable, prioritised requirements with chosen verification methods turn audit findings into an achievable programme.

Continue studying — chapter 21 of 50

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