Explainable correlation: how to decide two records are the same machine

Every asset inventory product promises deduplication. Few explain how they decide that a record from your EDR, a computer object from Active Directory and a host from last night's network scan are the same physical machine. Yet that decision is the single most important thing an inventory does. Get it wrong one way and you double-count; get it wrong the other way and two different servers quietly become one record, and one of them disappears from view.

This post describes the approach we take in Lumen Edge, and why we think correlation has to be explainable.

Why correlation is hard

Identifiers that look unique rarely are:

• Hostnames get reused when machines are replaced, and differ in case, domain suffix and length between tools.
• IP addresses change with DHCP, are shared behind NAT, and get recycled within hours.
• MAC addresses belong to interfaces, not machines, and virtual, docker and VPN interfaces generate plenty of them.
• Agent IDs are excellent within one vendor, meaningless across vendors, and change when an agent is reinstalled.

No single field is enough. What works is an ordered set of rules, each with a known strength, tried from strongest to weakest.

Ordered match rules

For each source, Lumen Edge evaluates a list of match rules in order. The first rule that produces a match wins, and the rule that matched is recorded against the result. A typical sequence for an EDR source looks like this:

1. Agent ID. The same vendor agent ID as an existing record. Unambiguous within that vendor.
2. Predecessor agent on the same hardware. The agent was reinstalled; the vendor reports the previous agent ID for the same device.
3. IP address and hostname together. Two independent identifiers agreeing at the same time.
4. Hostname. Strong when names are well managed, weaker when they are not.
5. Fully qualified domain name. Useful where short names collide across domains.
6. Short name within the same DNS domain. Bridges sources that report web01 and web01.corp.example.
7. IP address, provided there is no name conflict. The weakest rule, used only when nothing contradicts it.

Each step down the list trades certainty for reach. Ordering them explicitly means the engine always prefers the strongest available evidence, and you can see which piece of evidence was used.

Conflict guards

Weak rules need brakes. A conflict guard stops a match when a stronger identifier on the existing record disagrees with the incoming one.

Consider an IP-only match. If the existing asset has a CrowdStrike agent ID and the incoming record carries a different agent ID for the same IP, the two are almost certainly different machines that happened to use the same address at different times. The guard rejects the match, and the incoming record becomes a new asset rather than overwriting an old one.

The same applies to names: a rule such as "name match with no agent-ID conflict" will only fire if the records do not carry contradictory agent identifiers.

A correlation engine is judged less by the merges it makes than by the merges it refuses to make.

Never guess on ambiguity

Sometimes a rule matches more than one existing asset: two records with the same hostname, for example. A tie-breaker can narrow the candidates, but only if it lands on exactly one. If ambiguity remains, Lumen Edge does not pick one at random or merge them together. The finding is left for a human, with the candidates visible.

This is a deliberate trade-off. An inventory with a handful of unresolved records is far more trustworthy than one that has silently fused two production servers.

Human overrides: pin and block

Rules cover the common cases; people know the exceptions. Analysts can:

• Pin a finding to a specific asset, forcing the match on future scans.
• Block a match, preventing a particular finding from ever attaching to a particular asset again.

Both overrides are explicit, persistent and visible, so the next person to look at the record understands why it is shaped the way it is. Manual merges are also available, with field-by-field control over which value to keep.

Keeping "who said what"

Correlation decides which records belong together. A second question is what to do with their attributes when sources disagree on, say, the operating system version.

Lumen Edge keeps source-specific fields alongside the consolidated view. CrowdStrike's view of the host, Defender's view and the network scanner's view remain available under their own prefixed fields, while core attributes are merged according to per-field rules: replace, merge or do-not-override. Every asset also records when it was first and last seen, and by which tool.

The result is that any value in the inventory can be traced back to the source that reported it. When an auditor or an incident responder asks "where did this come from?", there is an answer.

A change-controlled pipeline

Correlation runs inside a staged pipeline: verification, cleaning, identification, validation and sync. Between identification and sync, approval policies decide what happens to new assets, changed assets and assets that have gone missing. Each can be applied automatically, held for approval, or ignored, per source. For regulated environments this turns inventory updates into something closer to change control than a nightly overwrite.

Why explainability matters

Without explanations	With explanations
"The tool says these are the same."	"Merged on rule 3: IP and hostname matched; no agent-ID conflict."
Silent mis-merges surface during incidents.	Ambiguous cases are held for review.
Fixes are lost on the next scan.	Pins and blocks persist.
Attribute origin is unknown.	Every value traces to a source.

An inventory is only useful if people trust it, and people only trust what they can check. That is why we treat correlation as a chain of evidence rather than a black box.

If you want to see how your own sources line up (and which records would need a human decision), book a demo and we will run it on your data.