Cybersecurity glossary

What is Log Correlation?

Learn what log correlation is, how joining events by identity, time, and session reconstructs attacks, which pitfalls create false stories, and how to design correlation that analysts can trust.

Logging, detection and responseUpdated August 13, 2026
Also known asEvent correlationSecurity event correlationMulti-source log joining

Definition

Log correlation is the process of linking related events from multiple sources—using shared identifiers, time windows, and entity context—so isolated log lines become a coherent timeline of activity for detection and investigation.

Why a single log line is rarely the incident

Attackers do not live in one product. They phish a mailbox, replay a token, then run a script on a laptop. Log correlation is how those fragments become a timeline: the same identity, the same device, the same request ID, crossing systems that were never designed to tell one story.

Without join keys, analysts perform correlation in their heads—slowly, and only for the incidents they already suspect.

Join keys that actually work

Identity

Canonical user or service account across IdP, SaaS, and host—not display names that collide.

Session and request IDs

Trace a single API call from edge to app to database when developers propagate IDs.

Device and agent IDs

EDR sensor IDs and hardware identifiers beat DHCP leases that change hourly.

Time, carefully

UTC timestamps plus known skew. A five-minute clock drift can split one attack into two uncorrelated bursts.

How correlation goes from join to detection

1

Normalize fields

Parsers map vendor-specific names onto a shared schema so “user” means the same entity.

2

Resolve entities

Aliases, email addresses, and hostnames collapse to one object in an entity store.

3

Apply a hypothesis

A rule states what sequence or combination is suspicious—not “any two events.”

4

Score and suppress

Known-benign sequences (backups, scanners) drop out before a human is paged.

5

Present a timeline

The analyst sees ordered evidence with source links, not a pile of raw hits.

Correlation pitfalls

PitfallWhat you seeFix
IP as identityEntire offices or cloud NATs look like one attackerPrefer user, device, and session keys
Clock skewCause appears after effect; rules miss the windowNTP everywhere; store timezone-aware UTC
Over-wide windowsUnrelated admin work glues onto malware alertsHypothesis-specific windows and sequence order
Schema driftRules go quiet after a vendor field renameParser tests and source-health alerts
  • Propagate correlation IDs through applications, WAFs, and identity providers.
  • Maintain an entity map for humans, service accounts, and devices.
  • Write correlation rules as testable hypotheses with true-positive examples.
  • Alert on pipeline health: volume drops and parse failures break joins first.
  • Do not page on “two events from the same /24 in one hour” without more context.
  • Keep raw events available so analysts can challenge the correlated story.
  • Document known-benign multi-source patterns (IT automation, backups, red-team ranges).
  • Revisit windows after you measure real dwell time, not vendor demo timelines.

The practical takeaway

Log correlation turns scattered telemetry into a defensible narrative. Invest in join keys, schemas, and honest time—then encode hypotheses you can test. Correlation without identity is coincidence with extra steps.

Related security terms

Frequently asked questions

What is log correlation in simple terms?

It is connecting the dots: the failed VPN login, the successful SaaS login, and the unusual download belong to the same person and the same hour, so they become one story instead of three tickets.

What do you correlate on?

Stable keys: user or workload identity, device ID, session or request ID, source IP (carefully), file hash, and time windows that respect clock skew.

Is correlation the same as a SIEM?

A SIEM is a common place to do it. Correlation is the technique—you can also do it in XDR, data lakes, or notebooks. Buying a SIEM does not magically join bad identifiers.

Why do correlation rules false-positive?

NAT-shared IPs, reused machine names, unsynchronized clocks, and rules that treat coincidence in a busy window as causation.

How much time window is enough?

It depends on the kill chain. Credential stuffing may be seconds. Human-operated ransomware may span days. Sliding windows that ignore dwell time hide the campaign.

Should every correlated match page someone?

No. Correlation can enrich a case or raise a score. Page when the joined evidence supports a hypothesis with a known response, not when two noisy sources happened to overlap.

What breaks correlation silently?

Parser changes, missing tenant IDs after a cloud migration, and identity stores that cannot resolve the same human across IdP, EDR, and email.

References

Explore authoritative guidance and frameworks related to log correlation.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary