Examine and clarify the desired behavior of overlaying profiles on existing attributes

[alanisaac]

Background

In OCSF's schema definition files, there is the concept of a profile. As documented here, a profile is akin to an overlay or mixin:

Profiles overlay additional related attributes into event classes and objects allowing for cross-category event class augmentation and filtering. Event classes register for profiles that when optionally applied, can be mixed into event classes and objects, by a producer or mapper.

As described further on in the documentation, classes may explicitly declare attributes that overlap with a profile. The described behavior is that the class defined attribute requirement (e.g. required, recommended, optional) takes precedence over that of the profile:

However some classes, such as System Activity classes, build-in the attributes of a profile, for example the Host profile attributes device and actor are defined in the class. When a class definition includes the profile attributes, it still registers for that profile in the class definition so as to match any searches across events for that profile. In this case the class defined attribute requirement definitions take precedence.

As discussed in the working group call on 03/05/2024, this behavior may or may not be desired. Specifically, it was not clear if a profile with a more restrictive requirement should be overridden by an explicitly declared attribute with a less restrictive requirement.

Examples

1. when a profile attribute is more restrictive than an event attribute

This can be seen in action today with the combination of the rdp_activity event in the network category and the host profile:

• The event as represented by the schema server can be seen here: https://schema.ocsf.io/1.2.0-dev/classes/rdp_activity
• The event as represented by the OCSF schema definition can be seen here: https://github.com/ocsf/ocsf-schema/blob/main/events/network/rdp.json
• The host profile as represented by the OCSF schema definition can be seen here: https://github.com/ocsf/ocsf-schema/blob/main/profiles/host.json

Note how the host profile includes a recommended device attribute, but the rdp_activity event includes a less restrictive optional device attribute.

On the schema server, the "device" attribute is not shown unless the host profile is active, and when the profile is active, it is shown with the less restrictive optional requirement.

2. when a profile attribute is less restrictive than an event attribute

This can be seen in several cases, but here we'll use the same host profile and the patch_state event in the discovery category:

• The event as represented by the schema server can be seen here: https://schema.ocsf.io/1.2.0-dev/classes/patch_state
• The event as represented by the OCSF schema definition can be seen here: https://github.com/ocsf/ocsf-schema/blob/main/events/discovery/patch_state.json
• The host profile as represented by the OCSF schema definition can again be seen here: https://github.com/ocsf/ocsf-schema/blob/main/profiles/host.json

Note how the host profile includes a recommended device attribute, but the patch_state event includes a more restrictive required device attribute.

On the schema server, the "device" attribute is shown with the more restrictive required regardless of whether the host profile is active. When the profile is active, interestingly the additional actor attribute from the profile does not seem to appear.

To Do

The above behavior in the OCSF schema server does conform to what is stated in the documentation, in a way: the requirement of the event is always preferred over the requirement of the profile. However, there does seem to be some inconsistency on whether attributes exist or not based on whether the profile is applied. Why doesn't the device attribute exist on rdp_activity without the host profile applied, and why does the actor attribute not exist on patch_state when it is?

[alanisaac]

Why doesn't the device attribute exist on rdp_activity without the host profile applied

I recently learned that preventing this behavior is the purpose of "profile": null, though this feature does not seem to be well-documented.