Skip to content

A SIEM alert fires for a suspicious login. Walk me through how you triage it.

Short answer

Confirm the alert is real before acting: read what fired and why, then enrich it — who is the user, is the source IP/geo/device expected, is this impossible travel, were there prior failures? Classify true vs false positive, escalate or contain if real (disable session, force MFA reset), and document everything so the next analyst can follow your reasoning.

Triage is about answering one question efficiently: is this real, and if so, how bad? Interviewers want to see a repeatable process, not a reflex. Jumping straight to "disable the account" is a red flag — you might be acting on a false positive and burning trust, or tipping off an attacker before you understand scope.

1. Validate

Start by reading the detection itself. What rule fired, on what data source, and what is the exact condition that matched? A "suspicious login" could be a single geovelocity rule or a correlation of several signals. Knowing why it fired tells you what evidence to gather.

2. Enrich with context

This is where most of the value is. Pull the surrounding facts:

  • Identity: who is the user, what is their role, do they normally log in at this hour?
  • Source: is the IP from a known corporate range, a VPN, a residential ISP, or a hosting provider / Tor exit? What country, and is that plausible?
  • Device: is this a managed device with the expected user agent, or something new?
  • Sequence: were there failed attempts before the success (password spray / brute force), and is there impossible travel — two logins too far apart geographically to be the same person?

3. Classify

With context in hand, decide: true positive, false positive, or benign true positive (real but authorized, e.g. the user travelling). Say so explicitly and record the evidence that led you there.

4. Contain (if real)

If it looks like account compromise, act proportionally: revoke the active session, force a credential and MFA reset, and check what the session did — mailbox rules, OAuth grants, data access. Containment beats waiting.

5. Escalate and document

Hand off to incident response if the blast radius is more than one account or you see lateral movement. Either way, write it down: what fired, what you checked, what you concluded, and what you did. Good notes are what let a SOC tune detections and survive an audit.

Why this matters

The structure shows judgment. Anyone can click "block"; an analyst who can explain why a login was or wasn't malicious — and who leaves a clean trail — is the one who gets trusted with bigger incidents.

Likely follow-ups

  • What is 'impossible travel' and how would you detect it?
  • When do you escalate to incident response versus handling it yourself?
  • How do you tune a noisy rule without creating a blind spot?

Sources

Certifications

Get 100 cybersecurity interview questions + answers

Drop your email and we'll send you the free PDF pack and the flashcard deck.

No spam. Unsubscribe anytime.