Module 1 · SOC Fundamentals 🔒

A Security Operations Centre (SOC) is the team that watches alerts, investigates suspicious activity, and coordinates response when something breaks. Whether it runs 24×7 from a dedicated floor or one analyst juggling Slack notifications, the job is the same: detect, triage, escalate, respond. This module covers the tiered analyst model, the triage workflow that keeps alert queues from drowning the team, and the operational rhythm of a functional SOC.

Why the tiered model exists

Every SOC drowns in alerts. A mid-size Indian SaaS with decent tooling easily sees 2000–8000 alerts per day across EDR, SIEM, cloud, email gateway, and identity. You cannot investigate each of them to root cause. You need a filter: fast triage up front, deep work only on the handful that actually matter. The tiered model is that filter.

It also solves a staffing problem. Senior analysts are scarce and expensive. Juniors are abundant and need growth paths. Tiering lets you route volume work to Tier 1 while reserving Tier 2 and Tier 3 for the hard problems — and gives juniors a clear ladder.

The three-tier model

Tier 1 — Alert Triage

• Goal: close or escalate every alert within SLA (typically 15–30 minutes for critical)
• Work: validate the alert is real, gather immediate context, decide “false positive → close” or “real → escalate to T2”
• Tools: SIEM dashboard, EDR console, email gateway, ticketing system
• Skills: pattern recognition, runbook execution, calm under queue pressure
• Experience: 0–2 years. First cybersecurity role for most

Tier 2 — Incident Response

• Goal: investigate escalated alerts to scope and root cause; drive containment
• Work: deep log analysis, correlating events across systems, coordinating with IT/engineering to contain, writing incident reports
• Tools: SIEM advanced search, threat intel platforms, forensic tools (Autopsy, Volatility), network capture (Wireshark, Zeek)
• Skills: investigative mindset, strong writing, understanding of attacker TTPs
• Experience: 2–5 years. Often promoted from T1

Tier 3 — Threat Hunting & Engineering

• Goal: find what the detection tools missed; build new detections; handle the hardest cases
• Work: hypothesis-driven hunting, reverse engineering malware, writing Sigma/YARA rules, tuning SIEM, red-team collaboration
• Tools: everything above plus sandbox, disassembler, threat intel APIs, custom scripts
• Skills: adversary simulation understanding, scripting (Python/PowerShell), detection engineering
• Experience: 5+ years. Specialists

Small SOCs (under 6 analysts) often collapse T2 and T3 into one role. That is fine — the ladder is conceptual, not a headcount prescription.

The triage workflow

Every alert walks through the same decision tree. Make it explicit so Tier 1 is not improvising each time.

ALERT RECEIVED
  │
  ├─ Is the source asset in scope? (Prod? Sensitive data? Known test box?)
  │    NO  → close as out-of-scope; tag for tuning
  │    YES → continue
  │
  ├─ Is this a known false-positive pattern? (documented suppression)
  │    YES → close with suppression link; update suppression stats
  │    NO  → continue
  │
  ├─ Enrich: user context, asset context, recent activity, threat intel hits
  │
  ├─ Apply runbook for this alert type
  │    │
  │    ├─ Runbook says "benign explanation found" → close with notes
  │    ├─ Runbook says "escalate" → create incident ticket, assign to T2
  │    └─ Runbook says "contain immediately" → execute containment, then escalate
  │
  └─ Document decision in ticket (even closures). Future-you will thank you.

What “enrichment” actually means

Enrichment is the 2–5 minutes where you turn a raw alert into something decidable. Concretely:

• User context: who owns this account? Active employee? Recent role change? On vacation? (HR/HRIS integration helps)
• Asset context: prod or dev? Which business unit? What data does it hold? (CMDB helps)
• Recent activity: is this user/asset showing related anomalies in the last 24h? (SIEM pivot)
• Threat intel: is this IP/domain/hash on known-bad lists? (TIP integration)
• Historical base rate: how often does this alert fire for this user/asset? Is today’s instance unusual?

If your Tier 1 cannot answer these in under 5 minutes, your tooling is not integrated enough — that is an engineering problem, not an analyst problem.

The SLA that actually matters

Most SOCs track mean time to detect (MTTD) and mean time to respond (MTTR). Useful, but what matters operationally is mean time to triage — how long a fresh critical alert sits in the queue before a human looks at it. Target: under 15 minutes during business hours, under 30 minutes after hours. If it drifts beyond that, you are either understaffed or drowning in noise.

Shift patterns for 24×7 coverage

Indian SOCs running 24×7 typically use one of:

• 3 × 8-hour shifts: standard. Requires 4–5 analysts per tier to cover weekends, leave, and training
• 2 × 12-hour shifts with follow-the-sun: one India team covers 08:00–20:00 IST, handoff to a partner SOC (often US/Europe) for the rest
• Business hours + on-call: small teams. One person on-call with paging thresholds tuned tightly

For a startup under 100 staff, business-hours-plus-on-call is almost always the right starting point. 24×7 is expensive and most incidents either wait safely until morning or are severe enough to page someone regardless of hour.

Key metrics to track

1. Alert volume by source — identifies noisy rules that need tuning
2. Mean time to triage — the operational health signal
3. True-positive rate per rule — below 5% means the rule is too broad
4. Escalation rate — T1→T2 escalations as % of triaged alerts. Healthy: 2–8%
5. Incidents closed by root cause category — drives training and tooling priorities
6. Analyst workload balance — no analyst should handle >3x the median queue

Runbooks are the multiplier

A SOC without runbooks is a SOC where every analyst solves every problem from scratch. A SOC with good runbooks is one where a Tier 1 with six months of experience can close 80% of alerts without escalating. Write one runbook per alert class. Minimum contents:

• What this alert means (in plain language)
• Common false-positive causes
• Enrichment steps (specific queries, URLs, tools)
• Decision criteria: when to close, when to escalate, when to contain first
• Containment actions for this alert class
• Link to the detection rule so analysts can see logic

Treat runbooks as living documents. Every time an alert gets escalated and the answer turns out obvious in hindsight, update the runbook.

The India-specific layer

Operating a SOC in India adds a few constraints worth planning for:

• DPDP obligations: personal data breaches require Board notification within 72 hours (as of the DPDP Act 2023). The SOC is often where that clock starts. Triage workflow must flag “personal data potentially affected?” as a decision point, and escalation to Legal must happen within the first investigation hour, not discovered on day three
• Regulatory overlap: if you process financial data, RBI cyber-security directives may also trigger. SEBI has its own. Sectoral overlays stack
• Time zones: most SaaS vendors are US-west. Their support teams are asleep during IST business hours. Build this into runbooks — know which vendor has India-hours coverage and which you will wait on
• Talent market: aggressive poaching of T2/T3 analysts is normal. Budget for 20–25% annual attrition and build runbooks/documentation so departures do not cripple the team

Getting started without a SOC

If you do not have a SOC yet and are reading this to decide whether to build one, the honest answer is usually: start with one security engineer, not a SOC. Have them set up logging, basic detection, and an on-call rotation. Only when alert volume exceeds what one person can triage in their work week does tiering start to earn its overhead. Most Indian startups under 200 employees are better served by an MSSP (managed SOC service) than an in-house team — the fixed cost of 24×7 staffing rarely pencils out under ~500 employees or ~₹50 crore revenue.

What the next modules cover

SOC fundamentals are about structure. The next modules fill in the tooling depth: SIEM (how logs flow and get correlated), detection engineering (how rules are written and tuned), EDR (what the endpoint sensor actually sees), and malware triage (what to do with the binary your T2 just extracted from a phishing email). Each builds on the triage workflow above. Get that workflow right first — without it, better tools just generate more alerts you cannot act on.