OCSF will benefit from self-certified tiers of compliance, as well as simpler onboarding for new implementations

[pagbabian-splunk]

As some of you know, the Steering Committee has time to time considered a certification process for OCSF compliance. We have been reluctant to do that so far due to the operational aspects of it, given all the other things that have been done to build the community, framework and core schema. However now that OCSF is well known industry-wide, what does it mean when a vendor says they support OCSF?

I've talked to many industry analysts about this, and they are very supportive of the idea of being more clear on what OCSF support by a product can mean for interoperability at minimum, and degree of commitment to the standard. I'm always asked, which products are supporting OCSF and aside from some of our more active members' products, and our active consumer companies, I usually say I don't really know. I know that some companies are saying they are or will support, but what classes, what depth of population of those classes, what percentage of their logs, is the support at the import/export boundary only or more native, etc.

Related to this, is the perceived difficulty of supporting OCSF. At vs 1.6 the core schema is fairly large, the complexities of profiles makes the learning curve a bit longer with more questions as to how to map, and in some cases, just too much of a barrier to even get started.

To kill two birds with one stone figuratively, having a basic, simpler tier of compliance spelled out can make new onboarding easier, including for tools that assist in that (we have lots of new tools cropping up), while at the same time giving customers and industry analysts more to consider besides marketing claims (we love those too of course).

We've seen in Slack some discussions around just using the Base class, but putting everything in message or unmapped isn't really desirable, yet I wouldn't be surprised if much of the claimed OCSF support does something like this (not all bad mind you, just not enough).

Here is a straw man for what a Basic or tier 1 compliance might mean.

1. Populate Base class Required Classification attributes. This is table stakes. category_uid/name class_uid/name activity_id/name type_uid/name. The semantics of the event are largely captured by type_uid/name.
2. Populate Required Base class time severity/_id and Recommended status/_id message attributes. The outcome of the event is reflected by these attributes.
3. Populate the relevant Recommended observables array objects. Recommended observables[].name Required observables[].type/_id Optional observables[].value would be needed. The affected entities and targets, primary actors are carried here.
4. Populate the Required metadata attributes. product object and version of the OCSF schema (less important given the thinness of the event since the above is in every version of OCSF).
5. Optionally, extracted key/value fields can be carried in the Optional unmapped Object. This is better than nothing for a thin event of this type.

That's it for a basic, or tier 1 OCSF event! Easy right? Yes, it doesn't always convey what really happened if the message isn't good, and the roles of the observable attributes might be ambiguous. But this might be still better than what CEF has been over the last 20 years.

Many vendors extend the schema with their own extension. By definition, as long as they use the framework, anything can be modeled in an extension. Even new dictionaries and categories. However, I'm unsure of whether a tier 2 could mean tier 1 + vendor extension, and if so, are there any constraints on a vendor extension such as supporting existing categories, and/or classes? Because in some cases, a very richly modeled vendor event might populate core classes but also extend the schema - it's after all more advanced to create an extension schema than to use the core schema, in most cases. But it can also be a short cut to not studying the core schema before embarking on an extension.

Maybe there is no intermediate tier, just a tier 2 for fully modeled.

Would welcome comments.

[mavam]

Awesome topic, Paul! This is exactly the kind of conversation we need to be having to make OCSF truly stick. We've been kicking around some similar ideas at Tenzir on how to make this whole process less painful and more valuable.

A Simple Pathway to Get Started

We see a pretty natural pathway for folks getting started, which could help with the learning curve.

It starts with just getting the raw log in there (Level 0). The next big win is parsing that mess into records in the unmapped field and filling out the basic OCSF headers (Level 1). That step alone is a huge leap in value. The holy grail, of course, is Level 2: a fully, semantically mapped event.

What Does "Fully Mapped" Even Mean?

But that "fully mapped" part is where things get fuzzy and where all the hard work is. We think it boils down to two main questions: "how good?" and "how much?"

First, there's Mapping Quality—basically, how good is the mapping? We could use a weighted score where you get the most points for nailing the required fields, a good chunk for the recommended ones, and bonus points for the optional stuff. It's an attempt to measure how useful the final event is for an analyst. That said, I'm not totally sure analytical utility always lines up with the required/recommended flags. That's definitely something to hash out!

Then there's Mapping Coverage—or, how much of the original log did you manage to map? The key here is to be fair. You can't expect someone to map a field if OCSF doesn't even have a spot for it. So, the score should be based on the percentage of realistically mappable fields. Of course, then you have to ask: who decides what's 'realistically mappable'?! Someone has to! The cool side effect is that all those 'unmappable' fields become a to-do list for the OCSF team to improve the schema.

A Quick Thought on Extensions

As for extensions, our rule of thumb would be to use them only as a last resort for data that genuinely has no home in the core schema. Using them as a shortcut to avoid a proper mapping feels like it should be off-limits for any kind of 'certified' event. A "Gold" mapping should mean you've mastered the core schema first.

[hmadison]

Hey Paul,

I went and took an example Meraki IDS event and (attempted to) translate it to OCSF under your proposal by only implementing the required options.

{
  "time": "1377449842",
  "message": "MX84 ids-alerts signature=119:15:1 priority=2 timestamp=1377448470.238064 direction=egress protocol=tcp/ip src=192.168.111.254:56240",
  "activity_id": 1,
  "category_uid": 2,
  "class_uid": 2004,
  "finding_info": {
    "uid": ""
  },
  "metadata": {
    "version": "1.6.0",
    "product": {
      "name": "Merkai",
      "vendor": "Cisco"
    }
  },
  "severity_id": 0,
  "type_uid": 200401,
  "observables": [
    {"type_id": 2}
  ]
}

Is this the kind of translation you had in mind?

Thanks,
Hunter

[pagbabian-splunk]

Thanks Hunter, yes it is, although my strawman required the enum siblings to be populated (for ease of reading) and the observables[].name/value to be populated. But basically this is what I had in mind yes. If we want the event to be as 'thin' as possible though, dropping the enum siblings would save space, and the consumer would have to look it up.

[floydtree]

Great topic @pagbabian-splunk. I want to approach this by using existing requirement constructs that we already have in place, as much as possible. (perhaps add a metaschema construct like compliance_tier: 1 to the cases where requirements aren't sufficient. (case in point, observables, those aren't required in the schema today, and we cannot make it required for backwards compatibility) This will allow to keep things -

1. Straightforward to understand as a user of OCSF, using concepts which are already a part of the frameworks (requirement, compliance tag)
2. Simple to maintain compliance tiers, puts more onus on each future PR and pushes to inspect each proposed requirement more clearly
3. Simplified evaluation of tiers - extend our validation API to output tiered classifications based on in-schema constructs.
4. Help users understand our tiers without separate layers of documentation. (i.e the output schema should tell me everything needed)

But there's one underlying issue that we need to address first. Something that mavam surfaced in his comment as well -

That said, I'm not totally sure analytical utility always lines up with the required/recommended flags. That's definitely something to hash out!

Before we can make a meaningful usage of OCSF's current recommended optional attribution, we'll need to review of it's accuracy and relevance from an analyst's perspective.
@ocsf/ocsf-maintainers this could be the task zero we need to address before we can derive a tiered compliance approach.

--

Side - @mavam I like your approach for a weighted model, something similar to what I had in my mind. I would add weightage to unmmaped utilization as well (the higher you use unmapped the lower the score)

[mavam]

Before we can make a meaningful usage of OCSF's current recommended optional attribution, we'll need to review of it's accuracy and relevance from an analyst's perspective.
@ocsf/ocsf-maintainers this could be the task zero we need to address before we can derive a tiered compliance approach.

That would be excellent! Although I bet it will cause a lot of discussion because everyone sees their use case as very important.

the higher you use unmapped the lower the score

I started like this as well, but then I realized that unmapped is not bad per se. Only if there actually exist possible mappings out of it. That's why I'd define coverage with the denominator being the number of fields that actually can be mapped, not just number of fields in unmapped.