Processes - Source/Destination

[neu5ron]

Looking into the ECS documentation there is a process schema however
I would like to discuss and propose adding or documenting an additional process schema for source and destination.

This is especially useful in endpoint data. Process spawning, one process accessing another, etc...

Process Spawning

scenario:

"cmd.exe" creating "powershell.exe"

example:

"source.process.name": "cmd.exe",
"destination.process.name": "powershell.exe"

[neu5ron]

additional comment for using destination versus “target” —- I think the word “target” has too much emotional attachment for the analyst/user - this leads them to focus more on the destination when the source could be just, if not more, suspicious.

also, I am open to suggestions of using parent/child for the process name.

[webmat]

Yes, I've mentioned the reuse of process at process.parent in another issue you've opened. But this would only address the process spawning activity.

We may need something to address processes interacting with one another as well, however. That's a good point.

As we've discussed already, I'd prefer keeping source/destination purely about network if possible. I've been thinking we need another "pair" in addition of src/dst and cli/srv: local/remote. And in that same line, I'd like to eventually find a way to manage and document these 3 pairs together, as a simplification... So it's not a hard no, but I'm trying to find other ways first.

Point taken on the emotional baggage of "target".

Perhaps we could use "affected"?

User management: user & affected.user
Process shenanigans: process & affected.process

[neu5ron]

im good with not using src/dst for processes, how about for processes and corresponding cli as well, to use parent/child parent.process.* child.process.* I think the user fields will be hard, because of the many scenarios like fromt/to smtp fields, one user account logging into remote box using another account, user account modifying a user account, etc. I sometimes can see user & affected.user, then I see scenarios where src/dst user makes a lot of sense. ^ this will probably require more discussion.

…

On Mon, Apr 8, 2019 at 4:04 PM Mathieu Martin ***@***.***> wrote: Yes, I've mentioned the reuse of process at process.parent in another issue you've opened. But this would address the process spawning activity. We may need something to address processes interacting with one another as well, however. That's a good point. As we've discussed already, I'd prefer keeping source/destination purely about network if possible. I've been thinking we need another "pair" in addition of src/dst and cli/srv: local/remote. And in that same line, I'd like to eventually find a way to manage and document these 3 pairs together, as a simplification... So it's not a hard no, but I'm trying to find other ways first. Point taken on the emotional baggage of "target". Perhaps we could use "affected"? User management: user & affected.user Process shenanigans: process & affected.process — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#414 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGDr4tWNbP6SmW8LRWoC9AGpJkpciM5zks5ve6DGgaJpZM4cfhTo> .

[willemdh]

Hello,

Working on getting process creation (4688) and process termination (4689) into siem.. So I will aslo need a spot to put winlog.event_data.NewProcessName and winlog.event_data.ParentProcessName

Process termination only have 1 field, aka winlog.event_data.ProcessName. So a spot to put the parent process would get me going.

Currently I'd go for something like

process.parent.name

Thoughts?

Grtz

Willem

[webmat]

Does the recent addition of process.parent (#612) solve this for you? Are you missing anything?

[neu5ron]

yup works for me

[webmat]

Oh I thought Willem had opened this one ;-)