SOC Tools by Tier: What T1, T2 and T3 Analysts Open First

SOC tools are the software a security operations center uses to detect, investigate and respond to threats: a SIEM for logs and alerts, an EDR or XDR console for endpoint telemetry, a case or ticketing system, threat intelligence lookups, network data from firewalls and sensors, and SOAR for automation. Which ones you open depends on your tier. Tier 1 works from the SIEM queue and the ticket. Tier 2 lives in the EDR and the network data. Tier 3 writes the detections and automations the other two run on.

Most lists of SOC tools sort by category, which tells you what exists but not what you will be handed on day one, or in what order you open it when an alert lands. This one sorts by tier and by the first ten minutes of an alert, then covers where to practice each layer without a SOC job. For vendor-by-vendor comparisons, the best SIEM tools and best EDR tools roundups already do that job.

The stack at a glance: who reads, who acts, who writes

Permissions vary from shop to shop, but the pattern holds in most teams: the further up the tiers you go, the more a tool becomes something you change rather than something you look at.

Tier 1: the queue, the SIEM and the ticket

A tier 1 shift starts in a queue. In Microsoft Sentinel that queue is the incident list, and each incident inherits the entities, severity, status and ATT&CK tactics and techniques of the alerts inside it, according to Microsoft's incident investigation documentation (accessed 2026-09-28). Splunk, QRadar and Elastic present it differently, but the job is the same: read what the rule matched, then search around it. If you want to see the queue side in more detail, the alert triage guide walks through the decision itself.

Three other tools sit next to the SIEM at this tier.

The ticket. New analysts treat it as paperwork. It is the only record of what you checked, and the next shift reads it to decide whether to trust your verdict or start again. A ticket that says "checked, benign" costs the next person the same ten minutes you already spent.

ATT&CK. The technique ID on an alert tells you what the rule author thinks happened. The technique page tells you which data sources would confirm it and what usually comes next in the chain. The MITRE ATT&CK explainer covers how to read a technique page quickly.

Enrichment lookups. VirusTotal, AbuseIPDB and whatever intel platform your team runs. They are also where a tier 1 analyst can leak data without noticing.

Tier 2: the EDR, the network and the intel

Tier 2 is where tools stop being read-only. The EDR console is the centre of it, because the process tree answers the question the SIEM cannot: what ran, what launched it, and what it did next. It is also where containment lives. Microsoft's response action documentation (accessed 2026-09-28) describes device isolation as disconnecting the device from the network while keeping its connection to the Defender for Endpoint service, so the device keeps reporting while you investigate. Isolation cuts the attacker off without cutting off your telemetry.

Network data comes next. Firewall, proxy and DNS logs tell you whether a host reached out and to what. Sensors like Zeek and Suricata add connection metadata and signatures on traffic that never touched a log source you control. Intel changes character at this tier as well. Tier 1 asks whether an indicator is known bad. Tier 2 asks what else sits on the same infrastructure, which is the kind of question a platform like MISP is built for.

If your team runs Microsoft's stack, most of this tier happens in KQL, and the Kusto Query Language guide covers the operators you will use there.

Tier 3: the rules, the playbooks and the hunt

Tier 3 analysts and detection engineers own the logic everyone else runs on. Detection rules increasingly live as code, often written in Sigma and converted to the SIEM's own query language. Playbooks get written, tested and automated, and the SOC playbooks guide covers what makes one usable at 3 a.m.

SOAR belongs here, not lower down, and government guidance is blunt about why. The practitioner guidance on implementing SIEM and SOAR platforms, published on 27 May 2025 by the Australian Signals Directorate's ACSC and released with CISA and other partners (accessed 2026-09-28), warns that a badly configured SOAR can mistake normal behaviour for an incident and isolate systems on its own. It concludes that SOAR is "usually not suitable for immature environments" and that a properly implemented SIEM is the higher priority.

The hunting stack rounds out the tier: endpoint collection with Velociraptor or osquery, network data from Zeek, notebooks for long-running queries. The threat hunting tools guide covers that layer tool by tool.

The first 10 minutes of an alert

Here is the order the tools come up in when one alert lands, with the question each one answers and what should go into the ticket. The times are a target for a routine alert, not a rule.

Below is what that looks like on a single alert. Every value is made up; the IP is from a documentation range and the domain uses the reserved .example suffix.

Simulated example generated by SOCSimulator Research. The SIEM alert:

{
  "alert_name": "Office application spawned PowerShell with encoded command",
  "severity": "High",
  "time_generated": "2026-09-28T09:14:03Z",
  "host": "fin-ws-022",
  "user": "CORP\\j.moreno",
  "parent_process": "WINWORD.EXE",
  "process": "powershell.exe",
  "command_line": "powershell.exe -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkA...",
  "mitre_techniques": ["T1566.001", "T1059.001"]
}

The first part of that Base64 decodes, as UTF-16LE (the encoding PowerShell's -EncodedCommand parameter expects), to IEX (New-Object Net.WebClient): the start of a download-and-execute cradle. That alone moves the alert to the top of the queue. The EDR process tree for the same minute:

OUTLOOK.EXE (pid 6388)  user CORP\j.moreno
  \_ WINWORD.EXE (pid 7012)  Invoice_0928.docm
       \_ powershell.exe (pid 7344)  -nop -w hidden -enc SQBFAFgA...
            \_ TCP 203.0.113.45:443  cdn-invoice-sync.example

Outlook, then Word opening a macro-enabled document, then hidden PowerShell with an encoded command, then an outbound connection. That is PowerShell execution (T1059.001) coming out of a spearphishing attachment (T1566.001). The minute 1 to 3 search, in Defender advanced hunting, pulls everything that host started in a 30-minute window around the alert:

let suspect_host = "fin-ws-022";
let alert_time = datetime(2026-09-28T09:14:03Z);
DeviceProcessEvents
| where DeviceName startswith suspect_host
| where Timestamp between ((alert_time - 15m) .. (alert_time + 15m))
| project Timestamp, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine, SHA1
| order by Timestamp asc

Two details come straight from Microsoft's DeviceProcessEvents schema (accessed 2026-09-28). DeviceName holds the fully qualified domain name, hence startswith rather than ==. And the query projects SHA1, not SHA256, because the schema notes that SHA256 is usually not populated in this table. A hash column that is empty on every row looks exactly like a clean result. Before closing the ticket, one scoping query tells tier 2 whether this is one user or a campaign:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName =~ "winword.exe"
| where FileName =~ "powershell.exe"
| where ProcessCommandLine contains "-enc"
| summarize hosts = dcount(DeviceName), first_seen = min(Timestamp), last_seen = max(Timestamp)

A zero here is weaker than it looks. Attackers vary how they spell the parameter, so widen the match before you call a quiet result clean. The ticket note that comes out of those ten minutes:

09:14:03Z  fin-ws-022 / CORP\j.moreno
Word (Invoice_0928.docm, opened from Outlook) spawned hidden PowerShell,
-enc payload decodes to IEX (New-Object Net.WebClient) download cradle.
Outbound TCP 443 to 203.0.113.45 (cdn-invoice-sync.example) at 09:14:05Z.
Hash lookup only, no upload. Scope query: 1 host in 7 days.
Verdict: true positive, T1566.001 -> T1059.001. Escalated to T2 for isolation.

The time zone trap

Consoles do not agree on what time it is. Microsoft's Defender XDR time zone FAQ (accessed 2026-09-28) says the portal displays UTC by default and lets each user switch to local time. So your screenshot and your colleague's screenshot of the same event can differ by hours, and a SIEM or firewall console with its own display setting adds a third clock. The same ASD practitioner guidance lists "time synchronisation for logs that are collected in different time zones" as a core SIEM challenge. The fix is dull. Every timestamp in a ticket goes in UTC, with the Z, and names the console it came from.

How to practice each tier without a SOC job

Every entry below was checked against its repository or product page on 2026-09-28. SOCSimulator is our product, and it is listed with the same facts as the others.

A few notes the table cannot hold.

For tier 1 practice, skip the lab build at first. The skill is reading alerts and searching around them, not installing Elasticsearch. The SOCSimulator SIEM console is in the free tier with investigation scenarios mapped to ATT&CK; the pricing page lists the XDR/EDR and firewall consoles under Pro. If you already have a lab, Wazuh's agent on a Windows VM gives you real alerts from your own mistakes.

Security Onion is free to use but not open source in the OSI sense. Its repository ships under the Elastic License 2.0, which forbids offering the software to others as a hosted or managed service. That is irrelevant for a home lab and relevant if you ever plan to run it for clients. Its README lists Suricata, Zeek and full packet capture, so one install gets you network data at tier 2 depth.

Velociraptor fits tier 3 practice on one laptop. The project's README says running velociraptor gui brings up the GUI, the frontend and a local client on your own machine, so you can collect artifacts from yourself before you have a fleet. For open source SIEMs beyond Wazuh, the open source SIEM tools comparison goes deeper.

Where too many tools break a SOC

Buying another tool rarely fixes any of this. It tends to make four things worse.

Every console is another clock and another schema. The time zone trap multiplies. So do field names. The ASD guidance uses src_ip against sourceAddress as its example of terminology that has to be standardised before a SIEM can correlate anything. An analyst pivoting across five consoles spends part of every alert translating.

Overlapping detections double the queue. An EDR alert and a SIEM rule that fire on the same process creation produce two tickets, often worked by two people who each close half the story. Decide which tool owns each detection and suppress the other, or at least link them.

Automation lands before the basics. The guidance quoted above is explicit that a SOAR without a mature SIEM and an experienced team tends to either misfire or sit unused. A playbook that auto-isolates on a rule nobody has tuned will take a finance workstation offline at month end.

The tool nobody on shift can use. If only one engineer has the rights and the know-how to run a collection in the forensics tool, that tool does not exist at 3 a.m. Count tools by who can use them on the night shift, not by the licences you pay for.

The tool list for a SOC fits on one page. What separates the tiers is the order you open those tools in and what you write down between them. Make the ten-minute routine automatic on one SIEM and one EDR, keep every time in UTC, and look things up by hash. Those habits carry over when your next employer runs different vendors.