Flesh out the user object

[webmat]

The user object is missing a few fields. We're considering adding the ones below:

• user.unique_id (Extended): an organization-wide unique ID for the user
• user.username (Core): The user's programmatic name / login for a given system. This is in contrast to user.name, which will be clarified to be the person's real name, e.g. "Albert Einstein"
• user.employee_id (Extended)

cc @andrew-goldstein

[ruflin]

• I would expect user.id to be unique?
• Could we fit both into user.name, meaning it could be user.name: ["ruflin", "Nicolas Ruflin"]?
• employee_id seems very specific. Not sure we should have this in ECS?

[webmat]

• I would expect user.id to be unique?

Well it wouldn't be unique in the event stream itself :-) But yes, I would expect this value to be the unique user id in the context of the system. In other words, perhaps when a Linux event is being mapped to ECS, user.id is the Linux UID, which is unique in the context of this specific system.

The difference between user.id and user.unique_id is that .id is an arbitrary system's definition of the user ID (Linux UID, my app's completely different ID, etc). Whereas .unique_id is a place where a UEBA would store the user's unique ID across all of the organization's systems.

• Could we fit both into user.name, meaning it could be user.name: ["ruflin", "Nicolas Ruflin"]?

I think it would be helpful to have both values in distinct fields. When doing an aggregation over a field that consistently contains a pair of values as in your example, each event would then be represented/counted twice. E.g.:

Frequent Logins:

1. ruflin: 42
2. Nicolas Ruflin: 42
3. webmat: 34
4. Mathieu Martin: 34
5. haxx0r: 32

Adding to the confusion of that duplication, typically only one of the two name fields is mandatory in a given system (username is mandatory for Linux users; only full name may be mandatory on a blogging app). So the aggregation would have duplication for dutiful users who filled both, and no duplication for users who preferred only filling only the mandatory name (as 5. above).

• employee_id seems very specific. Not sure we should have this in ECS?

I'm ambivalent about this. I agree it assumes a very specific thing is at play (employment). I've heard feedback that people from the government would like there to be a lot more user related fields. Although what's needed for these folks is just a better understanding that they can add these fields even if they're not in ECS (aka #114). So I guess we should indeed remove it from the list for now. And we need to work on 114 instead :-)

[ruflin]

Good point about the aggregation. I wonder if from your point of view this would also apply to user.id assuming the unique id would also be stored there?

As user.id is reusable, I would expect the unique id and the one from the system user id not necessarely to end up in the same place in the hierarchy.

Let's skip employee_id for now, we can always fields later. Perhaps this belongs actually under organisation. To keep track of it we could open a Github issue with it.

For the Nicolas Ruflin as name I would challenge if ECS has to provide a field for it? One of the core purpose of ECS is correlation / aggregation / filtering and the full name more looks like search.

[webmat]

Well sometimes (e.g. smaller companies) people use weird usernames that don't give a clue who the person actually is. So I'd be inclined to leave full name in, in order to encourage people to log both and increase the chance of figuring out who that dieu admin user is...

[willemdh]

Since ECS is using entity_id for the process object, I wonder if maybe we could use the same term to define something that is truly globally unique? Would user.entity_id be an option instead of user.unique_id?

This is in contrast to user.name, which will be clarified to be the person's real name, e.g. "Albert Einstein"

Imho user.name should have 'the best possible name' field as value. Like host.name. Most events / logs do not have the full name, so user.name will have the Active Directory user name in most cases. Maybe we should have a look at an Active Directory user and provide fields for all relevant user data.

Unfortunaly using:

user.name.first
user.name.last
user.name.full
...

is not an option due to user.name already in use.

So what about:

user.first_name
user.last_name
user.full_name
user.logon_name
user.description
user.email

user.name could generally contain user.logon_name and if not available anything else in the list above (or a variant) My personal preferred order would be

1. user.logon_name
2. user.email
3. user.full_name

Of course a user could have multiple email addresses, but generally only one is primary logon.
is user.email planned to be an array?

All of the above should be compatible with source and target vs primary and secondary vs subject and target problematic, see #678 and #234 and #589

For which discussions seems to have calmed down :)

For now I'm using winlog.event_data.SubjectUserName, but this really needs a decent spot in ECS.

Grtz

[webmat]

Closing as stale. The fields in the initial request have either been added or the decision was made not to add them.

If folks see a need for specific additional user fields, please open a new issue ❤️