SIEM and the Art of Useful Logging
Every security team eventually buys a SIEM, and a surprising number end up with an expensive log warehouse that detects nothing. The tool is rarely the problem. The problem is the belief that centralising logs is detection — that if you collect enough, insight emerges on its own. It doesn't. A SIEM turns logs into detection only when someone decides, deliberately, what a real attack looks like in those logs and writes it down.
A SIEM does three jobs: collect events from across the estate, normalise them into a common shape so a Windows login and an Okta login can be compared, and correlate them against rules that fire when a pattern matches. Teams pour effort into the first, tolerate the second, and neglect the third — which is exactly backwards, because correlation is the only part that produces detections.
Collect for a question, not for the archive
The instinct to "log everything" comes from a good place and produces a bad outcome: a bill that scales with volume and a signal-to-noise ratio that trends toward zero. Better teams invert it. They start from the detections they want — credential abuse, lateral movement, data staging — and ingest the log sources those detections need, at the fidelity they need. Debug logs from a service nobody attacks are cost; authentication, process creation, and network flow logs are the sources most detections are actually built on.
Normalisation is the boring part that decides everything
Correlation across sources only works if a "user," a "source IP," and a "host" mean the same thing whether they came from a firewall, an identity provider, or an endpoint agent. When normalisation is sloppy, cross-source detections — the ones that catch a real intrusion moving through your environment — simply cannot be written, because the fields don't line up. This unglamorous mapping work is what separates a SIEM that correlates from one that just stores.
- Map your sources to a detection framework. Lay your log sources against MITRE ATT&CK and the gaps are obvious: whole technique columns with no source feeding them are attacks you literally cannot see.
- Tier your data. Hot, searchable storage for the sources detections run on; cheaper cold storage for the compliance logs you’ll only ever need in an investigation. One retention tier for everything is how SIEM bills spiral.
- Write detections as code, review them, version them. Rules that live only in the console drift, break silently, and vanish when someone leaves. Treat them like the software they are.
- Measure rules by true positives, not by count. Five hundred rules that never fire usefully are worse than twenty that catch real activity — they bury the signal and exhaust the analysts.
- Pick one attack technique you care about — say, credential dumping — and ask which log source would show it and whether that source is actually ingested. If the honest answer is ‘we’d have to check,’ you have a blind spot, not a detection.
- Sample a day of alerts and count how many an analyst would call actionable. A low ratio isn’t an analyst problem; it’s a rule-tuning problem, and it’s training your team to close tickets without looking.
Mapping log coverage to real attacker techniques, closing the source gaps, and tuning rules so alerts mean something is ongoing detection engineering — the discipline our assessment and SecStudio agents bring to your telemetry.
A SIEM is infrastructure, not a detection strategy. The tool will faithfully store whatever you send it and fire whatever rules you write; both of those are decisions you make, not features you buy. Get deliberate about which questions your logs must answer and the SIEM becomes what it was meant to be — the place an intrusion becomes visible. Ignore that, and it becomes the most expensive way to not notice a breach. You can only detect in the telemetry you thought to collect.