Account for Multiple Users in an Event

[eternalyperplxed]

Some events, specifically Active Directory change events (event.id 5136) may have multiple user names in the event. The user making the change, and the user being changed. Perhaps user.source and user.target could be used to differentiate?

[MikePaquette]

@eternalyperplxed ECS allows for information from multiple users to be included the same event. The user.* fields are "re-usable" in the sense that they can be used "under" other objects, such as source.user.* , destination.user.* , host.user.*. So the mechanics of how to include multiple users in the same event are well defined.

See the user section of the readme file here.

However, your use case raises an interesting follow-on question - in which user fields should we populate which user's details?

Here's one way to approach it. Perhaps others will have better ideas.

• The host.* on which the event happened is the AD server.
• The host.user.* is the user that made the event happen (e.g. "administrator")
• The username of the account that was changed could be added under related.user.* (Note this is not yet explicitly defined in ECS)

Logically, it could look like this:

[eternalyperplxed]

Thanks @MikePaquette this makes sense to me and I agree with the follow on question. I believe there are some instances where an Active Directory event could have something like 6 different users contained within it, so trying to find a common ground to account for them is an interesting challenge.

[MikePaquette]

@eternalyperplxed yes, indeed, but note that the related.* fields are expected to be arrays, so adding multiple values to each related.user field might help address this problem.

[webmat]

Thanks for submitting this question, @eternalyperplxed.

I also agree that user management use cases will need a clear way to define which user is doing the change and which user(s) are affected.

Right now I would say that related.* is not semantically the right place to officially list affected users. This is a place where we expect all values of one kind to be added to the array, to simplify pivoting (in the case of usernames, we should add the administrator name as well as the affected user names).

So I do think we'll need to work on an official place to list the affected users.

[eternalyperplxed]

Understood @webmat Thanks for looking into this!

[MikePaquette]

@webmat I agree we need to find an official place for the affected user.* info, but once we do that, I think that the related.user.* will be a very good fit for a copy of it. Of course, the host.user.* fields would be copied there as well, consistent with the way we've envisioned and specified the use of other related.* fields.

[vbohata]

I think new 2 top level fields - old/new should help in situations like changing user name and more (so new.user.name for new username, for file path new.file.path, ...).

[neu5ron]

I would hope we could use source.user and destination AND or create a target field thus using target.user

Multiple usernames in a single field I would imagine is ok, because elasticsearch handles arrays well. Now if a category has multiple distinct fields like an SMTP log that has from,to,cc, etc.

[webmat]

Closing in favor of #1066 (see also RFC 0007 stage 3 PR #1017)