Envío de Datos con la Integración Personalizada de HTTP Push

Visión general

Para organizaciones que envían datos a sistemas para los cuales no existe una integración dedicada de Cato, proporcionamos la Integración Personalizada de HTTP Push.

Utilice la integración Personalizada de HTTP Push para transmitir eventos, y opcionalmente flujos, directamente a cualquier plataforma externa que acepte JSON o JSON delimitado por saltos de línea (NDJSON) a través de HTTP. Los datos se envían continuamente a medida que se generan, en lugar de ser recuperados en base a un calendario programado. Esto permite que los sistemas en bajada reciban actualizaciones casi en tiempo real sin necesidad de sondeos.

Casos de Uso Comunes

• SIEM y plataformas SOC - Sample Company utiliza la función de Monitorización de Actividad Sospechosa del IPS, que genera un alto volumen de eventos de seguridad. Deciden centralizar estos datos con su plataforma SIEM existente, para la cual no existe una integración dedicada de Cato. La empresa de ejemplo habilita la Integración de Eventos y configura una Integración HTTP Push Personalizada apuntando al punto de ingestión HTTP de su SIEM, para que todos los eventos de IPS se transmitan automáticamente al SIEM para correlación, alertas y retención a largo plazo junto con otros datos de seguridad.

• Recolección y análisis de registros personalizados - Sample Company quiere alimentar los datos de eventos de Cato en su canal de análisis interno para informes operativos. Levantaron un colector de registros basado en HTTP para recibir los datos y configuraron una Integración HTTP Push Personalizada en su cuenta de Cato, para que los eventos se envíen continuamente al colector a medida que se generen, sin necesidad de sondear a Cato para actualizaciones.

Confiabilidad de Entrega

Datos son enviados usando entrega con el mejor esfuerzo. Si un endpoint de destino se vuelve no disponible o devuelve un error de autenticación, Cato intenta automáticamente reconectar usando el siguiente horario:

• Reintentos a corto plazo: 1 mín, 5 mín, 10 mín, 15 mín, 1 hr, 6 hr, y 24 hr

• Reintentos extendidos: Reintentos diarios después de las primeras 24 horas, continuando por hasta 7 días

Si la integración permanece incapaz de conectarse durante 7 Días, los intentos de reintento continuos se detienen para toda la integración hasta que se resuelva el problema de Configuración del Endpoint.

Integraciones Nativas vs. Push HTTP Personalizado

Cato proporciona integraciones diseñadas específicamente para exportar eventos a plataformas de uso común, incluidas Splunk, Microsoft Sentinel, CrowdStrike y Azure Storage. Cuando hay una integración nativa disponible para su destino, recomendamos usarla. La ventaja es que está optimizado para esa plataforma y puede ofrecer capacidades específicas de la plataforma.

Use la integración HTTP Push Personalizada cuando su destino no tenga una integración dedicada o cuando necesite entregar eventos a una aplicación o servicio personalizado.

Filtros

Use filtros para controlar qué eventos se exportan. Esto ayuda a reducir costos de ingesta, minimizar ruido y enfocar investigaciones en los eventos más relevantes para sitios, usuarios o regiones específicos. También puede usar filtros para enrutar diferentes subconjuntos de eventos a diferentes entornos SIEM.

Usa grupos de filtros para definir filtros basados en cualquier Campo de Evento o combinación de campos. Las condiciones dentro de cada grupo usan lógica AND. Se aplica lógica OR entre grupos. Los filtros en la captura de pantalla configuran la integración para exportar:

• Eventos que se originan en París o Madrid, son de subtipo Cortafuegos de Internet, y resultan en acciones distintas a Monitorear o Solicitar.

• Nombre de usuario contiene Prueba

Requisitos Previos

Antes de configurar una integración HTTP Push Personalizada, verifique que la plataforma de destino admita todo lo siguiente:

• Solicitudes HTTP POST o PUT

• JSON o JSON delimitado por líneas (NDJSON)

• La carga estándar de Cato sin necesidad de un cuerpo de solicitud personalizado, envoltura específica del proveedor ni directiva adicional

La estructura de la carga es fija. No se pueden agregar, eliminar o reorganizar campos.

En resumen:

• Una plataforma de destino es generalmente compatible si puede ingerir objetos JSON simples o una transmisión de eventos NDJSON exactamente como Cato los envía. Ejemplos incluyen SentinelOne, Securonix y Trend AI.

• Una plataforma no es compatible si su API de ingesta requiere una estructura de carga patentada, como un sobre, envoltura o línea de control que se deba agregar al cuerpo de la solicitud. Ejemplos incluyen Elastic y Datadog.

Configurar un Push HTTP Personalizado

Paso 1: Reunir Parámetros

Desde tu plataforma objetivo, obtén:

• URL de ingestión: el punto final HTTP(S) que acepta eventos

• Detalles de autenticación: la integración soporta Encabezado(s) Personalizado(s), Clave de API, Token de Portador o Autenticación Básica. Si tu proveedor espera un valor con prefijo (por ejemplo, Portador <token>), debes ingresar toda la cadena, incluido el prefijo, como un valor único. Se almacena cifrado en el lado de Cato.

Paso 2: Prueba Con curl

Valida el destino de forma independiente usando una solicitud de curl desde la línea de comandos. Esto aísla problemas del lado del proveedor (autenticación, punto final, aceptación de carga) y te proporciona una solicitud funcional que puedes reutilizar directamente en la configuración del conector.

El siguiente ejemplo muestra una solicitud curl para Elastic que no tiene éxito:

curl -X POST "https://<your-elastic-endpoint>/_bulk" \
 -H "Authorization: ApiKey <KEY>" \
 -H "Content-Type: application/x-ndjson" \
 --data-binary $'{"create":{"_index":"logs-cato.events-default"}}\n{"message":"test event from curl","event_type":"test","timestamp":"2026-07-05T12:00:00Z"}\n'

Esto no cumple con los requisitos del conector, aunque la llamada curl en sí misma pueda tener éxito contra Elastic. La carga requiere una línea de directiva de crear antes de cada línea de evento; la integración no tiene forma de inyectar esa línea adicional ya que el formato del cuerpo es fijo.

El siguiente ejemplo muestra una solicitud curl para SentinelOne que tiene éxito:

curl -i "https://ingest.us1.sentinelone.net/services/collector/raw?sourcetype=cato_events" \
 -H "Authorization: <token>" \
 -H "Content-Type: application/x-ndjson" \
 --data-binary $'{"event_type":"test"}\n'

Esto funciona porque el endpoint HEC de SentinelOne acepta un objeto de evento simple por línea — sin envoltorio, sin directiva extra — que es exactamente lo que el conector envía. Cuando una prueba curl como esta tiene éxito, puedes usarla literalmente en la configuración del conector:

• URL: pega el punto final completo incluyendo parámetros de consulta (por ejemplo, ?sourcetype=cato_events)

• Auth: Encabezados Personalizados → nombre del encabezado Authorization, valor ajustado a tu token real (almacenado como Secreto)

• Cuerpo: ajusta el tipo de contenido para que coincida con lo que probaste (application/x-ndjson aquí)

Si tu prueba curl tiene éxito, continúa al paso 3.

Paso 3: Configura el Conector

1. En el CMA, ve a Recursos > Integraciones > Integraciones Configuradas, y haz clic en Nuevo.

2. En Integración, selecciona Integración HTTP Personalizada.

3. En Capacidad, elija Exportación de Datos.

4. En Auth, selecciona el método que coincida con lo que validaste con curl (Encabezados personalizados, Clave de API, Token de Portador, o Autenticación Básica).

5. Introduce un Nombre y una Descripción opcional.

6. Introduce la URL: el mismo punto final que probaste con curl.

7. Agrega tus Encabezados Personalizados (o campos de autenticación equivalentes): lleva los nombres y valores de encabezado exactos de tu comando curl exitoso. Cada valor puede almacenarse como Secreto o Plano.

8. En Cuerpo, confirma el tipo de contenido (el predeterminado es application/json; NDJSON también es compatible).

El cuerpo de la solicitud enviado por el conector no es configurable: no puedes agregar campos personalizados ni reestructurar la carga.

9. En Fuentes de Datos, selecciona Eventos, Flujos, o ambos.

10. Opcionalmente, delimite lo que se envía usando el Filtro de Eventos y el Filtro de Flujos (coincidan CUALQUIERA de los grupos de filtros configurados). Para más información, consulte Filtros anteriores.

11. Elige si deseas seguir errores con eventos del conector. Esto se recomienda para que las fallas de entrega surjan como eventos en los que pueda alertar.

12. Guarda la configuración y confirma que el estado muestre Conectado.

Resolución de problemas

• Curl tiene éxito, pero Cato muestra Error de Conectividad: verifica que los encabezados/autenticación ingresados en Cato coinciden exactamente con lo que usaste en curl, incluido cualquier prefijo requerido (por ejemplo, Portador) como parte del valor cifrado.

• No llegan eventos a mi plataforma externa: Verifica tu Filtro de Eventos/Filtro de Flujos. Un filtro demasiado estrecho puede excluir todo silenciosamente.

• El proveedor rechaza la carga útil: Revisa los requisitos previos. Es probable que el proveedor requiera una estructura de cuerpo personalizada que este conector no puede producir.

Registro de Cambios de Artículo

Preguntas Frecuentes