SOC Architecture, Analyst Tiers & the Alert Lifecycle

Prerequisites

• FND-K001: CIA Triad & the Modern Threat Landscape
• FND-K004: OS Fundamentals

Why This Lesson Matters

Every security tool — SIEM, EDR, NDR, SOAR — feeds into a Security Operations Centre. Understanding how a SOC is organised, how alerts flow through it, and what is expected of each analyst tier prevents the most common early-career failure: escalating or closing the wrong alerts.

1. SOC Architecture

A mature SOC has four functional layers that work together:

┌───────────────────────────────────────────────────────┐
│  Layer 4 — Management & Governance                    │
│  SOC Manager · KPIs · SLA reporting · budget          │
├───────────────────────────────────────────────────────┤
│  Layer 3 — Threat Intelligence & Hunt                 │
│  CTI analyst · proactive threat hunting · rule tuning │
├───────────────────────────────────────────────────────┤
│  Layer 2 — Incident Response                          │
│  Senior analysts · escalated incidents · forensics    │
├───────────────────────────────────────────────────────┤
│  Layer 1 — Alert Monitoring (you start here)          │
│  L1 analysts · alert queue · triage · escalation      │
└───────────────────────────────────────────────────────┘
        ↑  feeds into  ↑  feeds into  ↑  feeds into
  SIEM · EDR · NDR · Firewall · Email gateway · Cloud logs

1.1 Tier Responsibilities

An L1 analyst is not expected to fully investigate every alert — they are expected to make a correct triage decision quickly and escalate when appropriate.

1.2 Data Sources Feeding the SOC

2. The Alert Lifecycle

Every alert follows the same lifecycle from creation to closure:

SIEM rule fires
      ↓
  New (unacknowledged)
      ↓
  Acknowledged — analyst owns it
      ↓
  Under investigation
      ↓
  Triage decision
      ├── False Positive → close + tune rule
      ├── True Positive (Low) → close + document + IOC extract
      └── True Positive (High/Critical) → escalate to L2 / IR

2.1 Triage Decision Framework

For every alert, answer four questions in order:

1. Is the triggered rule actually applicable to this event? Read the detection logic. Does the event match what the rule is designed to catch?

2. Is the behaviour expected in context? A PowerShell script in an IT admin's session is different from the same script spawned by a Word document.

3. What is the CIA impact if this is real? Confidentiality (data access)? Integrity (system modification)? Availability (service disruption)?

4. Is there corroborating evidence in other sources? One event rarely confirms a compromise. Look for the chain.

2.2 SOC Metrics

Dwell time is the most important metric to drive down. An attacker who has been present for 16 days has had time to establish multiple persistence mechanisms, exfiltrate data, and move laterally. Detection at day 1 limits the blast radius dramatically.

3. Severity Classification

Consistent severity labelling allows SLA management and appropriate resource allocation.

3.1 Common Classification Errors

Under-classifying: Treating a confirmed credential dump as P3 because "we haven't seen lateral movement yet." Lateral movement may be the next event.

Over-classifying: Treating every PowerShell execution as P1. This causes alert fatigue — analysts begin ignoring P1 alerts because they are always false.

Context blindness: An alert fires during a known maintenance window but the analyst closes it as FP without checking whether the rule was expected to be suppressed.

4. Alert Fatigue and Why It Kills Security Programmes

Alert fatigue is the desensitisation of analysts caused by consistently high volumes of low-quality alerts. It is not a technology problem — it is a process and tuning problem.

Consequences: - Real threats are dismissed as false positives - Analysts leave the SOC (high turnover rate in L1 is an industry-wide problem) - The organisation invests in more tools that generate more alerts

Remediation: - Tune detection rules aggressively — every FP must be investigated and the rule adjusted - Use risk scoring (UEBA) to prioritise the queue — not all P3s deserve equal attention - Build baselines before alerting — a rule that fires on "first-seen process" is useless without a baseline of normal processes

5. Common Mistakes

Mistake 1: Closing an alert without documenting the evidence examined. If the alert turns out to be a TP weeks later, there is no record of what the analyst saw. Always document: what log entries you examined, what they showed, and why you concluded FP.

Mistake 2: Escalating every uncertain alert to L2. L1 should resolve uncertainty by gathering more evidence. Escalation is for confirmed or highly-suspected TPs, not for "I'm not sure."

Mistake 3: Not updating the ticket when new related events arrive. A second alert from the same host or user 20 minutes later may change an FP into a TP. Monitor related activity after closing an alert.

6. Practice Exercises

1. You receive an alert: "Encoded PowerShell executed — host: WS-042, user: bob, time: 14:32 UTC." Walk through the four triage questions and describe what additional evidence you would collect before making a decision.

2. Calculate MTTD: an attacker phished an employee at 09:00, installed malware at 09:15, and the first SIEM alert fired at 11:47. What is the MTTD? Is this acceptable for a P1 incident?

3. Your SOC has a 45% false positive rate on the "Suspicious Outbound DNS" rule. Propose two specific tuning actions that would reduce FPs without removing legitimate detections.

7. Lab

Assessment mode: quiz

Scenario-based quiz: 8 alerts with full context (event logs, timestamps, user/host info). For each alert: - Assign a severity (P1–P4) - Make a triage decision (FP / TP-Low / TP-High) - Identify the primary CIA impact

A score of ≥ 75% is required to pass.

8. Framework Alignment

9. Further Reading

• SANS SOC Survey (annual) — Industry benchmarks for SOC metrics and tooling
• MITRE ATT&CK Defender (MAD) — SOC-specific ATT&CK training programme
• "The Practice of Network Security Monitoring" — Richard Bejtlich — The foundational NSM book
• Google SRE Book — Chapter on On-Call — Directly applicable escalation and incident severity concepts

["Describe the four-tier SOC structure and the primary responsibility of each tier", "Apply the four triage questions to a given alert to reach a correct FP/TP classification", "Calculate MTTD and MTTR from a provided incident timeline and assess them against industry benchmarks", "Explain what alert fatigue is, why it is dangerous, and propose two concrete mitigation actions"]

Prerequisites → Why this matters → SOC architecture (4-layer diagram, tier responsibilities, data sources) → Alert lifecycle (state machine, triage framework) → SOC metrics (MTTD/MTTA/MTTR/dwell time) → Severity classification (P1-P4 with examples, common errors) → Alert fatigue (causes, consequences, remediation) → Common mistakes → Practice exercises → Quiz lab → Framework alignment → Further reading