3.2 Working the Incident Queue
Working the Incident Queue
The incident queue is the starting point of every shift. It shows all active incidents, sorted by severity and time, with filters for status, assignment, service source, and classification. Your job is to process this queue efficiently: triage new incidents, investigate the important ones, and resolve or escalate the rest.
Triage workflow
Triage is not investigation. Triage is the 60-second assessment that determines what happens next: investigate now, investigate later, or close as noise. Speed matters — you are trying to find the incidents that need immediate attention, not solve them all upfront.
Figure 3.2: Triage is a 60-second decision, not a 30-minute investigation. Read the title, check the entities, decide the action.
What to check in 60 seconds:
- Incident title — does it describe a known attack pattern? “Multi-stage AiTM phishing” demands immediate attention. “Suspicious inbox rule” needs investigation but is less urgent.
- Alert count and sources — multiple alerts from multiple products = higher confidence. A single alert from one product may be noise.
- Affected entities — is this a VIP user (executive, admin, finance)? Is it a critical device (domain controller, build server)?
- Time — how recent is the most recent alert? An incident that has been active for 6 hours without investigation is more urgent than one that just appeared.
A medium-severity alert for a regular user can wait. The same alert for your CFO, a domain admin, or a service account with privileged access cannot. Know your VIP list — if your SOC does not have one, create one. It is the single most effective triage acceleration tool.
Queue filters and sorting
The default queue shows all active incidents sorted by most recent. Useful filters:
- Status: Active — incidents that need work (exclude resolved/redirected)
- Severity: High — focus on the most critical first
- Service source — filter to specific products when investigating a specific type of alert
- Assigned to: Unassigned — find incidents nobody has picked up yet
- Classification: Not set — incidents that have not been triaged
Incident classification
After investigation, classify the incident. This feeds back into the detection engine and is critical for tuning:
| Classification | Meaning | Action |
|---|---|---|
| True Positive | Confirmed malicious activity | Document findings, remediate, close |
| Informational, expected | Legitimate activity that looks suspicious | Close, consider tuning the detection |
| False Positive | Not malicious, detection error | Close, create suppression rule |
Every incident you close without classifying is a missed opportunity to improve your detection quality. True positive classifications confirm the detection is working. False positive classifications signal that a rule needs tuning. If you close everything as "resolved" without classification, your detection quality never improves and alert fatigue gets worse.
Alert Tuning
Alert tuning is how you reduce noise over time. An untuned environment generates hundreds of alerts per day. A well-tuned environment generates dozens — and each one matters.
Suppression rules
When you identify a recurring false positive, create a suppression rule that automatically resolves future instances matching the same conditions. Conditions can include: specific alert title, specific user or device, specific IP range, or specific application.
Tuning workflow
- Investigate the false positive thoroughly — confirm it is genuinely benign, not just unfamiliar
- Identify the specific conditions that make it a false positive (e.g. “this alert fires for a specific service account that runs a scheduled job every hour”)
- Create a suppression rule scoped as narrowly as possible — suppress the specific condition, not the entire alert type
- Document why the suppression exists (in the rule description) so a future analyst understands the decision
Suppressing all "suspicious inbox rule" alerts because one user creates legitimate rules is dangerous. Suppress the alert for that specific user only. Broad suppression creates blind spots that attackers can exploit.
Triage decision: new incident in the queue
Check your understanding
1. An incident contains 8 alerts. After investigation, 6 are genuine and 2 are false positives. What should you do with the false positive alerts?
2. Why should suppression rules be scoped narrowly rather than broadly?
3. During triage, what factor should make you escalate a medium-severity incident to immediate investigation?