triaging-security-alerts

Triaging Security Alerts

Triage is the highest-volume work in security and the least written about. The output is a disposition you can defend later — most often to someone asking why an alert that preceded a breach was closed.

Three properties make it hard. The overwhelming majority of alerts are not incidents, so the prior is against you on every single one. The cost of the two error types is wildly asymmetric — a wrongly escalated alert wastes hours, a wrongly closed one costs the breach. And the queue keeps arriving, so unbounded care on one alert is care stolen from the next.

When to Use

• Working an alert queue from a SIEM, EDR, or cloud security tool
• Deciding whether an alert becomes an incident
• Reworking a backlog, or a specific alert that keeps recurring
• Reviewing another analyst's disposition
• Determining whether a noisy detection should be tuned or removed

When NOT to Use

• The alert is already confirmed malicious — stop triaging and use responding-to-incidents; triage ends where response begins
• Searching for compromise with no alert to start from — use hunting-threats; a hunt is hypothesis-driven, triage is queue-driven
• Rewriting the rule — use engineering-detections or writing-sigma-rules; feed your triage findings to it rather than tuning in place mid-queue
• Analysing the sample an alert pointed at — use analyzing-malware
• Investigating a specific compromised host in depth — use investigating-windows-endpoints or the relevant cloud investigation skill

Three Dispositions, Not Two

The common failure is a binary true/false frame. There are three, and conflating the last two destroys your detection programme: