Crear, probar y gestionar Custom Parsers de Sophos SIEM

Un Custom Parser asigna los campos de un mensaje de log a los esquemas de eventos estandarizados de Sophos XDR. Ayuda cuando una fuente integrada no se normaliza correctamente. Se trabaja en Security Operations > Integrations > Custom Parsers: crear el parser, probar distintos mensajes individuales, comprobar la asignación real y solo entonces activarlo. Se necesitan una suscripción Next-Gen SIEM y el rol Admin o Super Admin; otros roles solo pueden consultar la lista de parsers configurados.

El parser no configura el transporte de logs. Primero la fuente debe enviar datos; la explicación de SIEM distingue ingesta, normalización y detección. En una integración ya compatible, establecer primero el formato esperado en vez de sustituir prematuramente la lógica del parser global.

Preparar la fuente, el esquema y la reversión

Antes de empezar, registrar producto fuente, formato, tipos de evento, referencia temporal y análisis deseado. Sophos admite CEF, LEEF, JSON, XML y mensajes no estructurados. Cada variante relevante requiere un ejemplo depurado: inicios de sesión correctos y fallidos, campos opcionales ausentes y diferentes valores de usuario o dirección. Eliminar secretos conservando la estructura necesaria para el parsing.

El esquema de destino describe el tipo de evento. Un inicio de sesión puede corresponder a Auth, una conexión de red a Netflow y una consulta DNS a DNS. Los Custom Parsers solo admiten parte de los esquemas XDR. En Data Lake Search > Schema Library, comprobar esquemas y campos consultables; la referencia de normalización también enumera campos del parser y tipos de datos correspondientes. Un nombre de campo no demuestra que la fuente proporcione ese valor.

Documentar nombre del parser, responsable, formato, campos de destino deseados, mensajes de prueba y tratamiento anterior. Para un parser existente, guardar el script previo con acceso restringido. Preparar una reversión sin eliminación: mantener inicialmente desactivados los parsers nuevos y, si hay problemas, volver a desactivarlos o restaurar de forma controlada el script guardado. Sophos no mantiene ni actualiza los Custom Parsers; la responsabilidad sigue siendo del operador.

Elegir Standalone, Parent o Child

• Standalone corresponde a una fuente con exactamente un tipo de mensaje y un esquema de destino.
• Parent reconoce la fuente y prepara valores comunes. Sophos recomienda scwx.generic como destino. Los Child Parsers asociados normalizan los distintos tipos de evento.
• Child requiere un Parent y el esquema final correcto. Las variables y campos del Parent están disponibles para el Child.

Un firewall puede proporcionar inicios de sesión, conexiones de red y eventos HTTP. Un Parent reconoce el formato común; tres Children procesan los diferentes contenidos. Los Child Parsers personalizados no pueden tener otros Child Parsers. Una única fuente sencilla no necesita automáticamente esta división.

Crear el parser e identificar la fuente sin ambigüedad

1. Abrir Security Operations > Integrations > Custom Parsers y elegir Add Custom Parser.
2. Asignar un nombre descriptivo, como EXAMPLE_APP_JSON_AUTH. Es un ejemplo libre; producto, formato y función deben ser reconocibles.
3. Elegir Parent, Child o Standalone. Para Child, seleccionar el Parent correcto y después formato y esquema de destino.
4. Abrir el editor con Create. El código base generado incluye la función de separación adecuada al formato elegido.

La Confirm String determina si un mensaje corresponde al parser. !CONFIRMWITH=PATTERN selecciona una expresión regular compatible con Go; !CONFIRMWITH=EXPRESSION, una condición que devuelve verdadero o falso. La expresión en sí se define en ambos casos en !CONFIRMSTRING, en el bloque de declaraciones del script. Debe identificar con suficiente precisión la fuente y, cuando proceda, el tipo de evento. Una palabra general como «network» suele ser demasiado amplia. La plantilla completa del ejemplo práctico de HTTP/parser enlazado más abajo muestra juntos el modo y el matcher; su formato de laboratorio limitado no es intercambiable con el siguiente fragmento example-auth.

Incluso un parser sintácticamente válido puede capturar mensajes ajenos. Sophos no garantiza un orden fijo para todas las colisiones posibles. Probar también al menos un mensaje parecido que no deba corresponder. Comprobar después en extractor path qué Parent y Child se utilizaron realmente.

Asignar campos y comprobar marcas de tiempo

El script distingue variables locales de campos del parser terminados en $. Solo se normalizan campos compatibles con el esquema; un nombre arbitrario con $ no crea un campo nuevo. Los campos del esquema suelen usar snake_case y los del parser camelCase. Verificar la escritura exacta en el esquema elegido.

Este JSON ficticio ofrece un pequeño punto de partida para una asignación Auth:

{"product":"example-auth","user":"pilot-user","src_ip":"192.0.2.25","time":"2026-10-27T10:15:00Z","result":"success"}

192.0.2.25 es una dirección de documentación, no un destino de producción. Un fragmento de script JSON puede extraer usuario y dirección fuente así:

json = JSON(originalData$)
sourceUserName$ = json["$.user"]
sourceAddress$ = json["$.src_ip"]

Una plantilla completa para un formato sintético estrictamente definido, con marca temporal, asignación de enums y validación mediante búsquedas, se encuentra en el ejemplo práctico de HTTP y parser.

La definición requiere completar y validar los campos para el esquema del tenant. Faltan deliberadamente Confirm String, esquema, marca temporal, acción de autenticación y resultado; deben ajustarse al formato real. En particular, no copiar sin comprobar el texto success a un campo enum numérico. El esquema Auth define, por ejemplo, SUCCESS y FAILED para action_result; verificar expresamente su asignación en el parser.

Comparar valor original, zona horaria y event_time_usec normalizado. La función DATETIME() usa plantillas temporales de Go. Una zona incorrecta puede generar un análisis técnicamente correcto, pero temporalmente erróneo. Comprobar también los valores comunes extraídos por el Root Parser frente a la fuente.

Los campos repetidos, como varios adjuntos, indicadores o registros de metadatos, requieren listas de objetos adecuadas al esquema. Una cadena separada por comas no sustituye esa estructura. ADDFIELD() puede combinar arrays en objetos repetidos; los arrays JSON deben mantener alineadas las posiciones correspondientes. Un valor ausente no puede, por ejemplo, asociar un hash al tipo de archivo incorrecto.

Probar mensajes individuales y leer resultados

Si la fuente ya envía datos, buscar mensajes originales adecuados en Data Lake Search con FROM generic WHERE sensor_id='[my data source]'. Sustituir el marcador por el identificador verificado en eventos reales. En los detalles, elegir Original Data > Copy Original Data y pegar en Sample Message del editor. Como alternativa usar una sola línea de log depurada, no un archivo completo.

1. Comprobar primero la separación con Parse Message. Parsed Source Message muestra pares clave/valor de formatos estructurados o partes indexadas de mensajes no estructurados.
2. En Source Destination Mapping, comprobar qué valores se asignan a cada campo. Comparar por separado usuario, direcciones fuente/destino, hora, acción y resultado con el mensaje original.
3. Verificar extractor path. Debe mostrar la ruta prevista. Un aviso sobre otro parser no es un detalle cosmético.
4. Añadir más mensajes representativos y otros deliberadamente no coincidentes. En Parent/Child probar tanto reconocimiento común como asignación al Child.
5. Ejecutar Run Test para todos los ejemplos guardados y comparar esquema, valores y ruta. Sophos recomienda pruebas repetidas, unas 12 a 15 ejecuciones, para detectar asignaciones incorrectas variables. Un número concreto no garantiza el tratamiento correcto de todos los futuros mensajes.

Las herramientas analizan el contenido actual del editor, pero no lo guardan. Un parser inválido desactivado puede guardarse; guardar no constituye por sí solo una aceptación funcional. Si faltan campos, comprobar primero contenido fuente, tipo de datos, nombres exactos y separación del mensaje.

Guardar y activar de forma controlada

En un parser nuevo, Save and Continue guarda el borrador. Los nuevos parsers están desactivados por defecto. Tras las pruebas, salir con Exit, elegir el icono Play en Actions de la lista y confirmar con Enable. En Parent/Child, activar primero el Parent y después los Children.

Después de activar, generar un evento fuente inofensivo autorizado o correlacionar inequívocamente uno ya esperado. Buscar resultados normalizados por fuente, hora, esquema y campos requeridos. Sophos cita, por ejemplo, WHERE sensor_type=[your_sensor_type]; el marcador representa el tipo real y no es una consulta completa lista para copiar.

El tratamiento hacia esquemas adicionales ocurre junto con los eventos genéricos. Un resultado demuestra inicialmente solo la normalización verificada. No se garantizan detectores automáticos para cada fuente personalizada. Las rutas documentadas incluyen DGA y Domain Watchlist mediante DNS query_name, e IP Watchlist mediante direcciones fuente/destino en NIDS o Netflow. Aceptar por separado la detección deseada; un evento de prueba normal no tiene por qué producir una alerta.

Reglas del cliente y responsabilidad MDR

is_custom_alert, o vendor_alert_details.is_custom_alert para Email, identifica el origen de una regla de alerta. Según la ayuda de los esquemas, las detecciones así marcadas como Custom Alert con true se envían directamente al tenant para gestión propia y no entran en la cola del servicio MDR; su gravedad no cambia. No establecer la marca de forma que una alerta del cliente parezca una detección inalterada del proveedor.

Esto no significa que todo mensaje normalizado por un Custom Parser esté automáticamente sujeto a esa exclusión. Evento fuente, detección resultante y responsabilidad del caso siguen siendo cuestiones distintas. El artículo sobre Cases y Rules explica el límite existente de los Self-managed Cases generados por reglas del cliente.

Resolver errores y revertir con seguridad

Parser incorrecto en extractor path: Comparar las Confirm Strings implicadas. Si hay colisión con un parser global, pedir a Sophos Support que revise la especificidad, en lugar de superponer más overrides amplios.

Mensaje solo en generic: Verificar transporte y mensaje original, después Confirm String, parser activo y esquema. La ausencia aislada de un resultado normalizado no demuestra un fallo de transporte.

Script válido, valores incorrectos: Comparar mensaje y asignación campo por campo, especialmente hora y enums. En parsers activos restaurar controladamente la versión guardada tras un cambio erróneo y volver a verificar.

Desactivar un parser nuevo defectuoso con el icono Pause y Disable. En una jerarquía todos los Children deben estar desactivados o eliminados antes de desactivar el Parent. La normalización adicional termina de inmediato; los eventos genéricos continúan creándose. La reversión no corrige automáticamente datos históricos mal normalizados ni detecciones derivadas.

Eliminar mediante la papelera y Delete es irreversible. Para una primera reversión suele bastar con desactivar. Decidir la eliminación definitiva tras preservar configuración, aclarar dependencias y completar la aceptación.

Los parsers globales no se pueden editar directamente. Un Override sustituye su procesamiento para el caso concreto y una Extension añade tipos aún no normalizados. Ambos requieren asociación correcta al Parent global y mantenimiento propio. Sin nombre inequívoco y asignación verificada, conservar la ruta global; no corregir en producción una zona horaria o formato nuevo con un Override sin probar.