SIEM Is Not the Same as Detection Capability

A SIEM collects, stores and correlates log data. Detection capability is the organization’s ability to notice a specific attacker behavior in time to act on it. The first is a platform. The second is an outcome that the platform contributes to, and plenty of well-funded SIEMs deliver very little of it.

The gap matters because the two are often bought, budgeted and reported as one thing. A program can show high log volume, healthy dashboards and a long list of rules while remaining blind to the behaviors that lead to a breach.

What the platform provides, and what is left to do

None of the right-hand column arrives with the license. It is engineering and operating work, and it is the part that decides whether the platform helps.

Five ways a SIEM becomes an expensive log store

1. Ingestion follows availability, not use. Sources are onboarded because they are easy to connect or because an audit asked for retention. A revealing question is what share of ingested volume feeds at least one tested detection. Many teams cannot answer it.

2. Cost pressure removes the wrong sources. Many platforms price by ingestion volume. When costs rise, the verbose sources get trimmed first, and these often include endpoint, DNS and identity audit data, where much of the detection value sits. Cut by value instead: filter in a pipeline, send low-value data to cheaper storage and keep high-value sources fully searchable.

3. Parsing and timing fail quietly. A field that is missing or mis-parsed means a rule never matches, and no error appears. Clock drift and delayed delivery break correlation windows. Neither shows up on a dashboard of events per second.

4. Out-of-the-box rules are left untuned. Untuned rules create noise, and noise trains analysts to ignore the queue. The other response, switching rules off, leaves gaps that nobody records.

5. Migration copies the problems. Moving to a new SIEM by porting every rule and source carries the noise and the blind spots across. Query languages and schemas differ, so ported logic may behave differently, and nobody checks.

Treat telemetry as a supply chain

Each log source is a dependency that detections rely on, and it needs managing like one. A short onboarding record for every source keeps that visible:

• Purpose: which detections need this source.

• Required fields: and a test that they are populated.

• Completeness and latency: what share of events arrives, and how fast.

• Owner: who is told when the source breaks, and who fixes it.

• Retention: for investigation, not only for compliance.

• Health alert: a rule that fires when the source goes quiet.

Cloud platforms illustrate the issue well. Several audit log categories need to be switched on explicitly, and some are held at a cost or license tier. A SIEM connected to a cloud account that is not producing the right audit events looks healthy and sees nothing.

What a good use case looks like

A use case is a detection with its reasoning attached. It names the behavior, the data it depends on, the logic, the expected alert volume, the triage steps, the owner and how it was validated. Writing that down exposes the weak ones early.

A classic correlation rule, such as several failed logins followed by a success, shows why. It is simple and easy to evade. Password spraying uses a small number of attempts per account across many accounts, so a per-account threshold never trips. A rule that looks across accounts from the same source, or at unusual success patterns, fits the technique better. Impossible-travel logic has a different weakness: VPN exit nodes and mobile carriers produce false positives that people learn to dismiss. Neither rule is wrong. Both need context, tuning and a clear response step.

Questions that test whether the SIEM is delivering

1. Which log sources feed no detection at all, and why are we paying to keep them?

2. Which of our priority attacker behaviors have a tested detection, and which have only a rule that exists?

3. When did we last confirm that each critical source is complete and on time?

4. What happens when a source stops sending? Who finds out, and how quickly?

5. What share of alerts from each rule leads to action, and what share is closed without review?

6. If we replaced the platform tomorrow, which rules and sources would we deliberately leave behind?

Platform decisions that follow

Answers to those questions often point to the work before a purchase. A security data pipeline can filter, enrich and route events before they reach the SIEM. Tiered storage can hold lower-value data at lower cost. A dedicated detection engineering practice can own use-case quality. SOAR and XDR can take on response and endpoint correlation. Each helps only when the use-case discipline is in place.

The same applies to outsourcing. A managed detection service works from the telemetry it is given, and weak data limits what it can find. Replacing a SIEM rarely cures a missing process. It tends to move the same gaps to a new console. A short assessment of data sources, use cases and health usually costs less than a migration and shows whether the platform or the practice is the constraint.

Where to start

Take your ten highest-volume sources and map each to the detections that depend on it. Mark any that feed none. Then take your five most important attacker behaviors and trace each to a rule, its required fields and its last successful test. The result is a plain picture of where the platform earns its cost and where it only stores data.