Chapter 28 — Identity and access management: failure analysis
Lesson map
Lesson 28 published. Map, example, EX082.
flowchart TD
N0["Learning outcomes"]
N1["28.1 Lost and broken keys"]
N2["28.2 Provider outages"]
N3["28.3 Near misses"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX082"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["28.1 Lost and broken keys"]
N2["28.2 Provider outages"]
N3["28.3 Near misses"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX082"]
[Learning outcomes]
|
v
[28.1 Lost and broken keys]
|
v
[28.2 Provider outages]
|
v
[28.3 Near misses]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX082]
Learning outcomes
You will (1) analyse what happens when identity controls fail; (2) plan for lost keys and outages; (3) learn from near misses.
28.1 Lost and broken keys
Security keys get lost. If an operative loses a key and cannot sign in, work stops. Elena designs a recovery process: the operative calls the service desk, who verify identity by calling back the manager on a known number, issue a spare key and revoke the lost one. Each operative also registers a second key kept at the depot. NIST SP 800-63B-4 treats loss and recovery as part of authenticator management, and a weak recovery step would undo the protection keys provide.
28.2 Provider outages
If the office suite provider is unavailable, staff cannot sign in to connected systems. Elena checks the provider's published service status history and finds rare but real outages. She plans what Greenhill does: emergency tenant contact numbers are kept on paper at reception, the repairs team has a printed list of the day's jobs each morning, and one emergency administrator account with a key in the safe can be used if the IT lead's normal access fails. These simple steps limit harm without adding complexity.
28.3 Near misses
A near miss is a failure that almost caused harm. During rollout, a group rule briefly removed housing officers from the housing system for twenty minutes because a group was renamed. Nobody was hurt, but tenant calls were delayed. Elena records the near miss without blame, identifies the cause, a rename not tested first, and adds a test for group renames. Learning from near misses is cheaper than learning from real incidents and builds a culture where people report problems early.
Worked example
A twenty-minute housing access near miss from an untested group rename leads to a new test; lost-key recovery uses manager call-back and spare keys.
Synthetic case. Events and processes are synthetic; NIST SP 800-63B-4 is a real source.
Errors and limits
Recovering lost keys with weak checks, such as a caller simply giving their name, undoes the protection keys provide.
Exercises
- EX082 — Lost key verification. How does the desk verify an operative who lost a key? Rubric: 3 = call back the manager on a known number;; 2 = call-back;; 1 = name only;; 0 = none.
- EX083 — Outage preparation. Name one outage arrangement Elena plans. Rubric: 3 = paper emergency contacts, printed job lists, safe-stored emergency admin key (one);; 2 = one;; 1 = vague;; 0 = none.
- EX084 — Near miss cause. What caused the housing access near miss? Rubric: 3 = an untested group rename;; 2 = rename;; 1 = attack;; 0 = none.
Synthesis
Planned recovery, outage arrangements and learning from near misses make identity controls resilient.
Continue studying — chapter 28 of 40
← Chapter 27 (draft) · Course chapter index · Chapter 29 (draft) →