Detection in Technicolour: Finding the Gaps Your Dashboard Cannot See
No ratings
Presented at BSides Tallinn 2026 by
Security teams measure what their detection systems produce: alerts, incidents, false positives, response times, and technique coverage. These metrics are useful, but they describe only what became visible. They tell us much less about telemetry that was never generated, never collected, rejected during parsing, stripped of context during normalization, or delivered too late to support a detection. Dashboards make this limitation easy to overlook. They show ingestion rates, parser success, rule activity, and correlation volume in reassuring colour. Yet a high parse-success rate excludes anything rejected before the parser recorded it. Low ingestion latency does not tell us whether the right events were collected. A rule that fires regularly may be healthy, or it may simply be seeing the small part of the environment that still produces usable evidence. We often use measures of pipeline activity as evidence of detection coverage. Every detection system works within a blindness budget. Collection capacity is finite. Parsing accuracy requires engineering effort. Longer retention consumes storage that might otherwise support faster access or broader collection. Near-real-time detection often acts on incomplete evidence. Correlation depends on fields retaining stable meaning after they have passed through several systems. A decision that appears reasonable at one stage can remove options from the next, with no visible failure until a detection is missed. This talk follows security telemetry through a production SIEM stack, from generation and collection to parsing, normalization, storage, correlation, hunting, and detection. It brings together three views that are usually discussed separately: the architect deciding where state, trust, and failure boundaries belong; the developer implementing the pipeline and its instrumentation; and the detection engineer depending on that pipeline to preserve enough evidence for a rule to work. Looking at the same system from all three perspectives exposes failures that remain hidden when each layer is assessed in isolation. Missing telemetry is only one part of the problem. Analysts adapt to the alert streams they receive. When false positives and repetitive alerts dominate, dismissal becomes a rational response to limited attention. Rules continue to fire, but trust declines. Investigations become shallower, and alerts remain open without meaningful action. Too little evidence and too much noise reach the same operational result through different mechanisms. The talk uses six working categories for examining missed detections: collection gaps, parsing gaps, data-quality failures, semantic loss, correlation failures, and detections that never received enough evidence to fire. The boundaries are not always clean. A malformed event may appear to be a parsing problem, a schema problem, or a collection problem depending on where measurement begins. The useful question is not which label fits best, but where the evidence disappeared and whether the pipeline can demonstrate that it was present. Attendees will see how to assess telemetry freshness, parser health, schema completeness, ingestion delay, correlation readiness, unknown-event rates, rule dependencies, orphaned rules, and signs of analyst fatigue. These measurements do not produce a complete account of detection quality, but they expose failures that conventional SOC dashboards usually hide. The question is not whether the pipeline is active. It is whether enough of the right evidence survives the pipeline to detect anything that matters.