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

Source
Telemetry
Ship
Absorb
Retain
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

Official documentation