14.4 Triage Workflow, Severity, Status, and Verdicts

Triage is a workflow, not a vibe

SAL1 Alert Triage and Ticketing walks the triage workflow and alert classification: severity, statuses, and verdicts. This independent section is the conceptual backbone you will click in a SOC and in the SOC Simulator: TryHackMe's scoring article (29 March 2025) gives Classification 150 marks in each 400-mark scenario. Chapter 2 taught that scoring and the published zero-mark warning. Here you learn the meanings of the labels so you do not guess.

Triage means ordering and disposing work so the dangerous true things move first, without pretending every red badge is a breach. A practical L1 sequence:

1. Dequeue the next item using severity as a sort hint, then a queue snapshot so you do not tunnel-vision one card (chapter 2's first ten minutes).
2. Identify timestamp, affected asset, user, and which detection rule fired (section 14.3).
3. Open the workbook for that class. If none exists, use a generic skeleton: time, asset, related logs, indicators, documentation check.
4. Enrich before verdict. Asset owner and role, change calendar, scanner and allow lists, threat-intel on IPs/domains/hashes, related alerts in a nearby time window, and raw events—not only the highlighted field.
5. Assign a verdict (below). If evidence is thin but the story could be malicious, keep investigating; do not guess false positive to empty the queue.
6. Set status to match reality: in progress while you work, pending if you are waiting on a tool, escalated or closed when the workbook says you are done.
7. Update the ticket with facts. Escalate only when criteria say so (high level below; matrix in chapter 15).
8. Re-check the queue. New related firings often complete the chain.

Skipping enrichment is how authorized scanners become "intrusions" and how real beacons become "user typos."

Severity versus status versus verdict (do not collapse them)

These are three different questions. Mixing them is the most common L1 classification error.

Severity answers: how bad would this be if the detection's hypothesis were true? Typical labels: informational, low, medium, high, critical. Severity is usually assigned by the rule (or a scoring model) before you investigate. A High "possible C2" is a loud hypothesis. It is not yet a verdict. You may still close it as benign if the source is the approved scanner. You may still treat a Low as a true positive if logs show a quiet, confirmed backdoor. Do not use severity as the verdict.

Status answers: where is this item in the human workflow? Typical labels: New, in progress, pending, escalated, suppressed, closed. Status is operational bookkeeping. A Critical alert can be Closed. A Low alert can sit In progress for an hour while you correlate. Status is not a statement that the activity was malicious.

Verdict answers: what kind of truth did investigation find? For SAL1-level SOC work, memorize three:

True positive (TP)

The detector fired on activity that is what the rule is meant to catch, and that activity is malicious (or a genuine policy incident of that type). The rule was not confused. Example in the next worked pair: Word spawned wscript.exe, which beaconed to a young domain. Classify TP. Default next step: escalate with indicators when the workbook's criteria match (clear indicators of compromise (IoCs), crown-jewel asset, ongoing C2). Chapter 15 details the matrix; here, remember that TPs with clear IoCs are the alerts the SOC Simulator advice article (11 March 2025) tells you not to treat as optional.

False positive (FP)

The detector fired, but the event is not the bad thing the rule claims. The pattern matched junk: a bad field extraction, a substring collision, a signed admin script that only looks encoded. The activity may be completely normal. Classify FP. Default next step: close with the reason, then FP remediation against the rule (section 14.2). Escalating FPs as incidents trains IR to ignore the SOC.

Benign true positive (BTP)

The detector is technically correct—the activity matches the pattern—but the activity is authorized or expected. Classic case: the vulnerability scanner doing what documentation says it should do; an approved penetration test in a window; a backup host transferring large volumes to the backup network. Classify BTP. Default next step: close with the authorizing fact (scanner name, change ticket, test window). Escalate a BTP only if local policy says the finding still needs tracking (for example, scanner discovered an open host)—that is a vulnerability ticket, not "the scanner is the attacker."

Some shops add true negative (no alert, nothing bad) or false negative (something bad, no alert). Those matter for detection engineering and hunting. The queue you triage is made of firings; FN is the incident you find some other way. Do not invent a fourth button if the platform only offers TP/FP/BTP.

Enrichment before verdict

Enrichment is not decoration. Minimum set before you lock a verdict:

• Identity of the asset: hostname, IP, owner, subnet (branch PC versus SCAN-VULN-01 versus a domain controller).
• Identity of the user: role, travel, service account versus human.
• Documentation: approved scanners, probe lists, change windows, how this company sends mail.
• Related alerts: same host, user, or indicator within a bounded time.
• Threat intelligence: what is already known about the IP, domain, or hash—and what empty TI does not prove (tool failure is not "benign").
• Raw telemetry: parent process, full command line, bytes, destination rarity.

If enrichment is incomplete and the story could be a TP, keep the status in progress. Guessing FP to look productive is how you hit TryHackMe's published warning: the SAL1 technical-issues article (19 May 2025) states that if you misclassify at least 1 TP or the time runs out the whole section will be marked as 0. Teach that as published language. Classification scoring is 150 marks; a missed TP is not a "partial credit" event under that warning.

Escalation criteria at a high level (detail in chapter 15)

Escalation is a separate decision from verdict. Rough L1 rules of thumb:

• Escalate confirmed TPs with clear IoCs, ongoing C2, credential theft, ransomware behavior, or crown-jewel impact.
• Do not escalate FPs or ordinary BTPs once you have the authorizing fact.
• Ask the shift lead when the verdict is TP but impact is unclear, or when the workbook's "page IR" line is ambiguous.

Chapter 15 covers matrices, SLAs, and how you speak to other teams. This chapter only needs you to stop treating "High" as "page everyone" and "Low" as "cannot be a TP."

Worked pair: failed logon versus confirmed C2

Case A — failed logon burst (often not a TP incident). Alert: High "brute force" on Cedar Bank VPN. User m.cole, 14 Windows Event ID 4625 failures in eight minutes, then a 4624 success from a hotel IP. Enrichment: HR travel note says m.cole is in that city; no other alerts on m.cole; EDR on the laptop is clean; no new mailbox rules; TI on the hotel IP is empty residential space. Workbook says: check travel, check success after failures, check for spray against many users. Here the failures are the user mistyping on hotel Wi-Fi, then succeeding. Verdict is often FP (the rule claimed brute force, but the pattern is a human plus a travel IP) or a low-confidence close per local policy—not a C2 incident. Status: closed. Escalation: no, unless the workbook says every VPN 4624 after failures must be reviewed by IAM. Severity stayed High the whole time; that did not make it malware.

If instead the same 4625s came from a single source against forty users with no travel story, you are in password-spray territory: that can be a TP even with no malware yet. Enrichment changed the verdict. The title did not.

Case B — confirmed C2 (TP, escalate). Alert: High "rare 60-second HTTPS beacon" on BR-WKS-22 / a.nguyen. Enrichment: parent winword.exe from an email attachment; domain 48 hours old; interval ~60 seconds; related mail-gateway alert; not in the probe list; not SCAN-VULN-01. Verdict: true positive. Status: escalated. Escalation: yes—isolate host, block domain/IP, reset user, preserve the sample—because IoCs are clear and C2 is ongoing. Classification and escalation are both required; closing as BTP because "HTTPS is normal" would be a missed TP.

Same High badge. Opposite outcomes. The difference was enrichment plus the three-axis model.

Why this is the simulator's classification backbone

In each SOC Sim, you will apply this model to a variable, dynamic queue. Classification marks reward correct verdicts, especially TPs. Escalation marks (chapter 15 and chapter 2) reward raising the right TPs. Case reports record the enrichment. If you collapse severity into verdict, you will escalate scanners and miss quiet TPs. If you collapse status into verdict, you will think Closed means FP. If you skip enrichment, you will mark Case B as a failed logon analogue.

Independent study of these SAL1 classification topics is the difference between clicking labels and investigating. Use the workflow, keep the three axes apart, enrich, then verdict. When it might be a TP and the clock is running, confirm—it is safer than a casual FP under the published section-zero rule.