Capturing client application context in OCSF activities

[jwes2]

Modern authentications and API activities to cloud resources (AWS, Azure, GCP, etc.) and SaaS applications (Microsoft Office 365, Google Workspace, etc.) often create activity logs that contain information not just about the user identity performing the activity, but also the client application identity.

We had some small group discussions about how best to capture this client application information and I will use this Issue to capture our current thinking for a possible solution.

The client application identity is used in conjunction with the user identity when authenticating and authorizing activities against resources. For this reason, we feel the client application context (id, name, etc.) should be captured similarly to the way user identity context is captured in OCSF.

There are several approaches we considered in our small discussion:

1. Using the user object to capture the client application attributes. The pros to this approach are that the client app identity aligns conceptually to the user identity. The problem with this approach is a) the name "user" does not align well to the client application. and b) the OCSF user object is not an array, meaning one could capture either the user identity or the application identity, but not both.
2. A close alternative to (1) would be to add an additional new object (client_app) as an attribute of the user object. The downside is it may imply (incorrectly) that the user identity is somehow tied to the application identity, which it is not. The user is merely using this application, they are in no other way associated with the application.
3. (small group preferred this approach) Another approach we considered is to add a new object (client_app) as an attribute of the cloud object, which is added to classes via the cloud profile. The cloud object already has user identity conceptually as part of the object, by virtue of the account attribute. Adding a client_app attribute would be a convenient, and we thought logical, place to host the context of the client application used during an activity.
4. The API object (also added to classes via the cloud profile) is another place we considered to host client application context. However, this was generally agreed as not ideal, as all the existing information in the API object is related primarily to the server/resource context, not about the client. The only client side information currently in the API object is the request elements attribute, but even that doesn't have any context to do with the caller's identity. For these reasons this was ruled as not a good option.