Usage of the Actor object

[rstillio]

Reaching out to the community to ask for input on your usage of the Actor object.

At present, the schema refers to an actor as a user, role or process. The OCSF definition of the actor object states: "the Actor object contains details about the user, role or process that initiated or performed a specific activity." I like how @pagbabian-splunk describes it here when he says "An actor is one or more of [process, device, user] assumed to be coincident with the activity." Coincident - Occurring together in space or time. In agreement or harmony.

As a mapper, I'm increasingly aware of the fact that not all event sources or product types are going to have this definition of actor in their payloads, and that's OK. Many network devices, firewalls, flow records, etc. all good examples.

The question was raised to me when evaluating network-oriented datasets, what is the Actor? Is it the source IP? The entire 5-tuple? After great cogitation, I've come to the postulation that the answer is nothing. Because not all events have to have an Actor.

My personal biases lean me towards Actors being something bound to one of People, Identities, and Processes (system and host-level). Only because those things can be reliably made coincident. Beyond that, as an analyst I'm no longer investigating an actor, but the artifacts of those activities as they are observed within the tech stack. For example, I would argue there's no actor in a Flow record or IDS alert. Sure, there are IP's that can be correlated back to systems, where we have a chance at trying to correlate up to a session, process ID, and land on an identity. To call an IP address an actor seems like a bit of a leap.

Another point of view on this is to assume everything could have an Actor. I would question at what point down the OSI stack do we lose the ability to reliably associate an 'actor' back to user, role or process?

Lastly, and as a complete aside, I would submit that the term actor (when not qualified) should never imply intent (good or bad). Actor, in the OCSF definition, should not mean "malicious" or "bad guy", or "evil bits", it just means one who "initiated or performed" an activity. In practice, this could be increasingly at odds with many SOC, Threat Hunt, Threat Intel, Detection Engineering and IR end user roles, where differentiation between threat actor and remediation actor take on different context.

How does the broader OCSF community view this?

Mappers, how have you handled 'Actor' objects in context to Network-oriented datasets, or any dataset for that matter, that doesn't have payload directly referencing a "user, role or process that initiated or performed a specific activity"?

[zschmerber]

I have found this is easiest to explore with log examples. Do you have one sanitized log you can share where we can explore?

I made this to help:

[threatdecoder]

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

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?