Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Multiple users in an event #914

Merged
merged 24 commits into from
Oct 2, 2020
Merged

Conversation

webmat
Copy link
Contributor

@webmat webmat commented Aug 6, 2020

I'm opening this RFC with a target of stage 2. This is the first PR for this RFC, but a lot of discussion has already happened before on the subject. Notably in #809 and #589 (see this RFC's references links to for more past discussions).

Opening directly at stage 2 simply means we'll need to ensure all stage 1 and 2 criteria are satisfied before moving forward.

In this RFC I try to document all expected uses of the user fields. This is not meant to be only a description of the new fields that will be introduced by #869.

Since this RFC is meant to document all uses of the user fields, there will also be discussion about potentially deprecating and removing user fields in places that don't have a clear purpose. Feedback is definitely welcome, if you disagree with these removals.

TODO

  • Identify the sponsor
  • Populate the "source data" section
    • add some simple Linux IAM events
    • I need help to find more complex IAM event samples (e.g. listing changes to the user)

Preview of the RFC

@webmat webmat self-assigned this Aug 6, 2020
@webmat webmat added the RFC label Aug 6, 2020
@webmat webmat marked this pull request as ready for review August 10, 2020 20:37
@webmat
Copy link
Contributor Author

webmat commented Aug 10, 2020

This PR is no longer marked as Draft :-)

Ping @ebeahan @epixa @jamiehynds @leehinman @janniten @willemdh @neu5ron @vbohata @rw-access @P1llus

I'll be adding simple Linux events in the "Source Data" section.

However I would really appreciate if someone has real events they could share from AD or other, that capture some of the complex events with many users present in the event (e.g. "real" user + priv escalation + target user + changes to the user).

@jamiehynds
Copy link
Contributor

jamiehynds commented Aug 11, 2020

@webmat

Event ID 4732 in AD - 'administrator' has added 'bob' to the users group.

A member was added to a security-enabled local group.
Subject:
Security ID: WIN-R9H529RIO4Y\Administrator
Account Name: Administrator
Account Domain: WIN-R9H529RIO4Y
Logon ID: 0x1fd23

Member:
Security ID: WIN-R9H529RIO4Y\bob
Account Name: -

Group:
Security ID: BUILTIN\Users
Group Name: Users
Group Domain: Builtin

Additional Information:

Privileges: -

Expiration time: -

Event ID 4722 in AD - 'administrator' has enabled the 'john.locke' account.

A user account was enabled.

Subject:

Security ID: ACME-FR\administrator
Account Name: administrator
Account Domain: ACME-FR
Logon ID: 0x20f9d

Target Account:

Security ID: ACME-FR\John.Locke
Account Name: John.Locke
Account Domain: ACME-FR

@webmat webmat mentioned this pull request Aug 11, 2020
@janniten
Copy link
Contributor

Hi All,
AD Example
I was not able to find an AD event where the 3 users appear. The relationship between users exists but it is scattered in
several events (4648,4624 and 4787) and bound but the winlog.logon.id. For example:
image

I'm working now with some events in which all users maybe appears (4670,4715) in one event. I'll let you know If I found the example that contains all the users.

Oracle Auditory Event Example
Those events are in the table dba_audit_trail in the SYS schema (here the detailed structure: https://docs.oracle.com/database/121/REFRN/GUID-A9993FAC-12D3-4725-A37D-938CC32D74CC.htm#REFRN23023).
I prepare some small example, copying here the relevant columns but the full export is attached.

OS_USERNAME USERNAME ACTION_NAME SQL_TEXT Mapping
gabriel.surname SYS ALTER USER ALTER USER ACRISTALDI IDENTIFIED BY * user.name: gabriel.surname user.effective: SYS user.target: ACRISTALDI
gabriel.surname SYS SYSTEM GRANT GRANT SELECT ANY TABLE TO ACRISTALDI user.name: gabriel.surname user.effective: SYS user.target: ACRISTALDI
gabriel.surname SYS UPDATE UPDATE SYS.USER$ SET NAME='ACRISTAL' AND USER#=143 AND NAME='ACRISTALDI'; user.name: gabriel.surname user.effective: SYS user.target: ACRISTALDI user.changes: ACRISTAL

example_oracle.xlsx

Privilege Access Management Logs
In PAM solutions (with the exception of logs regarding to administration of secrets) we always have a case of privilege escalation, so user.name and user.efective always exists and if the action is related to user management, then user.target and user.changes appears
For example, I'm coping some headers from Cyberark's logs (unfortunatly I don't have access to export the logs)
image

I have access to some Thycotik logs, but I'm not able to generate logs. I'll be looking for an example there also.
Regards

@webmat
Copy link
Contributor Author

webmat commented Aug 12, 2020

Amazing, thank you @janniten

@leehinman
Copy link
Contributor

AWS has an AssumedRole API, a simplified Cloudtrail entry would be:

{
  "eventName": "AssumeRole",
  "requestParameters": {
    "roleArn": "arn:aws:iam::111111111111:role/JohnRole2",
  },
  "resources": [
    {
      "ARN": "arn:aws:iam::111122223333:role/JohnRole2",
      "accountId": "111111111111",
      "type": "AWS::IAM::Role"
    }
  ],
  "responseElements": {
    "assumedRoleUser": {
      "arn": "arn:aws:sts::111111111111:assumed-role/test-role/Role2WithTags",
      "assumedRoleId": "AROAIFR7WHDTSOYQYHFUE:Role2WithTags"
    },
  "userIdentity": {
    "accessKeyId": "AKIAI44QH8DHBEXAMPLE",
    "accountId": "111111111111",
    "arn": "arn:aws:sts::111111111111:assumed-role/JohnDoe/JohnRole1",
    "principalId": "AROAIN5ATK5U7KEXAMPLE:JohnRole1",
    "type": "AssumedRole"
  }
}
field value
user.id AROAIN5ATK5U7KEXAMPLE:JohnRole1
user.effective.id AROAIFR7WHDTSOYQYHFUE:Role2WithTags

Also AWS can have AssumedRoles in the userIdentity:

  "userIdentity": {
    "accessKeyId": "AKIAQRSTUVWXYZEXAMPLE",
    "accountId": "777788889999",
    "arn": "arn:aws:sts::777788889999:assumed-role/AssumeNothing/devdsk",
    "principalId": "AIDAQRSTUVWXYZEXAMPLE:devdsk",
    "sessionContext": {
      "attributes": {
        "creationDate": "2016-11-14T17:25:26Z",
        "mfaAuthenticated": "false"
      },
      "sessionIssuer": {
        "accountId": "777788889999",
        "arn": "arn:aws:iam::777788889999:role/AssumeNothing",
        "principalId": "AIDAQRSTUVWXYZEXAMPLE",
        "type": "Role",
        "userName": "AssumeNothing"
      }
    },
    "type": "AssumedRole"
  }
field value
user.id AIDAQRSTUVWXYZEXAMPLE
user.name AssumeNothing
user.effective.id AIDAQRSTUVWXYZEXAMPLE:devdsk

@ebeahan ebeahan added the ready Issues we'd like to address in the future. label Aug 18, 2020
@jamiehynds
Copy link
Contributor

Event ID 4624 in Windows is used to capture when a process attempts to log on an account by explicitly specifying that account’s credentials. This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the RUNAS command.

A logon was attempted using explicit credentials.

Subject:
Security ID: WIN-R9H529RIO4Y\Administrator
Account Name: Administrator
Account Domain: WIN-R9H529RIO4Y
Logon ID: 0x1ba0e
Logon GUID: {00000000-0000-0000-0000-000000000000}
Account Whose Credentials Were Used:
Account Name: [email protected]
Account Domain: WIN-R9H529RIO4Y
Logon GUID: {00000000-0000-0000-0000-000000000000}
Target Server:
Target Server Name: sp01.IceMAIL.com
Additional Information: sp01.IceMAIL.com
Process Information:
Process ID: 0x77c
Process Name: C:\Program Files\Internet Explorer\iexplore.exe
Network Information:
Network Address: -
Port: -

ebeahan
ebeahan previously approved these changes Aug 21, 2020
Copy link
Member

@ebeahan ebeahan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent proposal 💯 . I have a few notes but overall this looks great.

rfcs/text/0000-multiple-users.md Outdated Show resolved Hide resolved
rfcs/text/0000-multiple-users.md Outdated Show resolved Hide resolved
rfcs/text/0000-multiple-users.md Outdated Show resolved Hide resolved
rfcs/text/0000-multiple-users.md Outdated Show resolved Hide resolved
Co-authored-by: Eric Beahan <[email protected]>
@jonathan-buttner
Copy link
Contributor

@webmat just wanted to check in and see if you need me to solicit more feedback (I think I'm the sponsor for this one)?

@webmat
Copy link
Contributor Author

webmat commented Sep 9, 2020

@jonathan-buttner Thanks for asking. Yes, a thorough review from someone on the team would be welcome.

Note that I still have a few tasks on my end before this is final, the main one being including concrete mapping examples based on Linux and Windows events (e.g. like those shared via comments here). This is unlikely to happen this week or the next.

So a review in the meantime would be greatly appreciated, with the only caveat that the concrete examples are coming :-)

Copy link
Contributor

@jonathan-buttner jonathan-buttner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The proposal looks good to me. @rw-access any additional scenarios you can think of that would warrant additional fields?

rfcs/text/0000-multiple-users.md Outdated Show resolved Hide resolved
@jonathan-buttner
Copy link
Contributor

@rylnd not sure if you've seen anything from the SIEM that we'd need to include with these changes as well?

"name": "bob.barker"
}
},
"related": { "user": ["alice", "root", "bob", "bob.barker"] }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies if this has already been addressed, but one concern that was raised by the detections team was the uniqueness of these names. If related.user is intended to be used programmatically, my (naive) sense is that id would be a better candidate here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this has been raised in the past. We haven't addressed it directly anywhere yet, however. One potential solution that has been floated would be that related.user could perhaps contain all seen usernames + user IDs.

The field is only meant to pivot and find a user, no matter where in the event they appeared. It's not meant to have semantic meaning.

This RFC is not meant to address this issue, however. We will tackle that issue separately.

@webmat
Copy link
Contributor Author

webmat commented Sep 30, 2020

Ok I think this is ready for a final review for stage 2.

@janniten Thanks so much for these events, they're the ones I used for the Windows examples. Note that it's fine if events don't actually need all the field nestings at the same time. They're all in the schema to support events that do need them all. But in many cases, the activity is spread out across multiple events, as you noted. So only the needed fields should be used in each such events :-) I've tried to demonstrate the various situations in the examples I've just added.

@leehinman Thanks a lot for the Cloudtrail AssumeRole events. I modified one of the ARNs slightly, but I used your events in my cloud example :-) Can you confirm my mapping makes sense to you? Especially the last paragraph.

Final note for reviewers: I took the liberty to use a "session" event.category in some of the examples. It doesn't exist yet in the ECS allowed values, but has been discussed in the session RFC.

@ebeahan We have one additional merge task once this is approved:

  • Set the merge date
  • Assign the RFC ID
    • Rename the directory with field changes accordingly :-)

ebeahan
ebeahan previously approved these changes Sep 30, 2020
Copy link
Member

@ebeahan ebeahan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

I only noted a handful of tiny changes.

rfcs/0000-rfc-template.md Show resolved Hide resolved
rfcs/text/0007-multiple-users.md Outdated Show resolved Hide resolved
rfcs/text/0007-multiple-users.md Outdated Show resolved Hide resolved
rfcs/text/0007-multiple-users.md Outdated Show resolved Hide resolved
rfcs/text/0007-multiple-users.md Outdated Show resolved Hide resolved
rfcs/text/0007-multiple-users.md Outdated Show resolved Hide resolved
rfcs/text/0007-multiple-users.md Outdated Show resolved Hide resolved
rfcs/text/0007-multiple-users.md Outdated Show resolved Hide resolved
Copy link
Member

@ebeahan ebeahan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM :shipit:

@@ -2,7 +2,7 @@
<!-- Leave this ID at 0000. The ECS team will assign a unique, contiguous RFC number upon merging the initial stage of this RFC. -->

- Stage: **2 (proposal)** <!-- Update to reflect target stage. See https://elastic.github.io/ecs/stages.html -->
- Date: **TBD** <!-- The ECS team sets this date at merge time. This is the date of the latest stage advancement. -->
- Date: **2020-09-02** <!-- The ECS team sets this date at merge time. This is the date of the latest stage advancement. -->
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

@leehinman
Copy link
Contributor

Ok I think this is ready for a final review for stage 2.

@janniten Thanks so much for these events, they're the ones I used for the Windows examples. Note that it's fine if events don't actually need all the field nestings at the same time. They're all in the schema to support events that do need them all. But in many cases, the activity is spread out across multiple events, as you noted. So only the needed fields should be used in each such events :-) I've tried to demonstrate the various situations in the examples I've just added.

@leehinman Thanks a lot for the Cloudtrail AssumeRole events. I modified one of the ARNs slightly, but I used your events in my cloud example :-) Can you confirm my mapping makes sense to you? Especially the last paragraph.

Final note for reviewers: I took the liberty to use a "session" event.category in some of the examples. It doesn't exist yet in the ECS allowed values, but has been discussed in the session RFC.

@ebeahan We have one additional merge task once this is approved:

  • Set the merge date

  • Assign the RFC ID

    • Rename the directory with field changes accordingly :-)

LGTM.

@webmat webmat merged commit b106d3a into elastic:master Oct 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants