Rename actor_process to process in host profile

[awhite456]

Background

Currently, all events in the System Activity category require an actor_process, defined as "The process that performed the operation or action on the target object.". This field represents the process that is performing the action, such as the process reading a file in a Filesystem Activity, or the process creating a registry key in Registry Key Activity. The field actor_process is defined in the hosts profile.

Issues

There are two main issues with the term actor_process. Firstly, in all events except Process Activity, there is only one process, making the prefix actor_ superfluous. End users will be expecting the process for a File System Activity event to be called process, not actor_process. Secondly, in the case of Module Activity, actor_process is both the actor and target of the operation, which has confused end users as there is no other object for actor_process to be operating on.

The edge case for this proposal is Process Activity, which has two process objects. These two process fields contain the source and target of an operation, eg actor_process operates on process. To remove the actor_ prefix, we would need to rename the second field to something like target_process, such that process operates on target_process. This is arguably more intuitive than the original name pairing, as it is better in line with the source/target nomenclature used by the industry.

Options

Option 1

Rename actor_process to process across all events, and to handle the conflict in Process Activity, rename the existing process to target_process.

Option 2

Leave everything as is

[rroupski]

If we rename the actor_process as process and process as target_process, then we are going to create an inconsistent schema. To fix it, we will have to create new attributes for file, reg_key, reg_value, etc. with a target_ prefix, which will increase the schema dictionary.

[pagbabian-splunk]

I see this as '6 of one, half dozen of another' and as to which is more intuitive, I think that is subjective. I wanted to think of this in a more general way. The only reason we have actor_process is because this one class, Process Activity, had two process objects and there was an attribute name collision. The reason that the 'secondary' process used the process attribute and the 'primary process' became actor_process was to distinguish the roles, but also to be consistent with other activity classes where the primary role was a process, and the secondary role was something else, like a file or a registry key. In those cases, the secondary objects also used the generic attribute name (file or reg_key). Including actor_process in the host profile exacerbated things by spraying it out to many more classes (potentially).
Therefore, rather than drop the simplicity we would have had without the one case of a collision, or live with the inconsistency of having one class that doesn't use a simple generic attribute for the secondary object, there needs to be another construct that can solve both problems.
A suggestion has been thought about a bit for this which I will outline shortly.

[pagbabian-splunk]

Per the above discussion: if we did not have two process attributes in Process Activity, we would have used the process attribute everywhere (including in other classes where process is a primary object). There would not have been a need for an actor_process. However, the host profile carries a process attribute so that Network Activity events that originate from a known host can indicate what process is making the connection. It also carries the device. The user profile carries the user.
If we combine the host and user profile attributes into an object named Actor we can disambiguate the two process attributes in Process Activity with the convention that no event class can have more than one actor.
Process Activity would have an actor.process as the primary and a process for the secondary without collision. The other profile attributes of host and user are implicit in System Activity classes, hence the new Actor object could now be part of a new profile named actor which would replace the host and user profiles.
An actor is one or more of [process, device, user] assumed to be coincident with the activity.

[awhite456]

Ended up going with the actor object, which can have a process (among other objects)