31. SOC, SIEM and Incident Response
31.5 Alert Triage
Triage means quickly deciding what each alert is and what to do next.
| Outcome | Meaning | Example |
|---|---|---|
| True positive | Real attack, alert is correct | Brute force followed by successful login from an unknown foreign IP |
| False positive | Alert fired but nothing bad happened | Admin mistyped their password five times |
| True negative | No alert, nothing bad | Normal traffic |
| False negative | Attack happened but no alert – the most dangerous | Attacker used a valid stolen password during office hours |
An L1 triage routine for every alert:
- Read the alert: what rule, which host, which user, which source IP, what time.
- Enrich: is the IP internal or external? Check reputation on services like AbuseIPDB or VirusTotal. Is the user real and expected on this host?
- Scope: did the same IP or user touch other hosts? Any success after the failures?
- Decide: false positive (close with a note), or true positive (escalate to L2 with evidence).
- Document everything in the ticket: what you checked, what you found, why you decided.
Severity usually considers impact (production server, customer data) and confidence. A failed scan against a patched web server is low; an admin login from a new country followed by a new user being created is critical.
Ravindra Bagale's Tip
Ticket madhe fakt "false positive – closed" lihine ha sarvat common L1 mistake aahe. Ka false positive aahe he lihaa: "User Sneha ne VPN varun 5 veles chukicha password takla, nantar yogya password ne login, IP company cha aahe." Pudhchya shift la ani audit la he khup upyogi padte.
Practice task
For each alert, decide true or false positive and write a one-line ticket note: (1) 40 failed SSH logins from an external IP, no success; (2) 5 failed logins then success for user admin from a new country at 3 a.m.; (3) Nikto scan alert from the company's own vulnerability scanner IP during an approved scan window.