Data Sources for UEBA, Ranked

A UEBA deployment consumes whatever it is given, and the quality of what it is given determines nearly everything. This is a ranking by detection value per unit of integration effort, which is a different ordering from what most deployment guides suggest.

Tier one: start here

Authentication logs. Directory service and identity provider events: logons, failures, source addresses, authentication methods, token issuance. This is the single most valuable source. It covers every entity, it is well structured, and compromised credentials — the strongest UEBA use case — live here.

If you ingest one thing, ingest this.

Cloud identity and audit logs. Sign-ins, consent grants, role assignments, administrative actions in your identity platform and major cloud services. Structured, entity-attributed, and covering the surface where most modern activity happens.

VPN and remote access logs. Source geography, session duration, concurrency. Small volume, high signal, and they resolve addresses to users, which several other sources depend on.

Tier two: high value, more effort

Endpoint telemetry. Process execution, command lines, network connections from the host, file operations. Deep and voluminous. Enables detection that nothing else can reach, and requires real storage planning.

Application audit logs. Exports, record access, administrative actions in your CRM, HR system, finance platform, ticketing. Frequently the best available evidence of what someone actually did with data, and almost universally uncollected because each system needs its own integration.

This tier contains the single most underused source in the field: the export log of the system holding your most sensitive records.

File and object storage access. Who read what, when, at what volume.

Email metadata. Sender, recipient, volume, attachment presence, forwarding rule changes. Metadata alone is enough for most behavioural detection without inspecting content, which is a meaningful privacy advantage.

Tier three: useful in context

Network flow records. Who talked to whom, how much. Coarse and comprehensive. Valuable for lateral movement and for detecting activity from entities with no other telemetry.

DNS query logs. High volume, useful for detecting connections to unusual destinations.

Physical access records. Badge events. Small, structured, and enable a genuinely useful class of detection: authentication from the office by someone who did not badge in.

HR event feeds. Not behaviour, but context that transforms interpretation. Covered separately because it carries privacy obligations.

Tier four: expensive relative to return

Full packet capture. Enormous volume, mostly encrypted, rarely entity-attributed.

Web proxy logs at full detail. Useful, and the volume is punishing relative to what behavioural analytics extracts from it.

Anything requiring content inspection to be entity-attributable.

The attributes that matter more than the source

A source is only useful if its events carry certain fields. Check before integrating:

An entity identifier. An event without a user, host or account identifier cannot be attributed and contributes nothing to a per-entity baseline. Many network sources fail this test unless joined against DHCP or VPN records.

A reliable timestamp, with a known timezone. Time handling has its own entry on this site because it breaks more deployments than any other data issue.

A stable event type. Sources that change their schema without notice silently break features that depend on them.

Adequate retention. A ninety-day baseline requires at least ninety days of history. Sources retained for thirty days cannot support the models you intend to build.

The sequencing that works

Authentication first, alone, for a month. Establish that the pipeline works, that entity resolution is correct, and that baselines look sane before adding volume.

Add cloud audit and remote access. These share entity identifiers with authentication and enrich the same baselines rather than creating parallel ones.

Add the application logs for your most sensitive system. Highest value per integration in the entire list.

Add endpoint when storage and review capacity allow.

Adding everything at once produces an unusable alert volume and no way to attribute the noise to a source.

Verifying a source before you trust it

Integration is not completion. Before a source contributes to any baseline:

Sample thirty events by hand. Confirm the entity identifier resolves, the timestamp is correct with a known timezone, and the event type is what the documentation claims.

Measure coverage. Compare the distinct hosts, accounts or subscriptions appearing in the source against the inventory that should be producing them. The gap is the finding.

Check retention against your baseline window. A ninety-day model on a thirty-day source is training on a third of what you configured, silently.

Establish a volume baseline for the source itself, so that absence becomes detectable. This is the single most valuable piece of pipeline monitoring available.

Run it for a week before adding the next source. Adding sources in parallel makes it impossible to attribute noise.

Common false positives

Source-specific patterns that generate volume without meaning:

Health checks and monitoring probes generating authentication events continuously from service accounts.

Backup windows producing bulk file access nightly.

Software deployment touching every host in a short period.

Vulnerability scanners authenticating broadly and generating exactly the pattern lateral movement detection looks for.

Load balancers and proxies presenting themselves as the source of all traffic, collapsing many entities into one.

Each is trivially excluded once identified, and each will otherwise dominate a queue.

Blind spots and assumptions

That more sources mean better detection. Beyond a point they mean more noise and more entity resolution failures.

That a source covers what you think. Coverage gaps are routine — hosts without agents, cloud subscriptions outside the logging configuration, applications with logging disabled by default. Verify by sampling, not by asking.

That the source is trustworthy. Logs from a compromised system are attacker-controlled. Anything from the system being investigated should be corroborated from elsewhere.

That retention matches the baseline window. This mismatch is extremely common and produces models silently trained on less data than configured.