SOC Operations
Intermediate 17 min read SOC Operations
Telemetry and Logging for Security
Engineer the sources that give you evidence: what to log, at what level, with what content, and how to keep logs trustworthy and affordable.
loggingtelemetryEDRaudit eventslog contentretentionchains
Introduction
What is this?
Security telemetry is the set of log and event sources — OS, network, identity, cloud, EDR — sized, structured, and retained to answer 'what happened'.
Motivation
Why do you need it?
- An incident without logs is a guess; the entire SOC method collapses without evidence.
- Log content is engineering: you decide what facts the future responder gets by what you collect today.
- Retention is compliance currency — the audit asks 'show me the 90-day window' and files speak.
Think about it
Mental model
Imagine
A dashboard camera
Think of
One that only records while the engine is on and the road is clear
The useful camera always records the moment before the crash, not after you decide it matters.
Mechanics
How it works
- Sources: auth/identity logs, OS process audit, network/flow logs, DNS, cloud control-plane, and EDR agent events.
- Each source is structured (JSON-ish) with timestamp plus the 'who/what/when/where' facts that make queries pay off.
- Access/retention: logs land in append-only stores read by least-privilege analysts and immutable for evidence periods.
- Correlations only see what is collected — pruning a field today hides the pivot that tomorrow's incident needed.
From event to evidence
SourceOS/network/identity/cloud
Telemetrystructured events, key fields
Shipappend-only to SIEM/store
Absorbqueries reconstruct the story
Retaincompliance window, immutable
Real world
In production
- A company ships login events with device + geo, so a 3am login from a new country is a query, not a mystery.
- An EDR agent captures process-exec chains, turning 'malware ran' into 'it was spawned by Outlook, from this attachment'.
- A compliance team keeps 400 days of immutable auth logs and passes the SOC2 sampling check easily.
Guidelines
Best practices
- Log auth failures AND successes; the sober difference is the crux of legitimate-triage.
- Include stable IDs (user, asset, session, parent-process) not just a message string.
- Ship to an append-only store with integrity (hash chain or object lock) as the evidence trust base.
- Review log sizes quarterly: drop noise, never drop the fields that answer 'who did what'.
Watch out
Common mistakes
- Logging everything at debug in dev but nothing in prod for fear of disk.
- Truncating or redacting the very fields (source IP, username) incident response needs most.
- Authorizing 'log readers' to delete the evidence by default — a policy that costs a case.
- Assuming the cloud provider logs for you: most cloud events need explicit trail/monitor shipping.
When things break
Debugging tips
- Test your pipeline end-to-end with a known event (e.g. a logon you trigger) and confirm the field survived.
- When an incident timeline has no logs, check retention/config drift — the gap is a finding in itself.
- Museums of sample logs aren't evidence; keep the real timestamp real.
Security
Security considerations
- Logs hold PII and credentials-in-URLs: mask at ingestion but keep the discriminator fields.
- The log store is a sensitive system: least privilege AND immutable append is the dual lock.
- An attacker who can edit your logs can delete the evidence of their presence — integrity-preserve first.
Interviews
Interview checkpoint
Test yourself
Quick quiz
0/2
1
The most future-proof field to keep in a security log is...
2
Immutable append is important because...
Go deeper