Lion Cipher Lab
Triage Suricata alerts: true positive, false positive, or needs a second look
- SOC Analyst / Blue Team
- Intermediate
- ~40 min
- Free · no account required
Why it matters
A sensor's job is to raise alerts. An analyst's job is to be right about them, and that is a completely different skill — the one that actually separates a working SOC from an expensive dashboard nobody trusts. Every alert Suricata writes is a claim, not a conclusion: it says 'traffic matched a pattern someone once decided was worth flagging.' Sometimes that pattern is a real attack. Very often it is benign traffic that happens to fit the shape. And sometimes you genuinely cannot tell without looking closer. An analyst who treats every alert as real burns out and cries wolf; an analyst who…
What you'll learn
- reading a Suricata alert in both fast.log and EVE JSON form
- the anatomy of an alert: signature, sid, rev, gid, category, severity, the 5-tuple, and metadata
- deciding true positive vs false positive by reading what the rule actually matched
- corroborating an alert with the http/dns/tls/fileinfo records from the same flow
- understanding severity vs priority — and why 'high severity' is not 'confirmed bad'
- pivoting from an alert to the packet/flow when a signature match is not enough
- recognising and resisting alert fatigue
- writing a one-line triage verdict with a documented reason
- judgment: when to act on an alert, and when to investigate before you believe it
Steps in this lab
- What you're triaging, and the one rule that governs all of it
- Meet the data: three alerts in fast.log form
- Anatomy of an alert: the EVE JSON record, field by field
- Severity vs priority — why 'high severity' is not 'confirmed bad'
- Triage Alert A — read what the rule actually matched
- Triage Alert B — the noisy rule that is genuinely fine
- Triage Alert C — the one you cannot call from the alert alone
- The cost of getting this wrong, and the one-line verdict habit