Data Science for Security Operations
Security operations is a data problem wearing a badge: terabytes of logs, flows, and alerts, a handful of humans, and adversaries hiding in the ratio. It's also where naive data science goes to die — because the base rates are brutal, the labels are scarce, and every false positive spends an analyst's hour. This part is the field guide.
The base-rate wall
Start from the arithmetic in Part 4: if truly malicious events are one in ten thousand, a detector with 99% precision-sounding accuracy still buries the SOC in false alarms. Every design decision flows from this: optimize precision at a fixed, budgeted alert volume — "our analysts can investigate 40 alerts a day; make those 40 count" — rather than chasing recall in the abstract. An alert queue is a ranking problem, not a classification problem.
Features beat algorithms here
The wins come from representing behavior, not from exotic models:
- Aggregates per entity per window: logins per user per hour, unique destinations per host per day, bytes out vs. that host's own trailing baseline.
- Rarity features: first-time-ever pairs (this user, this country; this host, this port) — "new" is the most underrated signal in security.
- Time-of-day and cadence: humans are diurnal and sloppy; beacons are periodic and precise. A near-perfect 60-second heartbeat is a machine talking to its handler.
- Peer deviation: compare each entity to its cohort (developers vs. finance), not to a global average that nobody resembles.
Unsupervised where labels don't exist
You rarely have labeled attacks; you always have mountains of "probably normal." Isolation Forests and simple per-entity baselines (median + MAD, robust to the heavy tails everywhere in network data) surface the weird cheaply. Two honest warnings: anomalous ≠ malicious (the payroll run is anomalous every second Friday), so unsupervised output feeds triage, never auto-blocking; and normal drifts (see Part 10), so baselines must re-fit on a schedule.
Where supervised and LLMs fit
Supervised models shine where labels accumulate naturally: phishing (reported emails), malware (sandbox verdicts), fraud (chargebacks). Analyst dispositions — true/false positive on every closed alert — are a free label stream; feed them back and the ranking model compounds. LLMs (Part 8) earn a place at the triage layer: summarizing an alert's context, drafting the timeline, translating a query into the SIEM's language — always as the analyst's clerk, never as the decision-maker, and mindful that attacker-controlled text in logs is prompt-injection surface.
The engineering substrate
Security data science is 80% pipeline: parse logs to typed columns (Parquet, not gzipped text), normalize timestamps to UTC at ingest, sessionize flows, and make everything queryable (DuckDB locally, the SIEM or a lake at scale). Model quality is capped by how honestly the data is plumbed — Part 3's disciplines, at hostile volume.
Evaluating a detector like an adult
- Backtest on time-based splits — training on Friday to detect Tuesday is leakage with a clearance.
- Report precision@k (k = daily alert budget), time-to-detect, and analyst feedback rate — not ROC-AUC alone, which flatters everything at these base rates.
- Red-team your own features: which ones can an adversary who read your blog trivially evade? Rarity and cadence features degrade gracefully; signature-like features snap.
Checkpoint
Take a week of any log you own (auth, DNS, web). Build per-entity hourly aggregates, flag first-ever events and top deviations-from-self, and rank the top 20. Triage them honestly. The ones that made you look twice — that's your precision, and your resume.