Sophos SIEM: elegir transporte y configurar HTTP Ingest

HTTP Ingest recibe mensajes de registro mediante un endpoint HTTPS proporcionado por Sophos. El origen debe poder enviar HTTP POST a un webhook o endpoint HTTP con autenticación mediante token Bearer. Hace falta una suscripción Sophos Next-Gen SIEM; una licencia XDR existente no basta.

Son tres tareas separadas: elegir transporte, conectar el origen y comprobar los eventos reales. Crear correctamente el conector no demuestra normalización ni detección correctas. Revisar antes del piloto los fundamentos SIEM y las licencias.

¿Qué transporte corresponde al origen?

Custom está destinado a orígenes sin una integración optimizada Sophos adecuada. Comprobar primero en Marketplace la integración del producto y sus categorías reales. Un proveedor conocido no implica compatibilidad con todos sus registros.

Hay seis opciones:

• HTTP Ingest: HTTPS POST directo con Bearer, sin infraestructura cloud propia que operar.
• Customer-Managed S3: registros en un bucket de la cuenta AWS propia, reenviados por la configuración Lambda/CloudFormation proporcionada.
• S3 Ingest – Sophos-Managed (with token): destino gestionado por Sophos con prueba de propiedad exigida por el proveedor.
• S3 Ingest – Sophos-Managed (without token): mismo modelo sin dicha comprobación.
• Azure Event Hubs: flujo de eventos hacia un hub accesible.
• Azure Storage Account: archivos en Blob Storage reenviados por una Azure Function.

La guía S3 explica las tres variantes de bucket. La guía Azure distingue Event Hubs de Storage/Function. Un equipo syslog puede necesitar un XDR Data Collector; su IP no sustituye al endpoint HTTP Ingest.

Preparar piloto y credenciales

Registrar tenant, derechos SIEM, origen, categoría y responsable. La configuración general exige un rol Admin o Super Admin adecuado y acceso al exportador del origen. Su documentación debe explicar URL, Bearer, formato y comportamiento de transmisión; aquí no se presupone un JSON universal.

Elegir un origen de prueba autorizado y un evento inocuo identificable. Anotar hora con zona, identificador y campos esperados. Mantener las rutas existentes hasta la aceptación; el reenvío adicional no debe crear duplicados involuntarios ni transferir datos personales no autorizados.

Integration Key y URL solo se muestran una vez. Preparar antes el almacén de secretos aprobado. No dejar claves en capturas, tickets, repositorios públicos ni comandos guardados en el historial del shell. Documentar propietario y rotación controlada. El Integration Credential Manager admite tipos concretos, no cualquier clave de ingestión.

Crear HTTP Ingest en Sophos Fusion

1. Abrir Security Operations > Integrations > Marketplace > Custom.
2. En HTTP Ingest, pulsar Set Up.
3. Introducir un nombre único, por ejemplo Aplicacion-Prueba-HTTP, y Done. Es una etiqueta libre que debería identificar origen y entorno.
4. Guardar inmediatamente Integration Key y URL en el almacén previsto: no volverán a mostrarse. Si no se han protegido, detener la conexión del origen y aclarar la sustitución admitida; no se promete recuperarlas después.
5. Configurar la exportación HTTPS documentada con esos valores exactos. Comprobar Bearer, formato y posibles reintentos/búferes según la guía del origen. No utilizar cargas inventadas ni plantillas de otras API.
6. Localizar la conexión en Configured integrations de la página Custom; enviar el evento y verificar su ingestión por separado.

El ejemplo práctico de HTTP y parser describe una fuente sintética propia, una plantilla completa de parser y consultas de búsqueda. Compruebe en el tenant los resultados esperados de cada paso antes de utilizar una fuente real.

Validar transporte, normalización y análisis

Una Custom Integration asegura primero el transporte a XDR. Sophos normaliza tipos ya compatibles; formatos propios o no admitidos pueden acabar en generic. El modelo de parsers del artículo SIEM explica por qué pueden hacer falta un parser personalizado y campos obligatorios adecuados.

Para la aceptación, abrir Security Operations > Integrations > Configured Data Sources y seleccionar el origen propio. En sus detalles, Advanced Search muestra una búsqueda preparada para su ID de sensor durante las últimas 24 horas. Acotar el periodo al momento de la prueba y comparar tenant, identificador de origen, hora del evento, acción y campos necesarios con el evento enviado. Aceptar integraciones explica el punto de entrada, y Data Lake Search, cómo acotar más la búsqueda.

Un estado verde indica conectividad; no confirma una ingesta completa ni el esquema correcto. Encontrar texto bruto generic no demuestra que el detector deseado pueda usarlo. La ausencia de resultados en búsqueda simple no excluye datos generic.

Aceptar el piloto solo al demostrar por separado transporte, mapeo utilizable y búsqueda deseada. Probar una detección únicamente si hay una lógica adecuada y admitida para el origen. Un evento corriente de auditoría o inicio de sesión no tiene por qué generar alerta.

Errores y retirada controlada

Si faltan datos, comprobar primero envío real, endpoint y uso de la clave como Bearer. Después revisar errores del origen, red, intervalo temporal y estado. Un HTTP correcto no sustituye la comprobación del evento. Si los datos llegan mal mapeados, revisar formato/parser en lugar de crear preventivamente un segundo conector.

Para pausar, detener la exportación mediante el procedimiento documentado del origen. Antes de retirar, aclarar dependencias, evidencias históricas y conservación. Detener solo ese reenvío y validar la ruta anterior aún necesaria. Eliminar integración, revocar clave y borrar datos históricos son operaciones distintas; no se promete un interruptor universal. Ante claves perdidas o comprometidas, aclarar con Sophos la sustitución/revocación admitida, sin improvisar una rotación no probada.