Flesh out support for multiple users in an event

[webmat]

We need to flesh out support for multiple users in an event to ECS, when there is a semantic relationship between them. Here are some use cases (please comment if you see additional use cases):

1. User A manages User B (create, modify, delete)
2. Directory User A logs into a machine as User B
3. User A escalates privileges / assumes identity of User B

This has been discussed a bit in the past in #234 , but no concrete plans were made at the time.

ECS currently supports source.user and destination.user, which may be enough to satisfy the requirements for no 2 above. However since source and destination are both designed to represent each side of a network connection, the semantics may be problematic when trying to use source.user and destination.user for no 1 and 3, as these can be purely local events.

Questions

Has anyone used source.user and destination.user in ECS to model these use cases? If so, did this work well, and are there edge cases where it doesn't work as well?

Should we try to model all cases with one naming recommendation for all use cases? As an example, should we always use user & affected.user. Or should we adjust the naming depending on semantics? E.g. 1) user & affected.user, 2) source.user & destination.user, and a different way for 3).

Points to consider

• Some schemas use the word "target" to describe the affected user. However the word also has the connotation of sounding like a victim, or the goal of an investigation. It may be a good idea to avoid using this word if we can.
• It may be a good idea to define the non-nested user as the user initiating the action in an event, rather than nesting both sides. This way searching for user.name:bob would return any events where "bob" was doing something. Searching for events affecting "bob" would require searching for the more qualified field name, like e.g. affected.user.name:bob. Pivoting to find anything related to "bob" can somewhat be done in Kibana by searching for *.name:bob (not supported via the ES API), or could be done by populating related.user.name systematically in all sources, then searching for related.user.name:bob.

Naming ideas

Please comment with additional naming ideas.

• user & affected.user
• user & target.user
• subject.user & target.user (like Windows)
• user & assumed.user (privilege escalation)
• ... (your suggestions)

[webmat]

cc @neu5ron, @eternalyperplxed, @vbohata, @willemdh

Your thoughts on this would be appreciated, as always :-)

[webmat]

cc @rw-access if you can comment, or cc the right Endgamer to chime in for this discussion :-)

[willemdh]

Personally I think for clarity, it would be good to nest all user related data under user.*

user.name should always contain the most relevant user data.

Found an example logon event where 2 different user names are mentioned:

     "provider_name": "Microsoft-Windows-Security-Auditing",
      "record_id": 1530007,
      "provider_guid": "{54849625-5478-49554-a5ba-3e3b0328c30d}",
      "activity_id": "{a16e1baf-7f5a-0011-0b1c-6ea15a7fd501}",
      "event_data": {
        "TargetLogonGuid": "{55910e0f-a1ab-2985-9c09-cb2595029867}",
        "TargetInfo": "cifs/myserver.mydomain",
        "SubjectUserSid": "S-1-5-21-171585296-39277855-1598175747-29326",
        "LogonGuid": "{00000000-0000-0000-0000-000000000000}",
        "SubjectUserName": "mynormaluser",
        "SubjectLogonId": "0x18ca3a",
        "TargetServerName": "myserver.mydomain",
        "SubjectDomainName": "MYDOMAIN"
      },
      "event_id": 4648,
      "api": "wineventlog",
      "channel": "Security",
      "keywords": [
        "Controle geslaagd"
      ],
      "opcode": "Info",
      "task": "Logon",
      "computer_name": "myworkstation.mydomain"
    },
    "event": {
      "created": "2019-10-18T11:59:48.689Z",
      "kind": "event",
      "code": 4648,
      "action": "Logon",
      "type": "authentication_success",
      "category": "authentication"
    },
    "source": {
      "port": 445,
      "ip": "10.10.10.2"
    },
    "ecs": {
      "version": "1.0.1"
    },
    "log": {
      "level": "informatie"
    },
    "user": {
      "name": "myadminuser",
      "domain": "MYDOMAIN"
    },
    "process": {
      "name": "null",
      "pid": 4
    }
  }
}

Original event message:

Poging tot aanmelden met expliciete referenties.

Onderwerp:
	Beveiligings-id:		S-1-5-21-171585296-394481855-1598175747-29326
	Accountnaam:		mynormaluser
	Accountdomein:		MYDOMAIN
	Aanmeldings-id:		0x18CA3A
	Aanmeldings-GUID:		{00000000-0000-0000-0000-000000000000}

Account waarvan de referenties zijn gebruikt:
	Accountnaam:		myadminuser
	Accountdomein:		MYDOMAIN
	Aanmeldings-GUID:		{55910e0f-a1ab-2985-9c09-cb2445029867}

Doelserver:
	Naam van doelserver:	myserver.MYDOMAIN
	Aanvullende gegevens:	cifs/myserver.MYDOMAIN

Procesgegevens:
	Proces-id:		0x4
	Procesnaam:		

Netwerkgegevens:
	Netwerkadres:	10.10.10.2
	Poort:			445

Deze gebeurtenis wordt gegenereerd wanneer een proces probeert zich op een account aan te melden door expliciet de referenties van die account op te geven. Meestal gebeurt dit in batchconfiguraties zoals geplande taken, of bij gebruik van de opdracht Uitvoeren als.

In the above example, user.name is populated with myadminuser, which comes from winlog.event_data.TargetUserName

But as you can see this was initiated from my workstation which runs under users mynormaluser which is now in winlog.event_data.SubjectUserName.

Imho it won't be easy to find a solution which match all possible cases where multiple users are in 1 event. We could put winlog.event_data.SubjectUserName in user.subject.name for example..

But imho we should put winlog.event_data.TargetUserName not only in user.name, but also in
user.target.name for clarity..

Another point is to take some other fields into account at the same time, because together with the user comes also the domain... So we would also need user.target.domain and user.subject.domain?

To be continued... Looking forward to other people's opinions.. :)

[andrew-goldstein]

@webmat in the current version of ECS (1.2 at the time of this writing), the ECS Process fields have a field to store parent process id:

process.ppid

, however I'm not seeing a field to store the parent process name, which would be equivalent to:

endgame.parent_process_name

[webmat]

@andrew-goldstein Valid point, but let's keep this issue about multiple users :-) Please open a separate issue for this.

[webmat]

@willemdh I didn't initially envision nesting user within itself. But it may work better than the examples I gave in the issue text. While affected.user reads well out loud, we'd effectively be creating an empty top level namespace, only meant to nest a reuse of user. That may be confusing :-)

So I like the idea of nesting user within itself, user.subject.* & user.target.* would map the Windows use case really well. I think this approach makes most sense when it's the same person (remote logon, privilege escalation).

Would it make sense for user management scenarios? For the "User A creates User B" scenario, would user.subject.name:admin and user.target.name:newuser make sense? I'm not sure.

Perhaps as you say, we should not try to find one naming scheme to match all scenarios.

Naming ideas, take 2:

• user.subject.* & user.target.* (+ user.* populated like user.target.*)
• user.subject.* & user.* (the target user mapped to top level user.* only)
• user.* & user.affected.* for user management scenarios

[willemdh]

Another example (I stumbled upon today):

Peter D'hot (domain\domainuser) copied the password for 'Eaton 9PX' (UPS) to the clipboard. (Title = Eaton 9PX -- UPS Groendreef, UserName = syseer@dilis.co). Client IP Address = 1.5.24.146

In this case it's for the user domain\domainuser who copied a password from our password manager. The password he copied came from the user syseer@dilis.co

Atm I'm doing it like this:

user.domain: domain
user.name: domainuser
passwordappliance.user.name: syseer@dilis.co

But it seems like passwordappliance.user.name: syseer@dilis.co could be replaced with:

user.target.name: syseer@dilis.co

[janniten]

Hi @webmat, @willemdh
First of all I want to mention two more use cases:

4. An user A access data from user B (case similar to privilege escalation). A lot of this cases are found when you analyze the dba_audit_trail of Oracle Databases
5. In some events we can have 3 users in a relationship ( a combination of cases 1 and 2). For example: a user A logs into a machine and by the means of privilege escalation to user B creates an user C.
   Example of a sudo log in a linux system
   Oct 30 15:56:09 srvtest sudo: user_a: TTY=pts/0 ; PWD=/home/user_a ;USER=user_b ; COMMAND=/usr/sbin/useradd user_c

For in cases 1-4, I think the idea of having nested users field fits very well for the cases I have seen so far and I really like the idea of both having the user.name and the user.target.name as @willemdh mentioned.
I've been working with windows user managment events (elastic/beats#13530) and in the cases like "User A creates User B" the mapping of user.subject.name:admin and user.target.name:newuser makes sense.
Here is a summary of the roles of subject and target user names in the windows user management and other user related events. I think the proposed mapping fits well in all cases

Also if we look in how auditbeat maps those kind of events a similiar aproacch is used. For example: when a user A creates a user B then the following fields are mapped like this
       user.name -> user A
       auditd.summary.actor.primary -> user B
       auditd.summary.actor.secundary -> user A

So, in summary I believe is a very good idea to use the nesting approach but I would choose a different name from user.target.name and user.subject.name (those make me think in windows events). Maybe user.name.primary and secondary? and if we have cases like 5 where there are more "actors" will be possible add more user.name.n-ary fields

What do you think?

[willemdh]

Thanks for the detailed information and examples @janniten . Although I totally agree user.subject.name and user.target.name indeed makes you think of windows, imho that doesn't need to be a bad thing? Most organizations are using Active Directory and are used to subject an target user fields. I'm quite sure my Windows security colleagues would really appreciate some known terminology. Also target and subject terminology is used in a lot of documentation etc. Reusing subject and target would imho make things a lot less complex. For your example 5, maybe another solution could be acceptable? Let's think about some workarounds for cases such as 5, before reinventing the wheel. Some wild ideas:
user.new.name
user.object.name

[janniten]

Hi @willemdh
I don't think that using user.target.name/user.subject.name is a bad thing by itself, but IMHO is maybe too specific in order to provide semantic content for all cases
Anyway, despite which name will be chosen the idea of implement nested field in order to represent user's relationships seems very good to me.

[willemdh]

@janniten

is maybe too specific in order to provide semantic content for all cases

Definitely, all of the above is also just imho. 😄

If the majority of ecs desingers think using n-ary fields are our best option, I will definitely follow.

So what do you think of user.object.name? Considering the scenario of three user names like 'user a logging in as user b creating user c', then isn't the new user name the object?

[janniten]

@willemdh

So what do you think of user.object.name? Considering the scenario of three user names like 'user a logging in as user b creating user c', then isn't the new user name the object?

Sorry I don't follow the idea. Do you mean user.object.name -> user c ?