This page is not yet available in Spanish. We are working on its translation.
If you have any questions or feedback about our current translation project, feel free to reach out to us!
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 CategorySupported OCSF versions
AWS CloudTrailType: Management
EventName: ChangePassword
Account Change (3001)1.3.0
1.1.0
Google Cloud AuditSetIamPolicyAccount Change (3001)1.3.0
1.1.0
Google Cloud AuditCreateSinkAccount Change (3001)1.3.0
1.1.0
Google Cloud AuditUpdateSyncAccount Change (3001)1.3.0
1.1.0
Google Cloud AuditCreateBucketAccount Change (3001)1.3.0
1.1.0
GitHubCreate UserAccount Change (3001)1.1.0
Google Workspace AdminaddPrivilegeUser Account Management (3005)1.1.0
OktaUser session startAuthentication (3002)1.1.0
Palo Alto NetworksTrafficNetwork Activity (4001)1.1.0

Sintaxis de las consultas de filtro

Cada procesador tiene una consulta de filtro correspondiente en sus campos. Los procesadores sólo procesan los logs que coinciden con su consulta de filtro. Y en todos los procesadores, excepto el procesador de filtro, los logs que no coinciden con la consulta se envían al siguiente paso de la cadena. Para el procesador de filtro, los logs que no coinciden con la consulta se descartan.

Para cualquier atributo, etiqueta (tag) o par key:value que no sea un atributo reservado, la consulta debe empezar por @. Por el contrario, para filtrar atributos reservados, no es necesario añadir @ delante de la consulta de filtro.

Por ejemplo, para filtrar y descartar logs status:info, tu filtro puede definirse como NOT (status:info). Para filtrar y descartar system-status:info, el filtro debe ser NOT (@system-status:info).

Ejemplos de consulta de filtro:

  • NOT (status:debug): Esto filtra sólo los logs que no tienen el estado DEBUG.
  • status:ok service:flask-web-app: Esto filtra todos los logs con el estado OK de tu servicioflask-web-app.
    • Esta consulta también se puede escribir como: status:ok AND service:flask-web-app.
  • host:COMP-A9JNGYK OR host:COMP-J58KAS: Esta consulta de filtro sólo coincide con los logs de hosts etiquetados.
  • @user.status:inactive: Esto filtra los logs con el estado inactive anidado bajo el atributo user.

Las consultas ejecutadas en el worker de Observability Pipelines distinguen entre mayúsculas y minúsculas. Obtén más información sobre cómo escribir consultas de filtro con la sintaxis de búsqueda de logs de Datadog.

PREVIEWING: domalessi/docs-10186