-
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
Source/target and diff modeling #678
Comments
Hi @andrewstucki, |
@janniten that was the idea in that particular example, but the desire was just to highlight the need to model any sort of diffing or source/destination style events in a sizeable portion of the existing field sets out there. I'm fairly open to ideas on naming/implementation (would this be at the top-level as I suggested or embedded inside each top-level field set, etc.), but just calling out the need to solve this issue for a number of use-cases so that we don't just solve the same problem a myriad of different ways as they arise. So, any suggestions/opinions on how we should go about this are more than welcome! |
Cross-process activity could also be modeled this way. This could include injection, credential access/handle opening, etc. source.process.name = "totallynotmalware.exe"
target.process.name = "lsass.exe" I'd prefer that versus nesting source/target under process. Then you have two mega namespaces source and target without needing to pollute everything with a source and target. You could also argue that process.name = "totallynotmalware.exe"
target.process.name = "lsass.exe" The big advantage is that you can now build aggregations on those better. For instance, "what are the counts of the categories of events for cmd.exe?" You don't want to search search.process.name and process.name, and that will also make it tricky to assign them into buckets.
|
I totally agree about the implicit nature of some things, and am slightly less concerned with the proposed At least in our particular use case for security related stuff, I think that there's a ton of utility introducing the |
@andrewstucki just to make sure I'm tracking your example well, does this reflect your example? {
"user": {"name": "alice"},
"origin": {"user": {"name": "bob"}},
"target": {"user": {"name": "robert"}}
} This maps most closely to a Event ID of 4781 for Windows Event Logs (Security)
|
Using If I started out using I definitely want to add the capability to describe an original state that has transformed to a new state but conflating it with an object taking action on a different object seems confusing to me. |
…module (#15217) Added Audit and Log Management related events, Computer Object Management Events, Distribution Groups Events. Changed user.name field for user management events and related.user mapping. New Events Due to that Windows events are the source of information for Winlogbeat the events 1100, 1102, 1104, 1105, 1108 and 4719 has been added in order to monitor changes in the audit policy configuration, log deletion and other failures in the log subsystem. For event 4719, a human readable description was added in order to know which setting was modified (winlog.event_data.SubCategory) and to which value (winlog.event_data.AuditPolicyChangesDescription). Distribution Groups (Security-Disabled) Management Events were added. Those events are processed in the same way and with the same function that Security Groups (#14299). In order to add information about the nature of the group being managed the type (Security-Disabled/Security-Enabled) and scope (Local,Global,Universal) where added as winlog.group.type and winlog.group.scope. ComputerObject Management events were also added. Changes to ECS mappings In elastic/ecs#678 and elastic/ecs#589 we have been discussing how n-ary relationship between users in an event should be named and mapping into ECS. In #13530 winlog.event_data.TargetUserName has been mapped to user.name but from the reasons exposed in elastic/ecs#678 and elastic/ecs#589 the mapping winlog.event_data.SubjectUserName -> user.name is more appropriate. This mapping was changed. Also, with the adding of related fields in ECS 1.3 and specifically the related.user field (elastic/ecs#694) all the user names appearing in one event were mapped to the related user events. Every time a SubjectUserName or TargetUserName is copied also is added to the related.user field, as well as other users appearing in the event. Event test data were added for all events with the exception of event 1108 which I was not able to reproduce. Co-authored-by: Lee Hinman <[email protected]> Co-authored-by: Andrew Kroh <[email protected]>
…module (elastic#15217) Added Audit and Log Management related events, Computer Object Management Events, Distribution Groups Events. Changed user.name field for user management events and related.user mapping. New Events Due to that Windows events are the source of information for Winlogbeat the events 1100, 1102, 1104, 1105, 1108 and 4719 has been added in order to monitor changes in the audit policy configuration, log deletion and other failures in the log subsystem. For event 4719, a human readable description was added in order to know which setting was modified (winlog.event_data.SubCategory) and to which value (winlog.event_data.AuditPolicyChangesDescription). Distribution Groups (Security-Disabled) Management Events were added. Those events are processed in the same way and with the same function that Security Groups (elastic#14299). In order to add information about the nature of the group being managed the type (Security-Disabled/Security-Enabled) and scope (Local,Global,Universal) where added as winlog.group.type and winlog.group.scope. ComputerObject Management events were also added. Changes to ECS mappings In elastic/ecs#678 and elastic/ecs#589 we have been discussing how n-ary relationship between users in an event should be named and mapping into ECS. In elastic#13530 winlog.event_data.TargetUserName has been mapped to user.name but from the reasons exposed in elastic/ecs#678 and elastic/ecs#589 the mapping winlog.event_data.SubjectUserName -> user.name is more appropriate. This mapping was changed. Also, with the adding of related fields in ECS 1.3 and specifically the related.user field (elastic/ecs#694) all the user names appearing in one event were mapped to the related user events. Every time a SubjectUserName or TargetUserName is copied also is added to the related.user field, as well as other users appearing in the event. Event test data were added for all events with the exception of event 1108 which I was not able to reproduce. Co-authored-by: Lee Hinman <[email protected]> Co-authored-by: Andrew Kroh <[email protected]> (cherry picked from commit e624aef)
…ent Events - ECS related.user field mapping (#17090) Added Audit and Log Management related events, Computer Object Management Events, Distribution Groups Events. Changed user.name field for user management events and related.user mapping. New Events Due to that Windows events are the source of information for Winlogbeat the events 1100, 1102, 1104, 1105, 1108 and 4719 has been added in order to monitor changes in the audit policy configuration, log deletion and other failures in the log subsystem. For event 4719, a human readable description was added in order to know which setting was modified (winlog.event_data.SubCategory) and to which value (winlog.event_data.AuditPolicyChangesDescription). Distribution Groups (Security-Disabled) Management Events were added. Those events are processed in the same way and with the same function that Security Groups (#14299). In order to add information about the nature of the group being managed the type (Security-Disabled/Security-Enabled) and scope (Local,Global,Universal) where added as winlog.group.type and winlog.group.scope. ComputerObject Management events were also added. Changes to ECS mappings In elastic/ecs#678 and elastic/ecs#589 we have been discussing how n-ary relationship between users in an event should be named and mapping into ECS. In #13530 winlog.event_data.TargetUserName has been mapped to user.name but from the reasons exposed in elastic/ecs#678 and elastic/ecs#589 the mapping winlog.event_data.SubjectUserName -> user.name is more appropriate. This mapping was changed. Also, with the adding of related fields in ECS 1.3 and specifically the related.user field (elastic/ecs#694) all the user names appearing in one event were mapped to the related user events. Every time a SubjectUserName or TargetUserName is copied also is added to the related.user field, as well as other users appearing in the event. Event test data were added for all events with the exception of event 1108 which I was not able to reproduce. Co-authored-by: Lee Hinman <[email protected]> Co-authored-by: Andrew Kroh <[email protected]> Co-authored-by: Anabella Cristaldi <[email protected]> (cherry picked from commit e624aef)
I'm thinking that this issue is overdue to make it into ECS. We're also running into this with Endpoint, as part of the development for process injection telemetry and detection. The interim approach is I'm most interested in source/target for process events. think the most common use cases involve an acting process that "does the thing" and the target process that "has the thing done to it." Do you think that's fair to initially limit scope to that @andrewstucki? We can leave this issue open for the generic source/target problem if you like. @ebeahan Do you think this would be good to make into an RFC, or straight to a PR? I'm thinking that @andrewstucki @gabriellandau either of you interesting in helping drive this forward? |
@rw-access Yes, I do think this topic makes a good RFC candidate. Since this is something that's already been discussed extensively, the initial RFC draft should probably target stage 1. ++ for using |
@rw-access I think it's definitely good to limit this at first, and 👍 on the idea of nesting under the |
Interesting. In the past, we would put something under something else to indicate that it is a property of that other thing. Would Some other questions that come to mind while we're discussing schema layout. A Windows token is a security credential containing your username, groups, and related information. This is where we get the username from. Threads can have [impersonation] tokens that differ from their containing process's [primary] token. An event/action occurs in the security context of the impersonation token, but it can still be useful to know the primary token. These tokens can have different users and IDs. Target threads can be impersonating as well, so we can have:
We're not currently returning impersonation token information, but we may want to in the future. Each of these tokens can have additional relevant attributes, some of which we like to know, such as Integrity Level. How do you think this should all lay out? Here's some pared-down sample data from a 7.12.0 diagnostic (not user-facing yet) alert. Note that this alert describes an action between two threads in the same process, so everything is the same except
|
There is another issue for tokens specifically, #810. Do you think we would scope those separately or are they terribly intertwined and impossible to decouple? (Honest question) The meaning of Good question about target threads. I don't know the right answer, but that does sound like exactly the right thing to hash out on the RFC for target processes: #1297 Wanna be a SME for that? Edit: I think it would be |
This is a more generic application of modeling either "source/target" style events or "diff" events that I'm spinning off from #589
As I initially mentioned (#589 (comment)). There are a number of things that ECS should support modeling including things like:
source
anddestination
)Overall these more or less fall into two categories:
Currently the way ECS has started to approach this is to make fields that are specific to each of these domains, i.e.
source
/destination
are currently for network modeling only, and then there's alsoclient
/server
I'm advocating for adopting a more generic field set that allows you to do generic source/target or diff modeling which would essentially allow you to embed any other field set in it.
For example--something like
origin
andtarget
(sad thatsource
/destination
is already taken):For file modifications:
For process execs:
For network requests (slightly difficult because of the lack of
port
info):For user modification (maybe by another user
baz
who did the modification?):Thoughts?
The text was updated successfully, but these errors were encountered: