Elastic asset owner (WIP)

Works out who uses a host by aggregating logon events in Elasticsearch and attributing the host to the user who appears most. It creates no assets — it fills in asset_owner on the ones you already have.

Type name	elastic_asset_owner
Creates	Nothing — enriches existing endpoints
Runs on	A sensor with network reach to Elasticsearch
Fields written	asset_owner, optionally user_department and criticality

How ownership is resolved

1. Query the configured index for logon events, aggregated by user per host.
2. If exactly one user appears for a host, that user wins.
3. If several appear, the one accounting for more than 60% of the host's events wins. If no user clears that bar, the host is left unowned.
4. Match the winning username against existing user assets, by the local part of user_email, by active_directory_user_sam_account_name, or by active_directory_user_surname.
5. Write the matched user asset's ID into the host's asset_owner.

Ownership is a link, not a string

asset_owner holds the ID of a user asset. If the person has no user asset — because no directory integration has imported them — the host stays unowned no matter how clear the logon evidence is. Run Active Directory users or Azure users first.

An existing owner is never overwritten

If a host already has an asset_owner and this run resolves a different one, the conflict is logged and the run moves on. Ownership assigned by hand, or by another integration, therefore wins permanently.

Requirements

The integration is outbound-only: it searches an index on a schedule, so nothing is installed in the Elastic stack, nothing changes on the hosts whose logs it reads, and nothing has to reach into the deployment.

Network access

From	To	Protocol	Port
The sensor running the integration	Elasticsearch, at the URL configured on the instance	HTTPS over TCP	Whatever the URL names — 9200 on a default self-managed install, 443 on Elastic Cloud

One host, and it is Elasticsearch itself rather than Kibana: the run issues POST /{index}/_search. This is usually an internal destination rather than an internet one, so the rule belongs in the internal firewall.

Access in Elastic

Need	Why
An account that can create Elasticsearch users or roles	The credential is a user with read and view_index_metadata on the index pattern — see Permissions in Elastic
Logon events present in the index pattern	Ownership is inferred from authentication logs; an index without them resolves no owners while the run still succeeds

If Elasticsearch presents a certificate the sensor host does not trust, install the CA on the host in preference to enabling Ignore SSL — the credential is sent on every request, and these are authentication logs.

In this deployment

Need	Why
A registered, healthy sensor with reach to Elasticsearch	The integration runs on a sensor, on the platform's schedule — see Sensors
Endpoints already in the inventory	This integration creates nothing — it writes asset_owner onto hosts that already exist, matched on the Platform hostname field
Users in the inventory, for department and criticality	The enrichment copies user_department and criticality from the owning user's record, so those fields need a user source such as Azure users

Configuration

Field	Required	Default	Notes
Name	Yes		Label for this instance
URL	Yes		Elasticsearch base URL
Username	Yes		Elasticsearch user
Password	Yes		Password for that user
Cookies	No		Extra cookies added to requests
Elastic index	No	logs-*	Index pattern to search
Elastic query	No	Windows logon events (see below)	Query selecting logon events
Elastic user field	No	user.name	Document field holding the username
Elastic hostname field	No	agent.name	Document field holding the hostname
Platform hostname field	No	elastic_agent_name	Asset field matched against the document hostname
Platform user field	No	asset_owner	Asset field written with the resolved owner
Platform user value field	No	user_email	User-asset field used to match the username
Sensor	Yes		Sensor that will run the integration
Ignore SSL	No		Skips certificate validation

The default query targets successful interactive Windows logons:

winlog.event_id: "4624" AND process.executable: "C:\\Windows\\System32\\svchost.exe"

Its scan template adds a look-back window and an enrich host information by asset owner checkbox, on by default, which copies the owner's user_department into the host's department and propagates criticality.

Tune the query before widening the window

Event 4624 covers service and network logons as well as people at keyboards. Narrowing on logon type gives cleaner ownership than looking back further does — a noisy query with a long window mostly produces hosts owned by service accounts.

Permissions in Elastic

A user with read and view_index_metadata on the configured index pattern. The integration issues POST /{index}/_search.

These are authentication logs

Whatever index you point this at contains who-logged-in-where. Scope the Elasticsearch role to exactly that pattern, and keep this integration's credential separate from any other Elastic integration.

See also

• CrowdStrike asset owner — the same idea using Falcon telemetry instead of Elastic
• Elastic aggregation query — the general form of this pattern
• Integrations overview — the shared configuration model