Soc Analyst

SOC Analyst

When to Use

• Triage and investigate SIEM, EDR, email, cloud, and identity alerts
• Execute tier-1/tier-2 playbooks and document findings
• Enrich alerts with threat intel, asset context, and user/account data
• Close benign or true-positive-with-remediation alerts per runbook
• Escalate to CSIRT when incident criteria are met

When NOT to Use

• Declare incidents, lead containment, or draft regulatory comms → incident-responder
• Design SEV levels, on-call, paging, or postmortem program → incident-management-engineer
• Plan or execute red team campaigns (operator role) → red-team-specialist
• Implement SIEM/EDR or IAM controls → information-security-engineer
• Hypothesis-driven threat hunts and hunt campaigns → threat-hunter
• Disassembly, decompilation, patch diff, or malware RE lab work → reverse-engineer

Related skills

Handoff to threat hunting

Escalate to threat-hunter when alerts cluster into a plausible campaign, detections are evasive, leadership requests a proactive hunt, or post-incident pattern expansion is needed. Include UTC window, entities, IOCs, what was ruled out, and linked tickets.

Handoff to CSIRT

Escalate to incident-responder when incident declaration criteria are met (see incident-responder/references/incident_declaration_and_severity.md). Include UTC timestamps, affected entities, IOCs, evidence links, and open questions. Confirmed compromises found during hunts also route through this path.

Alert triage and classification

Table of contents

1. Triage sequence 2. Severity matrix 3. Incident categories 4. False positive handling 5. Escalation triggers

Triage sequence

Execute in order; do not skip validation for noisy rules.

1. Acknowledge — claim case; start SLA clock 2. Normalize — extract entities (user, host, IP, hash, domain, process) 3. Enrich — asset owner, criticality, recent similar alerts 4. Decide — FP / benign TP / TP requiring investigation 5. Classify — severity + category + scope count 6. Act — playbook, monitor, or escalate

Severity matrix

Align to org SEV definitions (incident-management-engineer). Default mapping:

Customer impact and data class override raw alert priority.

Incident categories

Use one primary category per case for reporting:

False positive handling

Document before close:

• Detection or rule ID
• Why benign (maintenance, known tool, expected admin, mis-tuned threshold)
• Proposed tuning (threshold, enrichment, time window, scoped allowlist)
• Expiry date for any allowlist
• Approver for changes affecting critical ATT&CK techniques

Never permanently suppress high-fidelity techniques without detection review.

Escalation triggers

Escalate immediately when any apply:

• Executive or break-glass account involved
• Regulated or restricted data (PHI, PCI, export-controlled)
• Lateral movement or scope unknown beyond 10 hosts/users
• Active C2 or encryption of production data
• Legal, regulatory notification, or external comms may be required
• Playbook has no approved branch for observed behavior

Package escalation: 2-line executive summary, timeline link, IOC list, actions taken, open questions.

Containment, escalation, and handoff

Table of contents

1. Containment recommendations 2. Approval matrix 3. Escalation paths 4. Shift handoff template 5. Evidence preservation

Containment recommendations

SOC recommends; IR or designated approver authorizes unless runbook grants auto-approve.

List order of operations in recommendation (e.g., snapshot → isolate → block IOC).

Approval matrix

If approver unavailable, escalate to IR lead—do not delay SEV1 containment waiting on business hours unless policy requires.

Escalation paths

Shift handoff template

Post in handoff channel at shift end:

## SOC handoff — [DATE] [SHIFT]

### Open P1/P2
- [CASE-ID] — severity — one-line status — owner — next action — blocker

### Watch list (monitoring)
- [CASE-ID] — why watching — expire time

### Tuning in flight
- [TICKET-ID] — rule ID — FP pattern

### Queue health
- Backlog count — oldest unassigned age

### Notes for next shift
- Maintenance windows, known noisy rules, staffing gaps

Require verbal read-back for any SEV1 or active containment case.

Evidence preservation

Before destructive containment when policy allows:

1. Export relevant SIEM searches (time-bounded) 2. EDR investigation package or snapshot 3. Identity sign-in export for affected users 4. Hash of exported bundles stored in case

Document who exported, when UTC, and storage location (case folder ID).

Detection feedback and metrics

Table of contents

1. Tuning feedback format 2. SOC metrics 3. Weekly detection review 4. Anti-patterns

Tuning feedback format

Open a tuning ticket for every repeatable false positive or noisy rule:

Detection engineering owns implementation; SOC owns signal from the floor.

SOC metrics

Track at team level (daily or weekly dashboard):

Slice metrics by source, category, and tier to find systemic issues.

Weekly detection review

Standing agenda (30–60 min):

1. Top 5 noisy rules by volume 2. New true positives worth promoting to higher fidelity 3. Open tuning tickets — owner and ETA 4. Missed activity (if any) from IR postmortems 5. Playbook gaps discovered on shift

SOC lead presents; detection engineering commits to change or documents risk acceptance.

Anti-patterns

Avoid:

• Global suppressions without expiry on credential theft or C2 techniques
• Closing without category — breaks metrics and IR reporting
• Silent queue drops — every alert gets disposition
• Analyst-only containment outside runbook without ticket
• Tuning via personal filters — changes must be team-visible and reviewed

Improve detections through documented feedback, not individual queue hacks.

IOC enrichment and investigation

Table of contents

1. IOC types and handling 2. Enrichment sources 3. Correlation queries 4. Timeline construction 5. Investigation depth by tier

IOC types and handling

Record confidence (high/medium/low) per IOC in case notes.

Enrichment sources

Use org-approved sources only:

• Internal — CMDB, asset tags, data classification, recent changes
• SIEM — historical prevalence, peer alerts, peer entities
• EDR — process tree, network connections, file operations
• Identity — sign-in logs, risky sign-in, MFA events, app consents
• Email — message headers, delivery path, similar campaigns
• Cloud — CloudTrail/Audit Logs, IAM changes, storage access
• Threat intel — feeds integrated in SIEM; cite feed name and score

Do not paste full TI reports into customer-visible tickets; summarize in case.

Correlation queries

Minimum pivots for true positives:

1. Same user — auth, cloud, proxy, email (24–72h) 2. Same host — EDR, local logons, outbound connections 3. Same IOC — other hosts/users hit (prevalence) 4. Parent process — if execution alert, trace parent and child

Stop correlation when runbook depth reached; hand off breadth to defensive-security-analyst.

Timeline construction

Required fields per event:

Order chronologically; mark first malicious and last observed activity.

Investigation depth by tier

Preserve chain of custody: export raw logs to secure case folder per policy.

SIEM and SOAR playbooks

Table of contents

1. Playbook principles 2. Standard playbook stages 3. SOAR case hygiene 4. Approved automation 5. When to stop automation

Playbook principles

1. Human decision at branches — automation gathers; analysts approve destructive steps 2. Idempotent steps — safe to re-run enrichment without duplicate blocks 3. Evidence first — export logs/snapshots before isolate or disable when policy requires 4. Mapped to category — each playbook names severity default and escalation path 5. Versioned — cite playbook ID and version in every case note

Standard playbook stages

SOAR case hygiene

Every case must include:

• Title — [Category] — primary entity — short behavior
• Timeline — append-only notes with UTC timestamps
• Evidence links — SIEM search IDs, EDR investigation URLs (no secrets in title)
• Owner and tier — T1/T2/T3 at time of handoff
• Related tickets — IR, IT, cloud, legal as applicable

Update status when waiting on: approver, customer, engineering, or legal.

Approved automation

Typical auto-actions (confirm against org runbook):

Require secondary approval for org-wide blocks, production service accounts, and executive users.

When to stop automation

Halt SOAR and escalate manually when:

• Playbook branch missing or confidence below threshold
• Blast radius unclear (cloud org, IdP tenant, >10 assets)
• Destructive action could interrupt revenue-critical system
• Alert storm — possible detection bug or attack in progress at scale
• Legal hold or law enforcement involvement mentioned

Log automation halted reason in case; do not force-close as FP during storms.

SOC analyst scope

Table of contents

1. Role boundary 2. Tier model 3. Partnership model 4. What good looks like

Role boundary

SOC operates the detection and response floor; it does not own security program design or infrastructure build-out.

Tier model

Tiers are skills, not titles—document who owns the case at handoff.

Partnership model

What good looks like

1. Every true positive has a UTC timeline with cited sources 2. False positives exit with a tuning ticket, not silent suppression 3. Playbook actions are logged and approved per policy 4. Shift handoff is written—no verbal-only transfer of SEV1–2 cases 5. Metrics improve: lower FP rate, stable time-to-triage, fewer reopen loops