Chapter 7 — Alert triage for identity events | Professional 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 7 — Alert triage for identity events

Lesson map

Lesson 07 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["7.1 The alerts"]
  N2["7.2 Triage steps"]
  N3["7.3 Escalating"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["7.1 The alerts"]
  N2["7.2 Triage steps"]
  N3["7.3 Escalating"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX031"]

[Learning outcomes]
    |
    v
[7.1 The alerts]
    |
    v
[7.2 Triage steps]
    |
    v
[7.3 Escalating]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) triage identity alerts; (2) separate benign from concerning events; (3) escalate with evidence.

7.1 The alerts

The firm's directory raises alerts for risky sign-ins, such as impossible travel, unfamiliar locations, repeated failures and sign-ins from anonymising networks. Daniel reviews a month of alerts: 46 in total. Many are benign, such as staff using a mobile network that appears in another city. Helen teaches him that triage is about deciding quickly which alerts need action, using evidence available in the logs and a short conversation, not about investigating every alert in depth. Daniel records the month's alert types in a short table.

7.2 Triage steps

For each alert Daniel checks: was the sign-in successful; was multi-factor authentication completed and by which method; is the device known; does the person confirm it was them? A failed attempt blocked by multi-factor authentication on a known person is low concern. A successful sign-in from an unknown device that the person denies is high concern and escalated at once. He records the outcome of each alert, building a picture of what is normal for the firm. Helen reviews his first twenty decisions.

7.3 Escalating

Of the 46 alerts, 41 are benign, four are failed attempts blocked by multi-factor authentication and one is a successful sign-in to an administrator's mailbox from an unfamiliar device that she does not recognise. Daniel escalates to Helen and the managing partner with the log entries, sessions are revoked, her authenticators are re-registered through the recovery process and mailbox rules are checked. Escalation with clear evidence lets decision-makers act within minutes. Afterwards he writes a short note of the timeline and what was done, which Helen reviews before it is filed with the evidence.

Worked example

Of 46 alerts in a month, 41 are benign, 4 are blocked attempts and 1 successful unrecognised sign-in is escalated and contained.

Synthetic case. Alerts and events are synthetic.

Errors and limits

Investigating every alert in depth exhausts time needed for the few that matter.

Exercises

EX031 — Alert total. How many alerts were reviewed? Rubric: 3 = 46;; 2 = forty-six;; 1 = 41;; 0 = none.
EX032 — Triage question. Name one triage check. Rubric: 3 = was MFA completed;; 2 = device known;; 1 = colour;; 0 = none.
EX033 — Low concern. What is low concern? Rubric: 3 = failed attempt blocked by MFA on a known person;; 2 = blocked;; 1 = success;; 0 = none.
EX034 — Escalated event. What was escalated? Rubric: 3 = successful unrecognised sign-in to an admin mailbox;; 2 = mailbox;; 1 = vague;; 0 = none.
EX035 — Containment. Name one containment step. Rubric: 3 = revoke sessions;; 2 = re-register authenticators;; 1 = delete account;; 0 = none.

Synthesis

Quick, evidence-based triage separates normal noise from events needing escalation.

Continue studying — chapter 07 of 12

← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →