-
Notifications
You must be signed in to change notification settings - Fork 419
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
Conversation
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). |
Event ID 4732 in AD - 'administrator' has added 'bob' to the users group. A member was added to a security-enabled local group. Member: Group: 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 Target Account: Security ID: ACME-FR\John.Locke |
Hi All, 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
Privilege Access Management Logs I have access to some Thycotik logs, but I'm not able to generate logs. I'll be looking for an example there also. |
Amazing, thank you @janniten |
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"
}
}
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"
}
|
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: |
There was a problem hiding this 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.
Co-authored-by: Eric Beahan <[email protected]>
@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)? |
@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 :-) |
There was a problem hiding this 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?
@rylnd not sure if you've seen anything from the SIEM that we'd need to include with these changes as well? |
rfcs/text/0000-multiple-users.md
Outdated
"name": "bob.barker" | ||
} | ||
}, | ||
"related": { "user": ["alice", "root", "bob", "bob.barker"] } |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
…tion field... Even if it's unrelated to how user fields should be used
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" @ebeahan We have one additional merge task once this is approved:
|
There was a problem hiding this 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -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. --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
LGTM. |
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
Preview of the RFC