Skip to content

🚨 General Alert Handling

Understanding how to triage and respond to any security alert is the most fundamental SOC analyst skill. Every specialised playbook builds on this foundation.

What is a Security Alert?

An alert is a notification generated by a security tool — SIEM, EDR, firewall, IDS/IPS, or WAF — indicating that a rule threshold or behavioral pattern has been triggered. Alerts are the starting point for every SOC investigation. Most alerts are false positives; your job is to quickly prove or disprove that.

The Universal SOC Triage Workflow

Step 1 — Review the alert details

Before touching anything, gather all context from the alert itself:

Field What to Look At
Alert name & rule What rule fired? Is it signature-based or behavioral?
Severity Low / Medium / High / Critical — use this to prioritize
Timestamp When did it happen? Business hours or off-hours?
Source IP / Host Internal or external? Known asset or rogue?
Destination IP / Port What was being targeted? What service?
Username Which account triggered this? Service account or human?
Action taken Did the tool Block it, Allow it, or just Alert?
Alert count Is this a single event or a pattern of many?

Step 2 — Initial triage (true positive or false positive?)

Apply quick context to classify the alert:

  • Check alert history — Has this rule fired on this asset before? Is it recurring?
  • Correlate with other events — Are there related alerts in the 30-minute window (pre or post)?
  • Check the asset — Is the source a known server, endpoint, or service account with expected behavior?
  • Check the user — Is the activity consistent with the user's role and normal working hours?
  • Check threat intel — Is the external IP/domain flagged in VirusTotal, Shodan, or your TIP?

Step 3 — Investigate (if suspicious)

Dig into logs, the endpoint, and network data:

  • SIEM — Search for the user/IP across multiple log sources around the same timestamp
  • EDR — Check the process tree, parent process, command-line arguments, network connections
  • Network/Proxy logs — Did the host make outbound connections to suspicious IPs or unusual domains?
  • Identity logs — Was there a login from an unusual location, device, or time?
  • Email logs — Was there a phishing email received around the same time?

Step 4 — Contain (if confirmed malicious)

Take the minimum action needed to stop the threat and preserve evidence:

  • Block the malicious IP/domain at the firewall or proxy
  • Isolate the endpoint using EDR (do not power it off — preserve memory/logs)
  • Disable or lock the compromised user account
  • Revoke active sessions and tokens

Step 5 — Escalate with all findings

Escalate to L2 or the Incident Response team with:

  • Timeline of events
  • All IOCs (IPs, hashes, domains, file paths)
  • Actions already taken
  • Scope assessment — how many systems/users affected?

Step 6 — Document everything

Create a detailed ticket with every step, finding, and decision. Good documentation protects you legally, enables post-incident review, and helps tune future alert rules.

Interview Answer

Q: Walk me through how you handle a security alert in the SOC.

"When an alert fires, I start by reviewing all the alert details in our SIEM — the alert name, severity, timestamp, source IP, destination, username, and whether the tool blocked or just alerted. My first goal is a quick triage decision: is this a true positive or a false positive? I check the alert history for that asset, correlate it with nearby events, and cross-reference the external IP or domain against threat intelligence like VirusTotal.

If the initial triage looks suspicious, I move into a deeper investigation — I pull EDR telemetry for the process tree and network connections, check proxy logs for outbound communication, and review identity logs for anomalies. I'm building a timeline and looking for corroborating evidence.

If I confirm it's malicious, I take the minimum containment action needed — isolating the endpoint, blocking the indicator, or locking the account — while making sure I preserve evidence for the IR team. Then I escalate with a written summary of everything I found: timeline, IOCs, actions taken, and scope. Finally, I document the full workflow in the ticketing system."

Very Short Version (Easy to Remember)

  1. Review — Read every field of the alert. What fired, when, on what, by whom, and was it blocked?
  2. Triage — True positive or false positive? Use history, correlation, and threat intel to decide fast.
  3. Investigate — If suspicious: SIEM search, EDR process tree, proxy/DNS logs, identity logs.
  4. Contain — Isolate, block, lock. Preserve evidence. Minimum action to stop the threat.
  5. Escalate — Hand off to L2 with full timeline, IOCs, and actions taken.
  6. Document — Write everything in the ticket. Every step. Every finding. Every decision.

Common L1 Mistakes to Avoid

  • Closing alerts without investigation — "looks fine" is not an answer; prove it.
  • Powering off an isolated device — you destroy volatile memory and active processes.
  • Escalating with no context — L2 needs your findings, not just the raw alert.
  • Forgetting to search for lateral scope — one alert often means more compromised hosts.