activity vs disposition vs status

[pagbabian-splunk]

There is some confusion on activity_id on the grammar we want to standardize on for its enum items. The intent of activity_id has been to specify the intent of the thing the event is trying to represent. For example, for File Activity, Create calls out what the actor attempted to do. It does not as such indicate whether the file was actually created, hence the use of present tense.

If the file creation succeeded, the status_id should be set to Success. However, that requires the consumer to inspect two attributes rather than one. In order to attempt to have a single summary attribute for the event, type_uid/type_name is the concatenation of the class_uid/class_name and the activity_id/activity_name. It does not include the status_id/status. In fact, status_id/status is not a required attribute from the base class.

Hence, the premise of how activity, status, and type should work is flawed.

In addition, we have disposition_id, currently used with the Malware profile, which indicates the outcome of an activity in more detail than status. In the white paper, it was intended that when disposition_id is present and populated, type_uid/type_name would concatenate disposition rather than activity, with the assumption that it imparts more information than simply the intent of the activity.

In summary:

• type_uid/type_name is intended to impart as much information about 'what happened' as possible
• activity_id is used to show what action or operation (activity) the event was representing, and so we combine it with the class_uid/class_name to have a single derived attribute representing the event
• disposition_id describes the action taken by the security product or control.
• we want status_id to indicate the success or failure of the activity or disposition
• status isn't represented in type_uid, hence sometimes there is a tendency to include those resultant states as an activity (past tense vs. present tense as well).

Option 1:

One option is to extend the derivation of type_uid/type_name to include status_id/status. It would now be class+activity+status. When there is a disposition, we would derive type_uid/type_name to be class+activity+disposition.

Even when there is a security product imparting a disposition (such as Blocked, Dropped, Delayed) there can be a status that is either Success or Failure. We just wouldn't include it in the derivation as it is an edge case IMO (that is the security product attempted to block the file creation activity, the disposition is Blocked, but the block failed, so status would be Failure).

As we can only map what is emitted from the product or service, you may not know the activity but you may know the disposition (e.g. Refused, Reset). In those cases the activity is indeed Unknown. The verbiage would be awkward, I admit - e.g. Network Activity: Unknown: Reset). But it would be deterministic and consistent with cases such as (DNS Activity: Query: Blocked).

For normal activity without security controls, it would be - File Activity: Open: Success.

status_id/status would need to be Required in this case. status string might need to conform the status_name convention.

This would constitute a breaking change. If we want to consider it, it should be before 1.0.

Option 2:

Another option is to relax the grammar and semantics on activity_id/activity_name to allow disposition-like items (e.g. Refused, Established, for an activity of Open). The downside is we lose information if the information is present (e.g. Open) although it can be inferred in some cases, but not all. For example, is Refused due to an Open activity or due to a Close activity, or with access controls, is Refused due to a Read activity?

This option is the least intrusive, although many of the existing enums would likely need to be extended and the combinations of what would have been activity+disposition (only in option 1) or activity+status (again from option 1) could get large and practically unbounded.

Status could continue to be optional. disposition would be used with Malware for malware events (and hopefully other security profiles).

This would NOT constitute a breaking change, although enum values changing would be breaking, and enum values being added such that existing population changes MAY constitute a breaking change.

[jasonbreimer]

I like option #1. +1 vote. You had me at deterministic. While a little more complex it has a logical order I appreciate. And includes the details.

Option 2 feels too mushy.