Search OCSF data as Splunk CIM

Security teams in Splunk build on the Common Information Model (CIM): data models such as Authentication and Network_Traffic, tstats searches over them, and the Enterprise Security (ES) detections built on both. OCSF data uses different field names for the same ideas. For example, CIM’s user is OCSF’s user.name in a logon, and CIM’s action comes from status_id in a logon or from action_id in network traffic.

The Axiom Portal for Splunk bridges the two at read time. It presents an OCSF dataset in Axiom as a second Splunk index whose events carry CIM field names and values. Nothing is copied or rewritten in Axiom. This page covers the last step of the OCSF flow: searching OCSF data from Splunk.

Searching OCSF data as CIM requires transparent mode and the Axiom for Splunk app 1.4.0 or later on the search head. It maps the OCSF classes and CIM data models listed on this page.

How it works

Three pieces work together:

• Two indexes for one dataset. For every Axiom dataset that looks like OCSF, the Portal advertises two indexes. index=ocsf shows the native OCSF fields. index=cim_ocsf points at the same dataset and adds CIM fields to every event. A dataset looks like OCSF when its class_uid field is an integer and it has at least one of metadata.version, category_uid, type_uid, activity_id, or severity_id.
• CIM fields computed in Axiom. When you search a cim_ index, the Portal computes the CIM fields inside the Axiom query, before filtering and aggregation. Filters such as action=failure and aggregations such as stats count by user therefore run in Axiom, like any other pushed-down search.
• Eventtypes and tags on the search head. CIM data models find events by tag, for example tag=authentication. A set of eventtypes selects OCSF events by class_uid and attaches the CIM tags. In transparent mode, the search head expands tags into class_uid constraints before it sends the search to the Portal.

Class-aware mapping

The same CIM field comes from different OCSF fields depending on the event class. The Portal reads the *_id enumerations first and falls back to their string siblings. For example:

For example, here is a failed logon from the OCSF for Axiom sample data in the two indexes:

Events in index=cim_ocsf keep their OCSF fields as well, so you can mix both vocabularies in one search. Where OCSF and CIM share a field name, such as action, status, and severity, the cim_ index shows the CIM value for the classes the mapping covers and the native OCSF value for the others.

The mapping reads only the typed columns of the dataset. Attributes stored under the unmapped map field don’t become CIM fields. Arrays of objects become multivalue CIM fields: cve from vulnerabilities, file_hash from file.hashes, process_hash from process.file.hashes, answer from answers, and mitre_technique_id from attacks. cvss is the first CVSS base score of the first vulnerability only.

Supported data models

Data models without an OCSF source, such as Risk, Certificates, Updates, and the inventory data models, return no OCSF events. OCSF classes not listed in the table keep their native fields in the cim_ index and match no CIM data model.

Requirements

• A Splunk Enterprise 9.2 or later search head.
• The Portal registered as a transparent mode provider, with the search head’s knowledge objects turned on. Standard mode doesn’t expand tags or send data model definitions, so the CIM mapping doesn’t work with it.
• The Axiom for Splunk app 1.4.0 or later on the search head. It provides the eventtypes and tags that connect OCSF classes to CIM data models.
• The Splunk Common Information Model add-on (Splunk_SA_CIM) on the search head. Enterprise Security includes it.
• An OCSF dataset in Axiom that follows the Axiom OCSF schema. For more information, see Send OCSF data to Axiom.
• A dataset name that Splunk accepts as an index name: lowercase letters, digits, underscores, and hyphens, starting with a letter or digit. The cim_ prefix is reserved, so the Portal can’t search a dataset whose own name starts with cim_ as a native index.

Set up OCSF as CIM

These steps use a dataset named ocsf. Replace it with the name of your dataset.

index=cim_ocsf tag=authentication | stats count by action, user

| tstats count from datamodel=Authentication by Authentication.action

Example searches

Failed logons by user and source, in the native OCSF vocabulary:

index=ocsf class_uid=3002 activity_id=1 status_id=2
| stats count by "user.name", "src_endpoint.ip"

The same question in CIM vocabulary:

index=cim_ocsf tag=authentication action=failure
| stats count by user, src

As a data model search, the form that ES and ES Content Update (ESCU) detections use:

| tstats count from datamodel=Authentication
    where Authentication.action=failure
    by Authentication.user, Authentication.src

Blocked network traffic and bytes by destination:

| tstats count sum(All_Traffic.bytes) from datamodel=Network_Traffic
    where All_Traffic.action=blocked
    by All_Traffic.dest

Accelerated data model searches with summariesonly=true, the default in ESCU detections, return the same results as unaccelerated ones:

| tstats summariesonly=true count from datamodel=Network_Traffic by All_Traffic.action

An ESCU-style process search with first and last seen times:

| tstats summariesonly=true count min(_time) as firstTime max(_time) as lastTime
    from datamodel=Endpoint.Processes
    where Processes.process_name=powershell.exe
    by Processes.dest Processes.user Processes.process_name

Vulnerabilities with their CVE IDs, a multivalue field from the vulnerabilities array:

index=cim_ocsf tag=report tag=vulnerability cve=*
| table cve, cvss, severity, signature

MITRE ATT&CK techniques in detection findings, from the attacks array:

index=cim_ocsf tag=ids tag=attack mitre_technique_id=*
| stats count by mitre_technique_id, signature, dest

Data model acceleration

ES and ESCU detections run | tstats summariesonly=true … from datamodel=…. Against a cim_ index, summariesonly=true and summariesonly=false return the same complete result, but not because Splunk reads acceleration summaries:

• Splunk builds no tsidx summary for Axiom data. The periodic summary-building searches Splunk sends to the Portal return nothing for cim_ indexes.
• For a summariesonly=true search, the Portal takes the data model definition that Splunk sends with the search and runs the equivalent aggregation live in Axiom.
• Results cover the full time range of the search with no summary lag. Each detection run is a live Axiom query, so its cost and duration follow the time range and data volume rather than a pre-built summary.

You don’t need to change ES data model acceleration settings or use summariesonly=false. You do need to scope the index macros.

Limitations

• Transparent mode only. Standard mode doesn’t expand tags or send data model definitions.
• Not every CIM field is populated. The Portal fills a CIM field only when the dataset has an OCSF source for it. Fields without a source are empty.
• unmapped isn’t mapped. Attributes stored under the unmapped map field don’t become CIM fields.
• Authentication covers logons only. The Authentication eventtype selects activity_id=1. Other Authentication activities, such as logoffs, stay out of the data model.
• Index patterns must match one index. An index pattern such as index=cim_*, for example in a data model macro, must match exactly one index. If it matches several, the search returns an error that names them. Name the concrete cim_ index instead.
• Asset and identity exports aren’t supported. The Axiom for Splunk app includes two scheduled searches that export ES asset and identity lists from OCSF data. They’re turned off by default and aren’t supported in this release. Leave them turned off.
• Enterprise Security. OCSF as CIM has been tested with Splunk Enterprise Security. In addition, the Portal’s translation of data model searches is checked against a large set of ES, ESCU, and community detection search shapes. That check confirms that the searches run against Axiom. It doesn’t confirm that every detection returns the results you expect on your data, so validate the detections you rely on. ES features that depend on other configuration, such as asset and identity lookups, need their usual setup in ES.
• One index per data model search. A data model search that spans more than one cim_ index returns an error.

What’s next

• Query OCSF data with APL
• Set up transparent mode
• SPL command support