ocsf-schema
ocsf-schema copied to clipboard
ocsf
v1.0 producer / log source compatibility
OCSF is a framework where the base event classes should produce the same outcome for an event regardless of the vendor generating that event. To that end, "supporting" log sources means ensuring that multiple producers confirm that the schema is robust and flexible enough to accommodate the data they produce / report on.
For example, if product A and product B both send process_activity logs, the end result after conversion to OCSF should look structurally the same, with the exception of optional attributes and any producer / vendor specific fields and objects which would be supported via an extension.
This issue aims to track the requirement for v1.0 that a minimum of 2 vendors or producers have confirmed that their data / logs can be converted into OCSF format, and as a secondary objective to confirm that two producers converting the same event data to OCSF format yield the same result.
I believe this leads to documentation and the greater question, "what does supported mean" and what does that look like.
Following discussion last week in the group call and again today, "supported log sources" is probably better described as "logs that can be supported by OCSF". @pagbabian-splunk put it well when he described OCSF as a schema that will yield the same result when logs from different products that do the same thing are converted to OCSF format. Or more precisely, that the core OCSF fields will look the same, and any differences are vendor specific and supported through an extension.
To that end, it was discussed that one approach to defining what needs to be supported for v1.0 would be to have a list of all the classes, and x (2-3?) vendors for each class certify that OCSF can accommodate their logs. I will update the title and description of this issue to reflect a list based on what was discussed, and put some vendor names in to start kick things off - either DTEX or something I know another vendor does or is working on - and we can iterate on the list.
Suggest this be matrix expanded to include
- Specific product
- Ingest vs Produce
- Some way to specify feature/function area in the product.
Some vendors have a lot of products and will have various different aspects of OCSF support across their portfolio at different points in time, and some products even both produce and consume data and may support subsets of one but not the other at any point in time.
@JasonKeirstead - Agree those are good points and we have representation from several orgs with prioritized support lists. I'd suggest that each vendor themselves can self-select and list where they'd like to start.
Follow on question - do we want to set a goal for number of distinct log sources as confirmation of an event class's v1.0 eligibility?
@JasonKeirstead yes definitely. Because GH is a fixed width adding a lot of columns will be troublesome, it would be better done in some other collab tool, but the plan is, once we have a bit more data, to create individual issues to track each one which can have the details, and link to those issues from this table.
Also @JasonKeirstead you make a good point about ingest vs produce. My assumption was that for v1 we'd focus on producers, since producers primarily determine many of the details of the schema which is the point we're at (the main structure is done). Do you think we need to certify / verify ingest as well for v1?
@jp-harvey I don't know, but there are several OCSF members who are likely focusing primarily on consume use case right now - us for example and I have to presume Splunk... arguably AWS...
Coming in late on this one but consumers like Splunk are also Mappers, which is closer to Producers. Both Producer and Mapper personae populate the classes and structure. Analyst personae SHOULD be able to make sense out of the populated classes.
