SOC triage: the first 15 minutes of an alert
In a SOC the problem isn't a lack of alerts, it's the excess. The difference between a productive shift and drowning is having a method for each alert instead of improvising. Here's the one I use: four steps —validate, enrich, scope, decide— that in a few minutes take you from "something fired" to "I know what to do with it".
1. Validate: is it real?
Before investigating anything, decide whether the alert deserves your time. Most closures happen here:
- Known false positive? Check if the rule already has exceptions or a usual pattern (an internal scanner, a nightly backup).
- Is the source reliable? A noisy rule with 500 identical alerts needs tuning, not 500 investigations.
- What exactly triggered the rule? Read the logic, not just the title. Many alerts say less than they seem to.
2. Enrich: give it context
A raw alert is a loose data point. Context is what turns it into a decision. Gather the indicators (IP, domain, hash, user, process) and enrich them:
- IP/domain: reputation? geolocation consistent with the user? is it known infrastructure?
- File hash: look it up in threat-intel sources without running it.
- User/asset: who is it, what permissions, is it a critical asset or a lab machine?
When you paste indicators into a ticket or the team chat, defang them first so nobody accidentally opens a malicious URL.
If the alert is phishing
Get the .eml and analyze it without opening links: headers, SPF/DKIM/DMARC authentication, sender and IOCs. Step by step in this guide and automated in the Email Triage.
If the alert is a vulnerability
Not every CVE is your emergency. Cross severity, exploit probability (EPSS), KEV and your real exposure to know if it's urgent —I cover it in "Which CVE to patch first" and with "Does it affect me?".
3. Scope: how far does it reach?
If it's still standing after enrichment, delimit the scope before escalating. It's the question that helps the next analyst most:
- One host or many? Search the same indicator across the rest of the fleet.
- When did it start? The first sighting sets the time window to review.
- Did it move? Outbound connections, lateral authentications, child processes.
4. Decide: close, escalate or contain
With the above, the decision almost makes itself:
- False positive → close and, if it recurs, propose tuning the rule. Closing well is work too.
- Real but low impact → document and resolve per the playbook.
- Real and serious → escalate and, if warranted, contain now (isolate the host, block the indicator). When in doubt, containing and notifying beats waiting.
Whatever you write, leave the trail: what you saw, what you checked and why you decided. The "why" is what turns a closure into reusable knowledge.
The idea
Validate → enrich → scope → decide. It's not slower than improvising; it's what stops alert number 60 of the shift from catching you without a method. And much of the enrichment takes seconds with browser tools, without installing anything or taking data off the machine.
Cybersecurity Analyst · SOC · Sentinel/KQL specialist