Processes - Source/Destination

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]

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 [e-mail] 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 https://github.com/elastic/ecs/issues/414#issuecomment-480985894, or mute the thread https://github.com/notifications/unsubscribe-auth/AGDr4tWNbP6SmW8LRWoC9AGpJkpciM5zks5ve6DGgaJpZM4cfhTo .

[webmat]

Oh I thought Willem had opened this one 😉