Remap to OCSF Processor

The Remap to OCSF processor is in Preview. Complete this form to request access.

Use this processor to remap logs to Open Cybersecurity Schema Framework (OCSF) events. OCSF schema event classes are set for a specific log source and type. You can add multiple mappings to one processor. Note: Datadog recommends that the OCSF processor be the last processor in your pipeline, so that remapping is done after the logs have been processed by all the other processors.

To set up this processor:

Click Manage mappings. This opens a side panel:

  • If you have not added any mappings yet, enter the mapping parameters as described in Add a mapping.
  • If you have already added mappings, click on a mapping in the list to edit or delete it. Use the search bar to find a mapping by its name. Click Add Mapping to add another mapping.

Add a mapping

  1. Select the log type in the dropdown menu.
  2. Define a filter query. Only logs that match the specified filter query are remapped. All logs, regardless of whether they do or do not match the filter query, are sent to the next step in the pipeline.
  3. Click Add Mapping.

Mappings

These are the mappings available:

Log SourceLog TypeOCSF Category
AWS CloudTrailType: Management
EventName: ChangePassword
Account Change (3001)
OktaUser session startAuthentication (3002)
Palo Alto NetworksTrafficNetwork Activity (4001)
Google Workspace AdminaddPrivilegeUser Account Management (3005)

Filter query syntax

Each processor has a corresponding filter query in their fields. Processors only process logs that match their filter query. And for all processors except the filter processor, logs that do not match the query are sent to the next step of the pipeline. For the filter processor, logs that do not match the query are dropped.

For any attribute, tag, or key:value pair that is not a reserved attribute, your query must start with @. Conversely, to filter reserved attributes, you do not need to append @ in front of your filter query.

For example, to filter out and drop status:info logs, your filter can be set as NOT (status:info). To filter out and drop system-status:info, your filter must be set as NOT (@system-status:info).

Filter query examples:

  • NOT (status:debug): This filters for only logs that do not have the status DEBUG.
  • status:ok service:flask-web-app: This filters for all logs with the status OK from your flask-web-app service.
    • This query can also be written as: status:ok AND service:flask-web-app.
  • host:COMP-A9JNGYK OR host:COMP-J58KAS: This filter query only matches logs from the labeled hosts.
  • @user.status:inactive: This filters for logs with the status inactive nested under the user attribute.

Queries run in the Observability Pipelines Worker are case sensitive. Learn more about writing filter queries in Datadog’s Log Search Syntax.