ocsf-schema icon indicating copy to clipboard operation
ocsf-schema copied to clipboard

Published 20 hours ago • verified publisher icon ocsf

Review cloud activity event classes

Open Aniak5 opened this issue 3 years ago • 1 comments

Determine whether we need the storage event class or any additional classes within the cloud category or whether the cloud api class suffices.

Aniak5 avatar Sep 15 '22 22:09 Aniak5

We decided to leave the Cloud Activity class for now and we moved the virtual machine class to the System Activity category. Now we need to determine whether we need the storage event class or any other more specific cloud usage classes.

Aniak5 avatar Sep 20 '22 17:09 Aniak5

@floydtree and @paveljos what do y'all think of removing the cloud category and moving the various activities to different categories/classes. image

1 Login activity could go here 2 IAM activity could go in here 3 Operational activity can go into various other classes/categories. As an example, ec2/emr/workspace events could go into the Virtual Machine Activity class.

We could potentially rename the Database activity category to Storage Activity and move the cloud storage activity event class under there.

Aniak5 avatar Oct 19 '22 19:10 Aniak5

Interesting thought; there is a lot to consider here. I agree with the idea that keeping the cloud category for a very small number of potential sources seems to be an anti-pattern. However, in terms of classes, I think the normalization of these events to those classes might be problematic and might make the overlap of "requirements" very thin. I'm still struck by the idea that we're really trying to normalize API calls with the sources that are in here currently. I'll run up some conversation and see if I can get some consensus.

paveljos avatar Oct 20 '22 13:10 paveljos

I believe the most common use case is that analysts (human and software) will process CloudTrail and similar sources holistically, and will most likely not benefit from separating the source across difference categories. However, this brings to mind the conversation we had with @jp-harvey recently on changing from a 1:many relationship between categories and classes to an approach more akin to tagging; that way, we could tag the cloud classes with all of these potential categories.

paveljos avatar Oct 20 '22 14:10 paveljos

That is my concern too. From an analytics perspective you want to have all the data in one schema, especially when you want to detect users deviating from their historic pattern of life. It would be nice to be able to represent cloud api activity holistically as well as individually in more specific event classes (such as storage activity or virtual machine activity). Maybe it makes sense to move cloud storage activity to another category and just keep the generic cloud activity event class?

Aniak5 avatar Oct 20 '22 14:10 Aniak5

Sorry, I have been away for a couple of weeks. I don't think we would benefit from separating out different types of Cloud API events into different event classes for a few reasons.

  1. All these events will in the end need to have the same/very similar schema, as all the events look alike.
  2. As you both pointed out, from an analyst's perspective having a congruent schema for cloud api events would be more beneficial.
  3. Having the ability to filter out all Cloud API events using a single class_uid/name parameter from the entire dataset is a strong outcome of our current scheme. We wouldn't want to lose on that.

floydtree avatar Oct 27 '22 04:10 floydtree

What do y'all think about renaming the database activity category to storage activity and moving the cloud storage event class into there? Would that break any that break anything on your end?

Aniak5 avatar Oct 27 '22 15:10 Aniak5