> For the complete documentation index, see [llms.txt](https://docs.bindplane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bindplane.com/integrations/processors/ocsf-standardization.md).

# OCSF Standardization

### Description

The OCSF Standardization processor transforms log data into [Open Cybersecurity Schema Framework (OCSF)](https://schema.ocsf.io/) compliant events. It maps fields from incoming logs to the appropriate OCSF class structure using

### Use

Use the OCSF Standardization processor to normalize security logs from diverse sources into a common OCSF schema before routing them to a security destination. The processor replaces the **log body** with an OCSF-compliant JSON structure. The original log attributes and resource fields are preserved. Destinations such as AWS Security Lake and [Google SecOps](/integrations/destinations/google-secops-chronicle.md) both support forwarding just the log body, making them well-suited for use downstream of this processor.

### Supported Types

| Metrics | Logs | Traces |
| ------- | ---- | ------ |
|         | ✓    |        |

### Configuration

| Field              | Required | Type                | Description                                                                                                    |
| ------------------ | -------- | ------------------- | -------------------------------------------------------------------------------------------------------------- |
| Telemetry Types    | Yes      | `telemetrySelector` | The types of telemetry to apply the processor to. Only Logs are supported.                                     |
| OCSF Version       | Yes      | `enum`              | The version of the OCSF specification to use for standardization. Supported versions: `1.0.0` through `1.7.0`. |
| Runtime Validation | Yes      | `bool`              | Enable runtime validation of OCSF events against the schema. Logs that fail validation will be dropped.        |
| Event Mappings     | Yes      | `ocsfEventMappings` | One or more mappings that define how incoming logs are transformed into OCSF events. See Event Mappings below. |

#### Event Mappings

Each event mapping defines the rules for transforming a matched log into a specific OCSF event class. Multiple mappings can be configured to handle different log types within the same processor. The first mapping whose filter condition matches a given log record is applied.

| Field          | Required | Type                 | Description                                                                                                                                            |
| -------------- | -------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Class ID       | Yes      | `int`                | The OCSF class ID for the target event type (e.g., `3002` for Authentication Activity).                                                                |
| Filter         | No       | `string`             | A condition expression that determines which logs this mapping applies to. If omitted, the mapping applies to all logs.                                |
| Profiles       | No       | `string[]`           | One or more OCSF profiles to apply to this event mapping. Each profile adds additional required and optional fields to the output. See Profiles below. |
| Field Mappings | Yes      | `ocsfFieldMapping[]` | A list of individual field mappings that copy or set values in the OCSF output body.                                                                   |

#### **Event Mapping Fields**

Each entry in the field mappings list defines how a single OCSF field is populated.

| Field   | Required | Type     | Description                                                                                         |
| ------- | -------- | -------- | --------------------------------------------------------------------------------------------------- |
| To      | Yes      | `string` | The target OCSF field path. Dot notation is used for nested fields (e.g., `actor.user.name`).       |
| From    | No\*     | `string` | An expression that extracts a value from the source log (e.g., `body["EventData"]["IpAddress"]`).   |
| Default | No\*     | `any`    | A static default value to use when the source field is absent or the `From` expression returns nil. |

\*At least one of `From` or `Default` must be provided for each field mapping.

### Automatically Populated Fields

In addition to fields defined in your event mappings, the processor automatically populates the following fields in the log body for every processed record:

| Field              | Description                                           |
| ------------------ | ----------------------------------------------------- |
| `class_uid`        | Set to the Class ID of the matched event mapping.     |
| `category_uid`     | Derived from the Class ID as `class_id / 1000`.       |
| `metadata.version` | Set to the configured OCSF version (e.g., `"1.7.0"`). |
| `type_uid`         | Calculated as `class_uid * 100 + activity_id`.        |

The processor also adds an `ocsf.class_uid` attribute to the log record (outside the body) for use in downstream routing and filtering.

### Type Coercion

The processor automatically coerces mapped values to match the target OCSF field's schema type. If a value cannot be coerced, it is passed through unchanged.

| OCSF Type   | Accepted Input Types                                                 | Output                     |
| ----------- | -------------------------------------------------------------------- | -------------------------- |
| `integer`   | `int`, `int64`, `float64`, `string` (numeric), `bool`                | `int`                      |
| `long`      | `int`, `int64`, `float64`, `string` (numeric), `bool`                | `int64`                    |
| `float`     | `int`, `int64`, `float64`, `string` (numeric)                        | `float64`                  |
| `boolean`   | `bool`, `string` (`"true"`/`"false"`), `int`, `int64`, `float64`     | `bool`                     |
| `timestamp` | `int`, `int64`, `float64`, `string` (numeric or RFC3339/RFC3339Nano) | `int64` epoch milliseconds |
| `datetime`  | `int`, `int64`, `float64` (epoch ms), `string`                       | `string` RFC3339           |
| `string`    | Any                                                                  | Unchanged                  |

### OCSF Profiles

Profiles are standardized field groups that can be applied to an event to extend it with a predefined set of related attributes. When a profile is selected, its required fields must be mapped. Profiles are selected per event mapping using a multi-select dropdown.

Not all profiles are available for every class. The profile dropdown automatically filters to show only profiles that are valid for the selected class and OCSF version.

### Generate Event Mappings with AI

Instead of authoring event mappings by hand, you can use [Pipeline Intelligence](/feature-guides/pipeline-intelligence/pipeline-intelligence.md) to generate one from a real log in your pipeline. Bindplane analyzes a sample log, detects the appropriate OCSF class, and generates a filter condition and field mappings for you to review before adding them to the processor.

{% hint style="info" %}
Generating event mappings requires Pipeline Intelligence AI features, which are available for Enterprise, Bindplane Enterprise (Google Edition), and Honeycomb licenses and must be enabled by an organization admin. See the [Pipeline Intelligence overview](/feature-guides/pipeline-intelligence/pipeline-intelligence.md) for details on enabling AI features and how your data is used.
{% endhint %}

**Generating a Mapping**

1. Open the OCSF Standardization processor in a configuration that has recent telemetry available in the snapshot preview. At the bottom of the Event Mappings list, click **Generate Event Mapping**.

   <figure><img src="/files/lhZDezHhWKTWiouNrMWK" alt=""><figcaption></figcaption></figure>
2. **Select log** - Expand a log row in the snapshot preview and click **Generate OCSF Mapping**.

   <figure><img src="/files/CgGHR364cbc4VmdiYllC" alt=""><figcaption></figcaption></figure>
3. **Detect class** - Bindplane analyzes the log and presents one or more suggested OCSF classes, each with a short explanation of why it matches. Click a suggestion to use it, or pick a different class manually from the **Event Class** dropdown and click **Continue**.

   <figure><img src="/files/jwzd8vEtKBxo2LtPnv4x" alt=""><figcaption></figcaption></figure>
4. **Generate mapping** - Bindplane generates a filter condition that scopes the mapping to logs from the same source, and field mappings that populate the required fields of the selected class. Progress streams in real time. The generated mapping is automatically validated against the OCSF schema; if required fields are missing, Bindplane retries with the validation feedback (up to four attempts).
5. **Review & accept** - Review the generated filter condition (with a plain-language explanation), the field mapping table, and any remaining validation issues. Click **Accept Mapping** to add it to the processor's Event Mappings list.

   <figure><img src="/files/tjQvroTlTpV5nZ8aPEis" alt=""><figcaption></figcaption></figure>

The accepted mapping is added as a regular event mapping. You can edit the filter, class, and field mappings just like a manually created mapping before saving the processor.

{% hint style="success" %}
Always review generated field mappings against your actual data before deploying. If validation issues remain after generation, resolve them by editing the mapping, or temporarily disable Runtime Validation while you iterate.
{% endhint %}

### Example Configuration

#### **Map Windows Logon Events to OCSF Authentication Activity**

In this example, Windows Security Event ID `4624` (Successful Logon) is mapped to the OCSF class `3002` (Authentication). The filter ensures this mapping applies only to matching log records. Field mappings populate all required fields for the Authentication class, including the target user, event time, severity, and source network details.

<figure><img src="/files/FGFg725zhAwbEdsf1Pky" alt=""><figcaption></figcaption></figure>

#### **Standalone Processor**

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
  id: ocsf_standardization
  name: ocsf_standardization
spec:
  type: ocsf_standardization
  parameters:
    - name: telemetry_types
      value:
        - Logs
    - name: ocsf_version
      value: '1.3.0'
    - name: runtime_validation
      value: true
    - name: event_mappings
      value:
        - classId: 3002
          filter: 'body["System"]["EventID"] == 4624'
          fieldMappings:
            - to: 'user.name'
              from: 'body["EventData"]["TargetUserName"]'
            - to: 'user.domain'
              from: 'body["EventData"]["TargetDomainName"]'
            - to: 'time'
              from: 'body["System"]["TimeCreated"]["SystemTime"]'
            - to: 'severity_id'
              default: 1
            - to: 'activity_id'
              default: 1
            - to: 'status_id'
              default: 1
            - to: 'src_endpoint.ip'
              from: 'body["EventData"]["IpAddress"]'
            - to: 'src_endpoint.hostname'
              from: 'body["EventData"]["WorkstationName"]'
            - to: 'actor.user.name'
              from: 'body["EventData"]["SubjectUserName"]'
            - to: 'actor.user.domain'
              from: 'body["EventData"]["SubjectDomainName"]'
```

The resulting log body will conform to the OCSF Authentication schema (class `3002`). The table below shows all populated fields, including those automatically added by the processor:

| OCSF Field              | Source        | Value                                                                         |
| ----------------------- | ------------- | ----------------------------------------------------------------------------- |
| `class_uid`             | Auto          | `3002`                                                                        |
| `category_uid`          | Auto          | `3`                                                                           |
| `metadata.version`      | Auto          | `"1.3.0"`                                                                     |
| `type_uid`              | Auto          | `300201`                                                                      |
| `user.name`             | Field mapping | Value from `body["EventData"]["TargetUserName"]`                              |
| `user.domain`           | Field mapping | Value from `body["EventData"]["TargetDomainName"]`                            |
| `time`                  | Field mapping | Value from `body["System"]["TimeCreated"]["SystemTime"]`, coerced to epoch ms |
| `severity_id`           | Field mapping | `1` (Informational)                                                           |
| `activity_id`           | Field mapping | `1` (Logon)                                                                   |
| `status_id`             | Field mapping | `1` (Success)                                                                 |
| `src_endpoint.ip`       | Field mapping | Value from `body["EventData"]["IpAddress"]`                                   |
| `src_endpoint.hostname` | Field mapping | Value from `body["EventData"]["WorkstationName"]`                             |
| `actor.user.name`       | Field mapping | Value from `body["EventData"]["SubjectUserName"]`                             |
| `actor.user.domain`     | Field mapping | Value from `body["EventData"]["SubjectDomainName"]`                           |

The log record attribute `ocsf.class_uid` will also be set to `3002`.

### Schema Validation

#### Configuration-time Validation

When the processor is saved, Bindplane validates it against the OCSF schema. Configuration-time validation checks:

* The selected OCSF version is supported.
* Each event mapping has a valid Class ID.
* All filter and from expressions are syntactically valid.
* Any selected profiles are valid for the chosen class and version.
* Field coverage - all required fields for the class (and any selected profiles) have a corresponding field mapping. The auto-populated fields (`class_uid`, `category_uid`, `metadata.version`, `type_uid`) are counted toward coverage automatically.

Configuration validation does not verify that mapped values will be the correct type at runtime. A field mapping that references the wrong source field or provides a default of the wrong type will pass configuration validation but may fail at runtime if Runtime Validation is enabled.

#### Runtime Validation

When Runtime Validation is enabled (the default), each processed log record is validated against the full OCSF schema after all field mappings are applied. Log records that fail validation are dropped and logged as errors. Validation checks include:

* Required fields - all required fields for the class and selected profiles are present.
* Enum values - integer and string enum fields contain a valid value from the allowed set.
* String length - string fields do not exceed their maximum allowed length.
* Pattern constraints - fields with format requirements (such as IP addresses, email addresses, hostnames, UUIDs, and datetime strings) match the expected pattern.

Disable runtime validation during initial configuration to allow logs through while you iterate on your field mappings. Re-enable it once the output is confirmed correct to ensure that all log bodies sent to your destination are OCSF-compliant.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.bindplane.com/integrations/processors/ocsf-standardization.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.