Advanced Security #alert-triage #alert-severity #SOC-documentation #false-positive

Alert Triage

5 exercises — master alert triage vocabulary: the full acknowledge-assess-enrich-classify-act-document process, alert enrichment dimensions, P1–P4 severity classification and escalation phrases, how to professionally close a false positive with a tuning recommendation, and complete SOC case documentation structure.

0 / 5 completed

Alert triage quick reference

Triage steps: Acknowledge → Assess → Enrich → Classify (TP/FP) → Act → Document.
Enrichment dimensions: threat intel, asset context, user context, historical alert data, correlated alerts.
P1 Critical (≤15min/page CISO) → P2 High (≤1h/Tier 2) → P3 Medium (≤4h/standard queue) → P4 Low (next business day).
Closing as FP: document exactly WHY with evidence; include a specific suppression/tuning recommendation; risk-assess the exclusion.
Case notes must include: header, initial assessment, timestamped investigation timeline, evidence, disposition (TP/FP/Indeterminate), actions taken, recommendations.
Alert fatigue root cause: high FP rate → analysts stop trusting alerts → real threats missed. Solved by enrichment-driven triage and targeted rule tuning.

1 / 5

A new SOC analyst asks: "When a SIEM fires an alert, what exactly do I do? What does triage an alert mean step by step?"

Describe the core alert triage process in a SOC and what each step involves.

Structured triage prevents both missed threats (from rushing to close alerts) and wasted time (from escalating obvious false positives). Every step has a specific English vocabulary.

Triage process vocabulary:

Step	Action	Key phrases
1. Acknowledge	Assign alert to yourself in the queue	"I'm picking this up." / "Alert assigned to me."
2. Assess	Read alert context: what fired, who/what is involved, severity	"The alert triggered on…" / "Involved asset is…"
3. Enrich	Look up IP, user, asset in intel feeds and CMDB	"IP is flagged by VirusTotal." / "Host is a critical payment server."
4. Classify	TP / FP / Requires further investigation	"This is a confirmed true positive." / "Closing as FP — scheduled scan."
5. Act	Open incident or close with documented reason	"Escalating to Tier 2." / "Closed — false positive, originating from Nessus scan."
6. Document	Write case notes; log rationale for all decisions	"Investigation steps taken: …" / "Recommended rule change: …"

Alert queue management vocabulary:
• Alert queue — the list of firing alerts awaiting analyst review; managed by priority/severity and age
• Queue depth — the number of unreviewed alerts; high queue depth = SOC under stress or rule quality issues
• Alert SLA — the time target for initial triage: e.g. "P1 alerts triaged within 15 minutes of firing"
• Alert ownership — assigning an alert to a specific analyst to ensure no alert is dropped or duplicated

Key vocabulary:
• Alert triage — the structured process of evaluating an alert's validity and required action: acknowledge → assess → enrich → classify → act → document
• Triage (noun, verb) — from medical triage; in SOC = prioritising and routing security events based on severity and context
• Alert fatigue — chronic analyst exhaustion caused by excessive FP alerts; leads to desensitisation and missed real threats

2 / 5

During a team review, a senior analyst says: "The raw alert tells us very little. We need to enrich it before we can make a confident triage decision. An enriched alert looks completely different from what the SIEM fired."

What does alert enrichment mean, what does it add, and how does an enriched alert differ from a raw alert?

Enrichment is what transforms "an IP connected to port 443" into "a known botnet C2 IP contacted your internet-facing payment server at 2 AM, and the same server had a failed login from the same IP 10 minutes earlier." The first is noise; the second is an incident.

Enrichment dimensions:

Dimension	Where the data comes from	Example enriched finding
Threat intel	VirusTotal, MISP, threat feed, EDR	"IP flagged by 12/90 vendors as Emotet C2"
Asset context	CMDB, asset inventory	"Destination is PCI-scope cardholder database, no public internet access expected"
User context	Active Directory, HR system	"User is a contractor, access expires in 3 days, no prior alerts"
Historical alert data	SIEM/SOAR case history	"This rule has fired 3 times on this host; all prior instances were vulnerability scanner FPs — but scanner traffic should be excluded"
Alert correlation	SIEM timeline, related alerts	"Same source IP triggered 5 other alerts in last 6h including port scan, failed auth, and new process launch"

Key phrases for enrichment discussions:
• "Let me enrich this before I classify it."
• "After enrichment, the alert looks much more suspicious — the IP hasn't fired before but the asset it hit is critical."
• "The enrichment shows this was a scheduled vulnerability scan. Closing as FP and recommending the scanner IP be excluded from this rule."

Key vocabulary:
• Alert enrichment — adding threat intel, asset, user, historical, and correlated context to a raw SIEM alert to enable accurate triage classification
• Raw alert — the initial alert as fired by the SIEM rule, containing only the fields captured in the log event (IP, time, rule name)
• Enriched alert — a raw alert supplemented with context from multiple data sources; enables confident, fast triage decisions

3 / 5

The SOC adopts a P1–P4 alert severity framework. During onboarding, the lead explains: "Severity classification determines response time and escalation path. Misclassifying a P1 as a P3 could mean a breach goes uncontained for hours."

What does a P1–P4 severity framework look like, and how do you communicate escalation correctly in English?

Severity frameworks enable the right analyst (right skill level, right authority) to respond at the right speed. Learning the framework language is critical for SOC communication.

P1–P4 framework reference:

Level	Criteria	Response target	Escalation path
P1 Critical	Active confirmed incident, significant business impact	≤15 minutes	On-call + SOC lead + CISO
P2 High	Likely threat, unconfirmed impact, time-sensitive	≤1 hour	Tier 2 analyst / SOC lead
P3 Medium	Suspicious activity, investigation needed	≤4 hours	Standard queue; no paging
P4 Low	Informational, FP candidate, audit trigger	Next business day	Standard queue; log only

Escalation communication phrases:
• "I'm escalating this to P1 — confirmed exfiltration event in progress. Paging on-call now."
• "Upgrading from P2 to P1 — lateral movement has reached a domain controller. Need incident commander."
• "Downgrading from P2 to P3 — enrichment shows this is a Nessus scan; not a real threat."
• "This stays at P2 until we can confirm whether the login was the account owner or an attacker."

Key vocabulary:
• P1 / Critical — active, confirmed incident requiring immediate response; maximum escalation
• P2 / High — likely significant threat; escalate to senior analyst; time-sensitive investigation
• Severity classification — assigning a priority level to an alert based on confirmed or potential impact; drives response time and escalation path
• Escalation path — the defined sequence of people and roles notified as alert severity increases

4 / 5

An analyst reviews an alert that fired 12 times this week, always for the same scheduled vulnerability scanner. She says: "I'm going to close this as a false positive and recommend a rule tuning change to prevent alert fatigue."

How do you professionally close an alert as a false positive, and what makes a good tuning recommendation?

5 / 5

After containing an incident, a senior analyst reviews the case notes submitted by a junior analyst and says: "These case notes are incomplete — there's no timeline, no investigation steps, and no clear disposition. Good SOC documentation needs to be useful to whoever picks this up after you."

What should complete SOC case documentation contain?

Case documentation is the SOC's institutional memory. When an analyst goes off-shift, gets sick, or leaves the company, the case notes are what enables continuity. Incomplete notes can mean a real incident is dropped at handover.

SOC case documentation structure:

Section	What to include	Why it matters
Header	IDs, timestamps, severity, assigned analyst	Traceability and audit trail
Initial assessment	What the alert was, initial hypothesis	Shows analyst's starting reasoning; reviewer can check for bias
Investigation timeline	Timestamped actions: what was checked, where, what was found	Next analyst can continue without re-doing work; legal admissibility
Evidence	Logs, screenshots, hashes, tool outputs forming the evidence base	Supports or refutes the hypothesis; required for legal/regulatory response
Disposition	TP / FP / Indeterminate + clear justification	Enables metrics tracking and rule quality improvement
Actions + recommendations	What was done; what remains; rule tuning suggestions	Enables handover; drives continuous improvement

Key vocabulary:
• Case notes — the running written record of investigation steps, findings, and decisions within a SOC incident/alert case
• Investigation timeline — a timestamped chronological log of every analyst action: queries run, tools used, sources consulted, findings noted
• Disposition — the final classification of a SOC case: True Positive (real incident), False Positive (benign), or Indeterminate (insufficient evidence to confirm either); required to close a case
• Case handover — transferring an open case from one analyst or shift to another; good documentation enables seamless handover without losing investigation progress