OCSF Standardization
The OCSF Standardization processor transforms log records into Open Cybersecurity Schema Framework (OCSF) compliant events. It replaces the log body with an OCSF JSON structure built from your event mappings, while preserving the original log attributes and resource fields. It operates on logs only. Use it to normalize security logs from diverse sources into a common schema before routing them to a security destination such as AWS Security Lake or Google SecOps, both of which can forward just the log body.
Supported Telemetry
✓
Configuration

Processor settings
Choose Telemetry Type
Telemetry Selector
Yes
Logs
The signal this instance runs on. Only Logs are supported.
OCSF Version
Enum: 1.0.0–1.7.0
Yes
1.3.0
The version of the OCSF specification to standardize against.
Runtime Validation
Boolean
No
true
Validate each OCSF event against the schema after mapping. Records that fail validation are dropped and logged as errors.
Event Mappings
OCSF Event Mappings
Yes
—
One or more mappings that transform matched logs into OCSF events. See below.
The Prebuilt Mappings option lets you load Bindplane-provided event mappings for common log sources as a starting point. The loaded mappings populate the Event Mappings list, where you can review and edit them before saving.
Event Mappings
Each event mapping defines how a matched log is transformed into a specific OCSF event class. Configure multiple mappings to handle different log types in one processor. The first mapping whose filter matches a record is applied.
Class ID
Integer
Yes
—
The OCSF class ID for the target event type, for example 3002 for Authentication.
Filter
OTTL Condition
No
(empty)
A condition that selects which logs this mapping applies to. When empty, the mapping applies to all logs.
Profiles
String list
No
(empty)
One or more OCSF profiles to apply. Each profile adds required and optional fields to the output. Requires collector v1.0.2 or later.
Field Mappings
OCSF Field Mappings
Yes
—
A list of field mappings that copy or set values in the OCSF output body. See below.
Field Mappings
Each row in a mapping's field mappings list populates one OCSF field.
To
String
Yes
—
The target OCSF field path. Use dot notation for nested fields, for example actor.user.name.
From
OTTL Expression
No *
—
An expression that extracts a value from the source log, for example body["EventData"]["IpAddress"].
Default
Any
No *
—
A static value used when the source field is absent or the From expression returns nil.
* Each field mapping must provide at least one of From or Default.
Automatically populated fields
For every processed record, the processor sets these OCSF body fields in addition to your mappings:
class_uid
The Class ID of the matched event mapping.
category_uid
Derived from the Class ID as class_id / 1000.
metadata.version
The configured OCSF version, for example "1.3.0".
type_uid
Calculated as class_uid * 100 + activity_id.
The processor also sets an ocsf.class_uid attribute on the log record (outside the body) for downstream routing and filtering.
Type coercion
The processor coerces each mapped value to the target OCSF field's schema type. If a value cannot be coerced, it passes through unchanged.
integer
int
long
int64
float
float64
boolean
bool
timestamp
int64 epoch milliseconds
datetime
string RFC3339
string
Unchanged
Examples
Map Windows logon events to OCSF Authentication Activity
Windows Security Event ID 4624 (successful logon) is mapped to OCSF class 3002 (Authentication). The filter scopes the mapping to matching records. The field mappings populate the required fields for the Authentication class, including the target user, event time, severity, and source network details.
The resulting log body conforms to the OCSF Authentication schema (class 3002). Along with the mapped fields, the processor sets class_uid to 3002, category_uid to 3, metadata.version to "1.3.0", and type_uid to 300201 (3002 * 100 + 1). The time value is coerced to epoch milliseconds, and the ocsf.class_uid log record attribute is set to 3002.
Generate event mappings with AI
Instead of authoring event mappings by hand, you can use Pipeline Intelligence 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. Generated mappings are validated against the OCSF schema during generation, and Bindplane retries with validation feedback when required fields are missing. Generating event mappings requires Pipeline Intelligence AI features, which must be enabled by an organization admin. Always review generated field mappings against your actual data before deploying.
Configuration Tips
The processor validates against the OCSF schema at configuration time (supported version, valid Class IDs, syntactically valid filter and
Fromexpressions, valid profiles for the class and version, and coverage of all required fields). Configuration validation does not verify runtime value types, so a mapping that references the wrong source field passes configuration but may fail runtime validation.During initial setup, set Runtime Validation to
falseso records flow through while you iterate on field mappings. Re-enable it once the output is correct to guarantee every log body sent downstream is OCSF-compliant.Selected profiles add their own required fields. When a profile is applied, map all of its required fields or configuration validation fails.
Profiles require a collector running the contrib processor v1.0.2 or later. Earlier collector builds support event mappings without profiles.
Order event mappings from most specific to least specific. Only the first matching mapping is applied, so a broad filter placed first will shadow narrower mappings below it.
Performance and Scaling
With Runtime Validation enabled (the default), every record is validated against the full OCSF schema after mapping. This is the dominant cost of the processor on high-volume log pipelines. If validation CPU becomes a bottleneck, validate during rollout, then disable Runtime Validation once mappings are confirmed stable.
Each record is evaluated against event-mapping filters in order until one matches. A large number of mappings, or expensive OTTL filter expressions, increases per-record cost. Keep filters cheap (favor simple field comparisons) and place high-volume mappings first.
Type coercion and schema validation walk the mapped fields per record, so very wide field-mapping lists add proportional overhead.
Troubleshooting
Records are being dropped
Symptoms: log count falls after the processor, and the collector logs OCSF validation errors.
Solutions:
Runtime Validation drops records that fail schema validation. Check the collector logs for the specific field or constraint that failed (missing required field, invalid enum value, string length, or pattern such as IP or datetime).
Map every required field for the class and any selected profiles. The auto-populated fields (
class_uid,category_uid,metadata.version,type_uid) count toward coverage automatically.To confirm whether validation is the cause, temporarily set Runtime Validation to
false. If records flow through, fix the failing mappings, then re-enable it.
A mapping does not apply to the expected logs
Symptoms: logs that should be transformed pass through unmodified, or the wrong mapping is applied.
Solutions:
Verify the Filter condition. An over-specific or mis-quoted condition (for example
== 4624against a string field) matches nothing.Only the first matching mapping is applied. A broad mapping listed before a narrower one shadows it. Reorder mappings most-specific-first.
A field has the wrong type or is missing in the output
Symptoms: a mapped value is absent or appears as an unexpected type in the OCSF body.
Solutions:
Check the
Fromexpression resolves on the source log. When it returns nil and noDefaultis set, the field is omitted.The processor coerces values to the OCSF field's schema type; a value that cannot be coerced passes through unchanged and may then fail runtime validation. Provide a
Defaultof the correct type, or correct theFromexpression.
Known Limitations
Logs only. Metrics and traces are not supported.
The processor replaces the log body with the OCSF structure. Original log attributes and resource fields are preserved, but the original body content is not retained unless you map it into an OCSF field.
Configuration-time validation does not check runtime value types. A mapping can pass configuration validation and still fail runtime validation.
Profiles are only available with the contrib processor v1.0.2 or later.
Standalone Processor
Related Resources
Last updated
Was this helpful?