Disambiguate the user context of the process object

[jp-harvey]

TL;DR

The user context under which a process object runs has caused ongoing confusion in the current implementation. It is proposed to disambiguate the situation through renaming the run_as field along with clarification in the associated attributes of the field.

TL; but read it anyway

Currently the process object defines the following field:

{
    "run_as": {
        "_source": "process",
        "caption": "Run-As User",
        "description": "The user account the process is running as, for when a user is impersonating another user.",
        "object_name": "User",
        "object_type": "user",
        "requirement": "optional",
        "type": "object_t"
    }
}

When tracking process activity, the user profile can be applied to provide a user field for the object.

This structure has repeatedly caused confusion about what these two things actually refer to (eg. discussion on #113 (comment)). It has been conveyed that the intent of the user from the profile is that it refers to something like a session, and run_as is to be used if the user is different from the session user.

Every process runs in the context of a user and this is an unambiguous concept, however determining the user context in OCSF is structured in a way that it is open to interpretation. The user profile is not enforceable, and even if it was it's not actually specifically referring to the context in which the process is running (it's inferred). When combined with the fact that run_as is a Windowsy term indicating starting a process as another user, as it does in OCSF, we end up with a multi-step method of determining what user context a process is running as, the logic being: use run_as, if it's blank use the user field from the user profile... if it has been applied. This is also without considering parent processes and how many ancestors a process has and how many different user contexts are used for those - tracking lineage then becomes more convoluted.

It has also been discussed during calls that run_as is actually the user context of the process, in which case the description is not accurate (and name arguably confusing). Whether this is the case or not, it only highlights that there is indeed confusion around the current structure and it the implementation is non-intuitive.

Following brainstorming by the system activity maintainers, this proposal seeks to reduce the ambiguity around the user context of a process and align it to what prototypical source data producers emit (eg. Sysmon, DTEX, Crowdstrike, Tanium), as well as make the language more generic across operating systems, by way of the following:

Proposed Solution

1. Rename the run_as field to user
2. Change the caption of the run_as user to "The user context"
3. Change the description of the current run_as field to: "The user context in which the process is running."
4. Change the requirement for the current run_as to recommended
5. Modify the user profile as it pertains to process_activity to represent a session_user (eg. Windows desktop session, ssh session etc.) <- note that this may have wider implications than are recognized here and need more thought
   JSON representation of changes:

{
    "user": {
        "_source": "process",
        "caption": "User context",
        "description": "The user context in which the process is running.",
        "object_name": "User",
        "object_type": "user",
        "requirement": "recommended",
        "type": "object_t"
    }
}

This disambiguates the user context under which the process is running. We do not lose any information about impersonation since that is available by looking at the parent_process object's user context. The user profile can still be applied to provide the additional context of the user "session", being defined as "the actual user doing the thing, if you choose to include it, and however you have determined that (eg. Windows desktop session, ssh session etc.)"

[AWSSecEng]

Agree on disambiguation. Ensuring the schema is as self describing and contextually interpreted is important.

Only additional question I would have if it would even more clear if the field was net new: user_context

[paveljos]

Same as above; I'm concerned with ambiguity with what is intended with a user field, especially since user exists in different contexts (e.g., the identity object). I think the break down is close to what I would expect, but would recommend a name change for the field. I'm only commenting so you can understand what is intended by my vote for the second proposal above.