Handling platform specific classes and profiles

[pagbabian-splunk]

Per discussion over the last few weeks on how to handle "platform specific" classes and profiles, we considered a few approaches:

1. Handle via profiles in core only, e.g. Windows Log
2. If 1 cannot correctly model the event, add platform specific classes to core, e.g. Windows RegistryKey Activity
3. Handle all platform specific classes and profiles via normal selectable extensions
4. Handle all platform specific classes and profiles within a separate selectable platform section (new idea)
5. As 4 above, but filter out classes and profiles that are not relevant or used by the platform

Item 4 will be constructed almost the same as normal extensions, but would be "first class" extensions, populated via the OCSF PR process. Unlike item 3, schema definitions would be within a platforms folder, rather than the extensions folder or other extension repo.

It should be noted that a normal extension could add platform specific classes and profiles that would also populate the platform section. They would only be available in the platform section when the normal extension is selected, differing from those that were part of the OCSF PR process.

Please vote by EOW if possible.

[awhite456]

As an example, this PR adds a Linux platform to add a Linux-specific profile, which augments process objects with extra Linux-specific fields. #584

[pagbabian-splunk]

We now have Platform extensions as part of RC3.