How does a log source work?

What a log source does in a security stack

A log source is the origin point for events that security teams need to see, store, and analyse. In practice, it is the system that emits records, the collector that forwards them, and the analytics platform that turns them into searchable telemetry. A source only becomes useful when its events are consistently structured, time aligned, and mapped to the detections you actually care about.

That is why log sources are not just inventory items. They are part of your detection coverage model: each one expands visibility into a specific process, boundary, or workload. If the source is incomplete, delayed, or poorly normalised, the downstream analysis may still run, but the conclusions become weaker and less trustworthy.

For SIEM programs, source quality matters as much as source count. A well-onboarded source produces fields that can be queried reliably, supports correlation across systems, and helps separate genuine security events from operational noise. SIEM Guide

Why onboarding and normalisation determine whether the source is actually useful

A source is not really “working” just because logs are arriving. Defenders still need to confirm that the events contain the right metadata, use a stable time source, and represent the activity at the right level of detail. If those basics are missing, the platform may ingest data but fail to answer operational questions such as who acted, what changed, where the event occurred, and whether related events belong to the same incident.

Normalisation is the step that turns raw vendor output into a usable security record. That usually means mapping fields into a common schema, preserving event type and severity, and making sure duplicates, retries, and parser errors do not distort the signal. This is also where teams discover whether the source is over-logging harmless noise or under-logging security-relevant actions.

At scale, source onboarding becomes a data quality problem as much as a security problem. The more services you add, the more important it becomes to define what “good” looks like for each source class, because a noisy source can consume storage and analyst attention while still failing to improve detection coverage. Log Management and Retention Guide

What goes wrong when log sources are missing, noisy, or inconsistent

The main failure mode is blind spots. If an important application, identity provider, endpoint, or cloud control plane is not sending events, detections built around the SIEM can never see activity in that path. The next failure mode is distortion: duplicate events, clock drift, or partial field capture can make investigations slower, make correlation rules fire incorrectly, or hide the sequence of an attack.

Noise is its own operational risk. Overly chatty sources inflate retention costs, make searches slower, and create alert fatigue when analytics have to sort signal from bulk harmless activity. In some environments, the biggest problem is not absence of logs but poor selectivity, where teams collect so much low-value telemetry that the events they actually need are harder to find.

Consistency matters because log sources often feed multiple uses at once: detection, forensics, compliance, and operational troubleshooting. When the same source is handled differently by different teams, one set of records may support alerting while another is too incomplete for investigation. That gap is what turns a log pipeline into a false sense of coverage. SANS Security Resources

Practitioner Guidance

What to verify: Treat every new source as a validation exercise, not a forwarding exercise. Confirm timestamp accuracy, field completeness, event volume, and whether the records actually support a detection or investigation use case before declaring the source “onboarded.”

Decision rule: If a source is security-critical but low quality, prioritise repair or parser tuning before expanding more sources. If the source is merely duplicative or low value, reduce its retention or sampling rather than letting it consume analyst and storage capacity.

What good looks like: A useful source produces stable, searchable events that line up with other telemetry, supports at least one concrete detection or investigation query, and does not generate avoidable duplication or alert churn.

Practitioner takeaway: The real measure of a log source is not whether it exists, but whether its events are trustworthy enough to improve detection and investigation without creating more noise than insight.

Related resources from NHI Mgmt Group

• Who is accountable when a critical log source goes dark?
• How should organisations evaluate no-log AI before using it for sensitive work?
• When does bytecode decompilation become more useful than source-based review in mobile security work?
• What happens when teams add a new log source without a fast tuning process in place?