ocsf / ocsf-schema

OCSF Schema
Apache License 2.0
625 stars 133 forks source link

Consolidation Efforts Tracking #813

Open mikeradka opened 1 year ago

mikeradka commented 1 year ago

A key point of discussion in the 10/04/2023 System Activity Workstream Sync was consolidation. As OCSF grows, so does its complexity. For instance, consumers would like to avoid having profile bloat - as the viewpoint is that this makes OCSF adoption difficult for consumers and mappers.

I'm adding this issue to capture several key topics the team raised concerns on:

  1. Should we have a regular cadence (monthly?) for looking at OCSF holistically in terms of how attributes/objects/profiles/classes can be consolidated so as to maintain OCSF simplicity?
  2. Should we lay down some concrete rules for Profile creation? For instance - If there is simply a need for a single object, is a profile really necessary? (metaschema opportunity?)
  3. Extensions - We've noticed many new classes spurring up due to individual organizations' needs. a process that worked well in the past was to have individual orgs create their own classes in an extension when needed, and if once that class is refined and the rest of the community see a need for it - then a proposal to have the class added to OCSF Core.
  4. It looks like the Person profile adds a bunch of attributes globally to the user object. To make life easier for adopters, could this be satisfied by simply adding those attributes as optional to the user object?
  5. The Firewall profile - is there room to consolidate it with the Security Control profile? It looks like the only key difference between the two is the firewall_rule attribute. Both profiles have disposition and disposition_id, and a case was made that a Firewall is a Security Control.
  6. Along with 4, there was some discussion around whether Network Proxy could also be consolidated into Security Controls
  7. Date/Time Profile - so important, should this profile need to be specified?
  8. Possibility for a stricter PR Checklist
  9. Container Profile - can the attributes from this simply be added as optional attributes to the Process object?

I imagine that each of these could be tracked as separate issues - but let's at least have them all captured here for now so we can discuss and spin up related issues/pr's wherever necessary

@jp-harvey and @zschmerber hopefully i captured everything here. If you two would like to add any color to this, please feel free to clarify on any of these or capture anything else I may have missed from Wednesday 10/4/2023's sync.

mikeradka commented 1 year ago

Added some extra notes (5,6,7,8) per System Activity Sync on 10/11/2023

query-jeremy commented 1 year ago
  1. A periodic compression would be healthy, but it also implies breaking changes. Changes that can't be managed with @deprecated should be avoided. And in follow up, if @deprecated elements don't already have an expiration date, we should provide one. I motion we purge @deprecated elements at the next major semver bump and not before.
  2. Yes! We could also consider making all relevant profile attributes optional all of the time, or perhaps extending that by making only making required profile attributes required when the profile is enabled. There are currently four required attributes in profiles.
  3. This sounds good.
  4. I'm in favor of merging those attributes into user. The person profile originally applied to user and one or two events, but now it's just user.
  5. No opinion.
  6. No opinion.
  7. No opinion.
  8. Yes!
mikeradka commented 1 year ago

I will give more insight as this progresses, but here is the quick and dirty of what I've captured so far: