Include a standard translator format in OCSF

[Res260]

Right now, as a mapper, the only choice I have to create a translator from raw events to OCSF format is to use ocsf-java-tools, which provides a CLI and classes to do the transformations. That's great. However, according to the documentation, I would have to create a mapping rule file in JSON.

It's very ugly. Here is an example.

JSON was never meant to be maintained, created or modified by humans, but it's currently the only choice the mapper community has to translate to OCSF, without having to re-write ocsf-java-tools.

I suggest that OCSF includes in their standards a YAML-based mapping format, which could be used by the community to create and maintain mapping rules from tool X to OCSF in a human-readable, machine-parsable format.

Right now, I don't feel the community will get on trying to create mappings for OCSF because writing JSON by hand is very painful.

Crowdstrike has already created something YAML-based, which is used in their FDR repo. The YAML format to translate events to OCSF looks like this:

# Ours = raw format, theirs = ocsf

---
- name: SomeEnumValueType
  type: Enum
  values:
    - ours: 0
      theirs: potato
    - ours: 1
      theirs: patato

---
- name:
    - ProcessActivityEventA
    - ProcessActivityEventB
  type: Telemetry
  format: ocsf
  mappings:
    - ours: LocalPID
      theirs: process.pid
      transform: as_number  # This is a function defined by a user-extendable/editable package; See ocsf/ocsf.py in the FDR repo.

    - ours: UniquePID
      theirs: process.uid

    - ours: InputField3
      theirs:
        - output_field_4
        - output_field_5
      transform: as_number

    - ours: Pronounciation
      theirs: potato.pronounciation
      using: SomeEnumValueType # resolve using enum above

  # static fields
  fields:
    - name: i_like
      value: coffee

We feel this is a great starting point.

We're very excited about OCSF, but without giving mappers proper standards and tooling, we fear adoption will be slow. If proper standards and basic tooling is given, the community will naturally adopt and create mapping rules for a number of tools that don't natively support OCSF.

[Prenux]

That would be a major enabler since mappers are needed to translate consistently and make OCSF a standard and common format instead of simply yet another schema among the other tool-specific schemas.

Since developping mappings is what is the most time consuming for adopters, it would be nice to be able to share mappings for popular and known data sources using a standard and readable way!