Module 11 Lesson 3 of 6 🕑 ~50 min

> cat module-11-3-alerts-triage.md

Alerts, Triage & the Analyst Mindset

This is arguably the most important lesson in the whole module. Everything else — SIEM, EDR, XDR, MITRE ATT&CK — exists to put an alert in front of an analyst. What that analyst does next is the actual job.

1 Event, Alert & Incident

These three words get used loosely, but they mean specifically different things.

Event
Something happened — e.g. alice successfully logged into laptop LON-LT-102. No judgment attached.
Alert
Security logic matched one or more events, e.g. ALERT: Multiple failed logins followed by successful login. User: alice. Source: 203.0.113.20. Severity: High. Thousands of events can contribute to a single alert.
Incident
One or more related alerts grouped into a security investigation. Microsoft's current Defender model similarly describes alerts as signals from detection activity, and incidents as collections of related alerts telling the broader attack story.

Example incident, built from four alerts:

Incident: Compromised employee account
  Alert 1: Suspicious sign-in
  Alert 2: MFA registration changed
  Alert 3: Mailbox forwarding rule created
  Alert 4: Large SharePoint download

An analyst should investigate the attack story, not just close individual alerts one at a time as if they were unrelated tickets.

2 Severity vs Priority

Alerts carry a severity level — Informational, Low, Medium, High, Critical — but severity alone doesn't decide the outcome. A critical alert can still turn out to be a false positive; a medium-severity alert can turn out to reveal a major compromise once investigated. Severity describes how serious the behaviour could be in the abstract; priority factors in business context. Malware on a test laptop might be High severity but Medium priority. Suspicious PowerShell on PAYMENTS-PROD-01 — the server behind global payment processing — might only be Medium severity technically, but Critical priority the moment you know what that box actually does. Asset context changes everything.

3 Triage: The Basic Workflow

Triage means rapidly answering: what happened? Is it malicious? Who or what is affected? How serious is it? What should happen next? An alert is not automatically an incident — the analyst has to investigate first.

Take this alert: ALERT: Multiple failed authentications. User: j.smith. Source IP: 203.0.113.50. Start gathering context: who is j.smith — standard user, admin, contractor, service account, executive? Where is 203.0.113.50 — corporate VPN, office IP, known cloud service, or unrecognised internet address? How many attempts — 3? 30? 30,000? Were other accounts targeted, or just this one?

That last question changes the investigation dramatically. 1,000 attempts against one user looks like brute force. One attempt against 1,000 different users looks like password spraying — attackers use spraying specifically to stay under account-lockout thresholds (Module 8, Section 8; Module 9, Lesson 1). Understanding authentication logs well enough to tell these apart at a glance is a core SOC skill, not a nice-to-have.

4 Building Context & a Timeline

SOC analysts correlate several kinds of context at once: user context (department, permissions, is the account privileged, recent password/MFA changes), device context (employee workstation vs Domain Controller vs payment server, is EDR installed, is it patched), network context (internal or external IPs, ports, protocol, was it blocked), and threat intelligence (has this IP/domain/hash been seen before — though TI alone should rarely decide the outcome, since an IP can change ownership, a malicious domain can disappear, and cloud IPs are often shared by thousands of unrelated customers).

Strong analysts build a timeline instead of reasoning about events in isolation:

08:14:02  User receives phishing email
08:15:47  User opens Word attachment
08:15:50  WINWORD.EXE launches powershell.exe
08:15:52  PowerShell connects to external domain
08:16:03  Executable written to AppData
08:16:07  Executable launches
08:17:21  Credential dumping alert
08:19:18  Account authenticates to FILESERVER01
08:21:44  Account authenticates to DC02

Laid out this way, the attack becomes legible: phishing → execution → payload download → credential theft → lateral movement. Individually, several of those log lines look unremarkable; the timeline is what turns them into a story.

5 False Positives, Benign Positives & False Negatives

A false positive is security technology flagging legitimate activity as suspicious. Detection: PowerShell launched with encoded command → alert fires HIGH → investigation reveals the device is IT-ADMIN-01, the account is endpoint-management-service, the script is a corporate software deployment tied to change ticket CHG005872. Legitimate activity, false alarm.

🔮 Predict first

Attackers use PowerShell; administrators use PowerShell. Attackers create scheduled tasks; IT management software creates scheduled tasks. Attackers scan networks; vulnerability scanners scan networks. Given that pattern, what's actually hard about SOC detection work?

Reveal the answer

The genuinely hard part of security operations is separating malicious activity from legitimate administration when both use exactly the same tools and techniques — detections frequently rely on behaviours attackers and defenders both use, so the signal is rarely "this tool ran," it's the surrounding context.

Some teams distinguish a benign positive from a true false positive: the detection correctly identified genuinely suspicious behaviour (say, credential dumping), but there's a legitimate explanation — a penetration test was intentionally running it. The detection worked correctly; the activity just happened to be authorised.

False negatives are generally more dangerous than either: malicious activity occurs, but security tools fail to detect it at all. An attacker steals credentials, logs into Microsoft 365, and the login looks completely normal — no alert fires, and the account stays compromised with the SOC none the wiser. This is exactly why security teams have to keep evaluating their detection coverage rather than assuming "no alerts" means "nothing happened."

6 Alert Tuning & Alert Fatigue

Say a detection for PowerShell using -EncodedCommand generates 2,000 alerts a day, and investigation shows 1,500 of them come from one deployment server. The fix is a precise exclusion (host = SCCM-DEPLOYMENT-01 AND account = svc_sccm AND parent process = ccmexec.exe), never a blanket "ignore all PowerShell alerts" — that would blind the SOC to the exact technique attackers actually use most (Lesson 2 covers this same tuning process from the detection-engineering side).

When analysts receive thousands of meaningless alerts every day, they eventually start ignoring them — alert fatigue. Poorly tuned detection leads to missed important alerts, slower investigations, analyst burnout, growing backlogs, and slower response times overall. This is exactly why modern platforms increasingly correlate related signals into incidents (Section 1 above) instead of presenting every raw telemetry event as its own independent item competing for attention.

7 What Makes a Good SOC Analyst

A strong analyst doesn't memorise alert names — they learn to think. When an alert lands, the internal checklist looks something like: what happened, why did the detection trigger, what evidence supports it, is this normal for this user, is this normal for this device, what happened before and after, what other systems can confirm it, could there be a legitimate explanation, what's the potential impact, do we need containment, and who needs to know? That investigation mindset is worth far more than knowing exactly where a button lives in one specific vendor's console.

Common beginner mistakes go the other way: seeing Malicious IP detected and immediately declaring "we've been hacked," without checking whether the firewall already blocked the connection, whether the threat intel is stale, or whether a security scanner triggered it. Or seeing one Failed login and assuming "brute-force attack" — employees mistype passwords constantly, and one data point is not a pattern. Security analysis is about patterns and context, not single events read in isolation.

8 A Repeatable Investigation Method

Everything above compresses into one mental model worth memorising:

1. Validate — did this actually occur?↓ 2. Understand — what does the alert actually mean?↓ 3. Correlate — what other evidence exists?↓ 4. Scope — which users, devices or systems are affected?↓ 5. Assess impact — what could the attacker access?↓ 6. Contain if required — isolate an endpoint or identity?↓ 7. Escalate — does Incident Response need involvement?↓ 8. Document — record what happened and what evidence supports it

This is the exact eight-step shape you'll use again and again through Lessons 4 and 5 as the log sources and lab scenarios get more specific.

Lesson Outcome

You should now be able to distinguish an event from an alert from an incident, distinguish severity from priority, walk through a basic triage workflow including distinguishing brute force from password spraying, build an investigation timeline, classify false positives/benign positives/false negatives correctly, explain alert tuning and alert fatigue, and apply the eight-step validate-through-document investigation method. Lesson 4 gives you the raw material this method actually runs on: what each major log source looks like and what to look for in it.