Normalisation and Pivoting Across Sources

What is it?

Normalisation is mapping the different field names each source uses onto a shared schema, so the same idea — a source address, a user, a host — has one name everywhere. Pivoting is using a normalised field to jump from one source to another while following the same entity.

Why it matters

Without normalisation you cannot join sources at all: one log calls it src_ip, another client.address, a third RemoteHost. Pivoting on a shared field is how one alert becomes a full picture — and doing it at scale, across millions of events, is exactly the Tier-2 job.

Where you see it

The SIEM normalises at ingest time into a common information model, so a single search can span many sources. Where a source is not onboarded or a field is not mapped, the analyst normalises by hand in their notes.

What normal looks like

A well-run SIEM maps the core entities — user, host, source and destination address, process — consistently across sources, so a pivot on a user returns their activity everywhere. Coverage is never total, and that is expected.

What suspicious looks like

An entity that appears in one source but is absent from another where it should appear — a host that authenticated but has no endpoint telemetry — points either to a coverage gap or to tampering. Both are worth recording; the analyst must not silently assume 'no data' means 'nothing happened'.

How analysts investigate

Choose the pivot field with the highest fidelity — a host name or a unique address beats a shared NAT address. Search it across every normalised source, collect the hits, and note where a source that should have matched did not.

Common beginner mistakes

Pivoting on a low-fidelity field such as a shared NAT or proxy address, which returns many unrelated entities at once.
Assuming a source has no relevant events when in fact the source was never onboarded or the field was never mapped.
Trusting the SIEM's normalisation blindly and never checking the raw event when a field looks wrong.

What you will be able to do

Map differently-named fields across sources onto one shared meaning.
Choose a high-fidelity pivot field and follow one entity across sources.
Recognise a coverage gap and refuse to read 'no data' as 'nothing happened'.

Correlation and timelines both depend on one quiet skill: being able to say that this field in source A is the same idea as that field in source B. That is normalisation, and pivoting is what you do with it — following one entity through every source that saw it.

Shared idea	Windows log	Proxy log	Firewall
Source address	IpAddress	c-ip	src
User	TargetUserName	cs-username	(none)

Worked example — following one user

The account a.kamal appears as TargetUserName in Windows logs and as cs-username in the proxy, but the firewall log has no user field at all. Before reading on, decide: can you pivot on a.kamal directly into the firewall log?

The answer: no — the firewall has no user field, so you must pivot indirectly, via the host or address a.kamal was using. And if the endpoint source shows no a.kamal activity in a window where you expected it, do not conclude 'clean': that missing coverage is itself a finding to record.

Recap

Normalisation maps different field names to one shared meaning, so sources can be joined.
Pivot on the highest-fidelity field — the one with the fewest owners.
Where a source that should match does not, that is a coverage gap or tampering — record it.