Clarification on Proper Placement of Parent Process Details in Process Event (ACTOR vs PROCESS.PARENT)

[threatdecoder]

Description:
I have a question regarding the appropriate placement of parent process details in OCSF for process events, specifically in the case of process creation events with activity_id set to 1.

The current schema has two fields that could potentially be used to store details about the parent process:

process.parent: As per the OCSF documentation, this field is explicitly designed to capture information about the parent process (i.e., the process that spawned the current process).

actor: According to the description of the actor field, it represents "the actor that performed the activity on the target process. For example, the process that started a new process or injected code into another process."

Given this, there seems to be overlap between the two fields when it comes to process creation events, where the parent process can be considered both the "actor" (initiating entity) and the hierarchical parent.

Doubt/Clarification:
Should the parent process be stored exclusively in the process.parent field in process creation events to adhere to a more hierarchical approach, or is it acceptable to also store the parent process details in the actor field?

For clarity and standardization, should we exclusively reserve the actor field for other entities like code injection or external actors (e.g., a remote machine or user) that perform actions on processes?

If we are to store the parent process details in the actor field, would this create confusion, since the process.parent field exists for that specific relationship? Is there a scenario where both fields should contain the parent process details?

[mlmitch]

There is certainly overlap between these two fields. However, on some systems (e.g. Windows) the "parent" and the "creator" can be different. Here is an article on creating a process with a parent other than yourself in Windows. An endpoint solution with sufficient visibility can see both the creator and the parent. You would use the parent field for the parent and the actor field for the creator.

On some platforms (e.g. linux) the parent and creator are always the same. Additionally, on the above systems, parent and creator will usually be the same. So, even though there is justification for both locations existing, implementors need to decide how to handle the situation where they will be the same information. My team leans toward always filling both in and dealing with the redundancy. This ensures dataset queries against parent and actor both function properly.

This thread does end up pointing to a potential gap in the schema though. The process object does not have a dedicated field to represent it's creator. This means the only time that both parent and creator can be communicated is in the process launch activity. I'll start a thread about this in the slack.

[threatdecoder]

Thanks @mlmitch for the clarification.

I take "creator" is the real process which actually launched the process, and "parent" being the one which is assigned to be.

Is it correct to keep "creator" in "ACTOR" and "parent" in "PROCESS.PARENT" ?

[mlmitch]

Is it correct to keep "creator" in "ACTOR" and "parent" in "PROCESS.PARENT" ?

I believe this is the correct way.