Chapter 26 — Incident response for identity | Technologist 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 26 — Incident response for identity

Lesson map

Lesson 26 published. Map, example, EX076.

flowchart TD
  N0["Learning outcomes"]
  N1["26.1 Recognising incidents"]
  N2["26.2 First steps"]
  N3["26.3 Learning"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX076"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["26.1 Recognising incidents"]
  N2["26.2 First steps"]
  N3["26.3 Learning"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX076"]

[Learning outcomes]
    |
    v
[26.1 Recognising incidents]
    |
    v
[26.2 First steps]
    |
    v
[26.3 Learning]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX076]

Learning outcomes

You will (1) recognise identity incidents; (2) take first containment steps; (3) record and learn.

26.1 Recognising incidents

An identity incident is any event where an account may be used by the wrong person or access is wrong in a way that matters: a staff member reporting an unexpected MFA prompt, a sign-in from an unusual country, or someone seeing records they should not. Kai writes a short guide describing these signs for staff and asks them to report quickly, explaining that early reports cost nothing and late ones can cost a great deal. The guide is short enough to fit on one page.

26.2 First steps

Kai's first-steps card for IT says: confirm with the staff member; if their account may be misused, sign out all sessions, reset authenticators through the recovery process and review recent activity; if access was simply wrong, correct the group membership and check what was viewed. The practice manager is informed in every case and decides whether data protection reporting is needed. The card focuses on protecting accounts and data, not on investigating anyone. The card is kept beside the IT desk and in the runbooks. It is tested in a short exercise.

26.3 Learning

After each incident, Kai records what happened, how it was found, what was done and what would prevent a repeat. In the first year there are three incidents: an MFA prompt a nurse did not request, which she rejected and reported; a misdirected group change; and a lost unlocked tablet. Each leads to a small improvement, such as number matching on MFA prompts. Recording lessons turns incidents into improvements. Kai shares each lesson with staff briefly, without naming anyone. Staff report more quickly afterwards, which he notes in the metrics.

Worked example

Three identity incidents in a year each lead to an improvement, including number matching for MFA prompts.

Synthetic case. Incidents are synthetic.

Errors and limits

Discouraging reports by blaming staff delays discovery of real incidents.

Exercises

EX076 — Incident sign. Name one sign of an identity incident. Rubric: 3 = unexpected MFA prompt;; 2 = prompt;; 1 = slow PC;; 0 = none.
EX077 — Who decides reporting. Who decides on data protection reporting? Rubric: 3 = practice manager;; 2 = manager;; 1 = IT;; 0 = none.
EX078 — MFA improvement. What MFA improvement followed? Rubric: 3 = number matching;; 2 = matching;; 1 = SMS;; 0 = none.

Synthesis

Clear signs, first-step cards and recorded lessons make identity incidents manageable.

Continue studying — chapter 26 of 30

← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →