2.3.3. Investigating and Remediating Risk
💡 First Principle: Automation handles the clean cases; the reports exist for the rest. Investigation is deciding, per detection, which of three truths you're in — false positive, real-but-contained, real-and-active — and the portal's verbs (dismiss, confirm safe, confirm compromised) are how you teach the system which one it was.
Three working surfaces: Risky users (each user's level, detections, recent risky sign-ins; actions: reset password, confirm user compromised, dismiss user risk, block), Risky sign-ins (per-event detail with location, IP, device, applied CA outcome; actions: confirm safe / confirm compromised), and Risk detections (the raw feed, filterable by detection type). Investigation flow: read the detection type, correlate with the user's normal pattern (sign-in logs), check what policy already did (did MFA pass?), then act.
The verbs have consequences: confirm compromised pushes user risk to High (triggering your user-risk policy); dismiss closes risk without marking it legitimate; confirm safe trains detections toward the user's pattern. Full compromise response is never just a password: reset, revoke sessions, audit the user's registered MFA methods (attackers add their own), and check mailbox rules/app consents planted for persistence.
Risky workload identities extend the same machinery to service principals (P2 / workload identities licensing): detections like leaked service-principal credentials or anomalous sign-ins surface in a parallel report, and remediation means rotating credentials/disabling the principal — plus risk-based CA for workload identities where licensed. Phase 4 covers the identities themselves; here, know the report exists and that apps can be "risky" too.
⚠️ Exam Trap: Dismiss ≠ confirm safe. Dismiss says "stop tracking this risk" (no learning); confirm safe says "this was truly the user" (feeds the model). Using confirm-safe on an actually-compromised sign-in actively teaches the wrong lesson.
Reflection Question: After confirming a user compromised and resetting their password, why must you still review their registered authentication methods and active app consents — what persistence survives a password reset?
