Security Telemetry Quality and Blind Spots
Evaluate whether security telemetry has the coverage, context, timing, and stability needed for investigation and detection.
Quality is fitness for a decision
High event volume is not the same as useful telemetry. Define the investigation or detection decision, then test whether the data represents the necessary behavior with sufficient context, timeliness, and retention.
Quality is purpose-specific. Aggregated network counts may support capacity planning but not connect an action to a process; a rich endpoint event may arrive too late for containment. For each use case, name the behavior, entities, fields, acceptable delay, retention window, and decision owner. This creates a service expectation that can be measured and prevents “we collect those logs” from substituting for proof that the evidence works.
Map coverage and vantage point
Record which systems can observe an action and which cannot. Endpoint, identity, network, email, DNS, cloud, and application sources expose different parts of the path. A blind spot should name the missing behavior and affected decision.
Draw the action path from initiator through identity, application, infrastructure, and target resource, then place sensors at their real vantage points. A firewall may see a connection but not the authenticated user; an identity provider may see token issuance but not later local authorization. Record populations, versions, exclusions, encrypted paths, unmanaged assets, and collection boundaries. Coverage percentages without a defined denominator can hide entire environments.
Preserve time and identity
Normalize clocks without discarding original timestamps. Retain stable identifiers and their scope, such as tenant, host, process, user, session, or request. Names and IP addresses often change or are reused.
Preserve event time, ingestion time, source time zone, clock offset, and timestamp precision. Know whether a process ID is unique only until reboot, a logon ID only on one host, or an account name across several directories. Maintain mappings over the period needed for investigation. Normalize copies for correlation while retaining raw values; otherwise a parser correction or daylight-saving issue can make the original sequence impossible to reconstruct.
Classify missing data
Distinguish true absence from unavailable, delayed, filtered, malformed, or expired data. Each state supports a different conclusion. Do not turn a collection failure into evidence that activity did not occur.
Use explicit states in queries and reports. “No matching event in source S for window T” is defensible only when S covered the asset, the sensor was healthy, the query represented the behavior, and retention included T. Track late arrivals, dropped batches, schema violations, license or cost filters, and access failures. Corroborating sources may reduce uncertainty, but they do not retroactively make the missing source complete.
Monitor the evidence pipeline
Track schema changes, ingestion delay, parser failures, cardinality, field completeness, and sample events. A CTI data pipeline and a security telemetry pipeline both need provenance, correction, replay, and accountable ownership.
Use synthetic or known-good events to test the path end to end, not just whether the collector process is running. Alert on silence where activity is expected, unexpected volume changes, parsing to null, timestamp drift, and loss of key identifiers. Version source contracts and parsers, retain raw data where proportionate, and make replay safe. A correction should identify which detections, investigations, and reports used faulty data so their conclusions can be reviewed. Publish data-health status beside analytic results so responders can distinguish “no suspicious event observed” from “the required evidence did not arrive.”
