New Resource Activity

[odianosen]

Proposal for a new Resource Activity event class, related to the Resource object discussion. This class takes inspiration from Entity Management, and extends it for additional event types and use cases.

{
  "caption": "Resource Activity",
  "uid": 7,
  "name": "resource_activity",
  "extends": "audit",
  "description": "Reports activity on resources.",
  "attributes": {
    "activity_id": {
      "enum": {
        "1": {
          "caption": "Create"
        },
        "2": {
          "caption": "Read"
        },
        "3": {
          "caption": "Update"
        },
        "4": {
          "caption": "Delete"
        },
        "5": {
          "caption": "Enable"
        },
        "6": {
          "caption": "Disable"
        },
        "7": {
          "caption": "Search"
        },
        "8": {
          "caption": "Add User"
        },
        "9": {
          "caption": "Remove User"
        },
        "10": {
          "caption": "Export"
        },
        "11": {
          "caption": "Import"
        },
        "12": {
          "caption": "Share"
        },
        "99": {
          "caption": "Other"
        }
      }
    },
    "actor": {
      "description": "Use for when the entity acting upon another entity is a process or user.",
      "group": "context"
    },
    "resource": {
      "group": "primary",
      "requirement": "required"
    },
    "related_resources": {
      "description": "Other resources that were directly or tangentially involved in the activity. For example, User added to a Group, where Group is the primary resource and User is a related resource",
      "group": "primary",
      "requirement": "optional"
    },
    "configuration_id": {
      "description": "The normalized identifier of the type of configuration updated, if the activity was a configuration change.",
      "requirement": "optional",
      "enum": {
        "1": {
          "caption": "Privileges"
        },
        "2": {
          "caption": "MFA"
        },
        "3": {
          "caption": "Session Duration"
        },
        "4": {
          "caption": "External Sharing"
        },
        "5": {
          "caption": "Password Policy"
        },
        "6": {
          "caption": "Login Url"
        },
        "7": {
          "caption": "Logout Url"
        },
        "8": {
          "caption": "Single Sign-On"
        },
        "9": {
          "caption": "Password Reset"
        },
        "99": {
          "caption": "Other"
        }
      }
    },
    "comment": {
      "description": "The actor provided comment about why activity was performed on the resource.",
      "group": "primary",
      "requirement": "optional"
    }
  }
}

[rroupski]

This new/updated class overlaps with the existing event classes:

If the resource is a File or Folder, then it is pretty much the same as the File System Activity class.

The Add User and Remove User activities overlap with the Account Change class.

[odianosen]

If the resource is a File or Folder, then it is pretty much the same as the File System Activity class.

Perhaps, but I think that's a problem that derived from the broadness of the Resource object. As long as Resource contains known types like File, Device etc, I think an overlap with existing classes will always exist.

The Add User and Remove User activities overlap with the Account Change class.

No, it's different. Perhaps it's named badly here, but these activities point to adding/removing user access to this resource, rather than general account management.

[k2niner]

If the resource is a File or Folder, then it is pretty much the same as the File System Activity class.

We need to be able to log/audit CRUD operations for files (and folders) at locations other than the OS File System.

[pagbabian-splunk]

It would be useful to see some sample logs or events so we have a better idea how to model more specifically. For SaaS activity, we should look at bringing forward Application Activity, but improving it as it has a very narrow Systems Management focus. Also Access Activity needs work - it needs a resource object, but it focuses on granting and denying access. However, things like Search that is included here could also be considered access. But adding and removing users, that is a more specific activity already covered.

[odianosen]

For SaaS activity, we should look at bringing forward Application Activity, but improving it as it has a very narrow Systems Management focus

By Application Activity, are you referring to https://schema.ocsf.io/classes/dev/application_log, or something else?

Also Access Activity needs work - it needs a resource object, but it focuses on granting and denying access

I think this makes sense - Access Activity could define granting and denying access to resources. The risk is that the more the Resource object grows, the greater the chance of Access class inadvertently overlapping with something else. We could simplify Resource to exclude types already defined (like File), and include a field in Access Activity for the type of the target object - which could be Resource, File, etc.

But adding and removing users, that is a more specific activity already covered.

It's mis-named in this proposal, but adding and removing users referred to here means adding and removing user access to this resource, rather than general user management. Of course, following on from my the previous comment, maybe Access Activity can cover for this.

[k2niner]

Concur that we should look at Access Activity for targets beyond "application" and possibly consider a name change to Access Control Activity.

[pagbabian-splunk]

I will make this a topic for tomorrow's call - we've had a lot of discussion in and around it, super good discussion, but let's zero-in on the intent we have at the activity level first and the Resource object changes should follow that, rather than the other way around. E.g. we have the equally ambiguous Managed Entity object to consider as well.

[odianosen]

As discussed, Resource Activity is too broad, and it's function will be split into other existing and new classes.