Skip to content
Sign In

Learn · Start here

Foundations

What a SOC does, why defenders stack layers of control, and what the analyst's part of that work really is. Everything else in Learn builds on this.

About 10 min

In this unit
The vocabulary and habits behind every investigation: what a SOC does, how an alert becomes a decision, and why evidence beats suspicion.
Before you start
Nothing. Start here.
Not yet read in this browserSign in to see where you have applied this.

Why it matters

Every alert you triage and every case you run asks the same question: did something bad happen here, and if so, what exactly. The concepts in this unit are how a SOC organizes the work of answering it, and they are the vocabulary your colleagues will use.

Knowing how the pieces fit tells you how seriously to take what you are looking at. An alert that means an attacker got past several layers is a different problem from one the first layer already stopped.

What analysts see

On a working day these ideas show up as three things.

  • A queue of alerts from many sources, most of them noise. Triage is deciding quickly which ones are real.
  • Evidence scattered across systems: endpoints, the network, mail, identity. No single source tells the whole story.
  • A handoff at the end of every investigation, to another tier, to the team that fixes the underlying issue, or to whoever must be told.

The Range puts you in the middle of this: the evidence is in the SIEM, and you write the conclusion.

Core concept

A Security Operations Center (SOC) watches continuously for signs that something bad is happening. Attackers look like normal activity until the moment they don't, so the work is ongoing monitoring, not a one-off check. The SOC is the people, tools and process built around that watching.

Most SOCs split the work into tiers, and the learning paths here follow them. Tier 1, Analyst Foundations, triages the flow of alerts and escalates what looks genuine. Tier 2, Incident Investigation, investigates escalations, rebuilds the intrusion behind them and decides what to contain. Tier 3, Specializations, is where an analyst specializes in one of four tracks: Detection Engineering, Threat Hunting, Forensics or Malware Analysis.

Defense in depth means no single control is trusted to hold. Segmentation, endpoint monitoring, identity and access controls, logging and detection, and a response process each cover for the others' failures. When you investigate, the layers tell you what an attacker had to get past to reach the point you are looking at.

Network defense never finishes. Attackers adapt, so detections need tuning when they are noisy, new detections are needed for behavior nobody covers yet, and the team needs a shared, current map of adversary behavior. MITRE ATT&CK is that map, and Thinking in MITRE ATT&CK covers this in depth.

The analyst's core skill is knowing what normal looks like well enough that abnormal stands out, then working from incomplete evidence to a conclusion you can defend. It is investigative work: you rebuild a sequence of events from scattered records. That skill comes from repetition on real telemetry, which is why every case on the Range is hands-on.

Annotated examples

One record, several layers

A synthetic endpoint-protection record of the kind you might triage. Every value is invented.

@timestamp:
2026-03-10T14:22:41.007Z (note 1)
host.name:
ws-example-12 (note 2)
user.name:
a.chen (note 3)
file.path:
C:\Users\a.chen\Downloads\quarterly-report-viewer.exe (note 4)
event.action:
quarantined (note 5)
  1. Note 1: Times in the SIEM are UTC. Mid-afternoon on a workday is when people open what they downloaded, so the time alone proves nothing.
  2. Note 2: The machine the file was found on. Find out what this host is and who uses it before you go further.
  3. Note 3: The account the file belonged to. Would this person normally download programs?
  4. Note 4: Where the file was. A program in a downloads folder came from somewhere, and that is a question to answer, not a conclusion.
  5. Note 5: Endpoint protection quarantined the file. One layer held, but the file still reached the machine, and that is worth explaining.

A quarantined file is not the end of the story. The endpoint layer worked; the question is how the file got there. Check where it was downloaded from, whether it ran before it was caught, and whether the same file is on other machines.

How to investigate

  1. 1.

    Read what fired.

    Note the source, the host, the account and the time before you form a view.

  2. 2.

    Ask whether it is normal.

    Compare with how this host and this account usually behave. The first question in triage is whether this is real.

  3. 3.

    Look across layers.

    Check what the other evidence sources recorded around the same time: endpoint, network, mail. One source rarely tells the whole story.

  4. 4.

    Set the scope.

    Find the first and last related activity, and every host and account involved.

  5. 5.

    Decide and record.

    Close it as benign with a reason, or escalate it with the evidence that makes it real. Either way, write down what you found and where.

Common mistakes

  • Mistake: Treating a blocked event as resolved.

    InsteadAsk why the attempt happened. A control that held can still point to a compromise.

  • Mistake: Judging an alert from one source.

    InsteadCheck the other layers before you decide.

  • Mistake: Closing an alert without a reason.

    InsteadRecord why it is benign. The next analyst will see the same pattern.

  • Mistake: Escalating without evidence.

    InsteadHand over the host, account, time and records that make it real.

  • Mistake: Assuming the network is either all clean or all compromised.

    InsteadScope it: which hosts, which accounts, from when to when.

  • Mistake: Learning only the tool's interface.

    InsteadLearn the telemetry underneath. It transfers between products; the interface does not.

Field references

FieldWhat it tells youSeen in
@timestampWhen the event happened, in UTCEvery data view
host.nameThe machine that recorded the eventWindows event logs, Sysmon, Linux audit
user.nameThe account the activity ran underWindows event logs, Sysmon
source.ipWhere a connection or request came from, such as 192.0.2.44Network records
destination.ipWhere a connection wentNetwork records
event.actionWhat the source did with the event, such as endpoint protection quarantining a fileWindows event logs, Network records

Apply it in a Case

On your next case, before you search for the attack, spend five minutes on normal: pick one host and one account and note what their ordinary activity looks like. Then look for what does not fit.

Browse every case on the Range →

References

Keep going

Next is How Our Ranges Work. With a free account, you'll see what counts toward Tier 1 Analyst.