Ir al contenido
Avanet
Iniciar sesion

Conectar registros de flujo cloud a Sophos XDR y SIEM

Sophos Fusion Admin Sophos SIEM

Los registros de flujo cloud describen conexiones de red, no el contenido completo de los paquetes. Sophos XDR puede recibirlos de AWS VPC Flow Logs, Azure Network Watcher, Google Cloud Platform (GCP) y Oracle Cloud Infrastructure (OCI). La ruta depende de la fuente: S3 y Lambda para AWS, Azure Storage y una Function para Network Watcher, Pub/Sub para GCP y Streaming para OCI.

La telemetría netflow de estas integraciones requiere Sophos Next-Gen SIEM. GCP y OCI también proporcionan otros esquemas mediante las mismas integraciones; esto no convierte todos sus datos cloud de auditoría o seguridad en datos exclusivos de SIEM. Primero se confirman categorías necesarias, tenant, actualización a Fusion y derechos de licencia. La guía de SIEM y retención explica el alcance comercial.

Estas conexiones directas no equivalen a un collector syslog alojado en el cloud. Para ese otro camino se utiliza el runbook del collector XDR.

Antes del primer cambio cloud

Se necesita la tarjeta de producto correspondiente al tenant de destino en Security Operations > Integrations > Marketplace, permisos administrativos cloud aprobados para los recursos y un equipo responsable de costes recurrentes, claves y calidad de datos. Comprobar disponibilidad y campos en el tenant; no sustituir una tarjeta ausente por otra integración de nombre similar.

Documentar cuenta o suscripción cloud, región, categorías deseadas, integración de destino e inicio de ingesta por fuente. Limitar permisos a la ruta prevista. Los privilegios administrativos necesarios para desplegar no justifican utilizar permanentemente una cuenta personal de administrador como identidad de integración. Lambda, Storage o Pub/Sub pueden generar costes cloud adicionales.

Un estado verde confirma comunicación, no la ingesta completa. La aceptación necesita un evento inocuo autorizado con evidencia y hora en origen, seguido del registro normalizado correspondiente. La guía de integraciones explica permisos, flujo y diferencias respecto a acciones de respuesta.

AWS VPC Flow Logs mediante un bucket S3 propio

AWS VPC Flow Logs se recoge desde un bucket Amazon S3 propio. Sophos proporciona una plantilla CloudFormation que crea una función Lambda de reenvío. Se requiere cuenta AWS, bucket con registros de flujo y permisos para crear los recursos Lambda, CloudFormation e IAM necesarios.

  1. Abrir AWS VPC Flow Logs en el Marketplace Sophos. En Configured integrations > Add new, leer la información S3, elegir Next, introducir un nombre identificable y seleccionar Done. Descargar la plantilla generada después del aprovisionamiento y guardarla con acceso restringido.
  2. En AWS dirigir la exportación VPC prevista a ese bucket. El destino debe ser Amazon S3. Usar únicamente el formato predeterminado de AWS; un formato personalizado puede perjudicar normalización y detección.
  3. En la misma región AWS del bucket de registros, abrir CloudFormation > Create stack, cargar la plantilla y elegir un nombre sin espacios. Definir IntegrationType como awsvpcflow. En NotificationBucket introducir el nombre del bucket, no una URL ni URI S3. Si se usa deliberadamente SNS en lugar de notificaciones S3, introducir su ARN en SNSNotificationarn. Revisar los demás parámetros según el camino previsto.
  4. Revisar y aceptar la creación de recursos IAM, crear el stack y esperar CREATE_COMPLETE. Un bucket separado que almacene la plantilla no tiene que hacerse público.
  5. En Lambda, abrir la función creada por el stack. En Function overview > Add Trigger, añadir el bucket de logs como fuente S3. Elegir Event Type: All Object Create Events. Prefix contiene solo el prefijo real de los registros; dejarlo vacío si no se usa. Dejar Suffix vacío. Revisar los costes y añadir el trigger.
  6. Generar un flujo de red inocuo y apropiado dentro del VPC elegido. Primero comprobar el registro en el bucket; después comparar período y características de conexión en el esquema Sophos netflow.

El formato predeterminado requerido es:

${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}

Si no llegan datos, comparar destino, nuevos objetos, región y prefijo del trigger. La plantilla establece Reserved Concurrency en 5 por defecto; no garantiza dimensionamiento. Evaluar carga y métricas CloudWatch. Rate Exceeded puede indicar una cuota de concurrencia AWS; recrear repetidamente la integración no resuelve ese límite.

Azure Network Watcher mediante Storage y Azure Function

Network Watcher escribe NSG Flow Logs o VNet Flow Logs en un Azure Storage Account. Ya no se pueden crear nuevos NSG Flow Logs. Planificar VNet Flow Logs para las nuevas fuentes. Los NSG Flow Logs existentes pueden conectarse hasta su sustitución; Microsoft retirará la función el 30 de septiembre de 2027. Planificar su migración a VNet Flow Logs antes de esa fecha. Ambos tipos necesitan integraciones Sophos separadas, porque usan contenedores Blob o Data Source Keys diferentes.

Se necesita una suscripción Azure activa, el Storage Account con su contenedor y flow logs activados y un plan Azure Function compatible. Están documentados Basic con B1, B2 o B3, Dynamic con Y1 y determinados códigos Premium. Isolated no es compatible. Elegir un código Premium de la lista ofrecida actualmente, sin deducir compatibilidad por semejanza de nombres.

  1. En Network Watcher enviar VNet Flow Logs para una fuente nueva al Storage Account previsto; utilizar NSG Flow Logs existentes solo como transición hasta la migración. Anotar nombres de cuenta y contenedor y comprobar que llegan nuevos objetos.
  2. En Marketplace Sophos abrir Microsoft Azure Network Watcher - Azure Storage Account y crear la integración en Azure Storage Accounts > Set Up.
  3. Copiar exactamente Storage Account Name. Function App Name es un nombre descriptivo propio, por ejemplo NSGFlowLogsForwarder, no un valor fijo del producto. Definir Data Source Key como insights-logs-networksecuritygroupflowevent para NSG o insights-logs-flowlogflowevent para VNet.
  4. Elegir Azure Function Service Plan Type, su Service Plan Code y Num Workers. El valor predeterminado es un worker. Para Basic B2/B3 se documenta un máximo de tres; no extender ese límite a otros planes.
  5. Seleccionar Done para generar y descargar AzureFunction.json. En Azure cargarlo mediante Deploy a custom template > Build your own template in the editor. Revisar Resource Group y parámetros, luego Review + Create y Create.
  6. Storage Account y Function pueden estar en Subscription IDs o Resource Groups distintos. En ese caso, definir explícitamente Storage Account Subscription ID y Storage Account Resource Group para la fuente real.
  7. Tras el despliegue, comprobar un flujo esperado en el contenedor correcto y después en netflow en Sophos. Validar cada integración por separado si se utilizan los dos tipos.

Si existe la Function pero faltan datos, comparar contenedor, Data Source Key, relación Subscription/Resource Group y plan. Una segunda integración del mismo flujo puede producir duplicados; no es una reparación general.

GCP mediante Pub/Sub

GCP proporciona cloudaudit, thirdpartyalert y, con SIEM, netflow. Se admiten Cloud Audit Logs, Security Command Center Findings, VPC Flow Logs y GKE Dataplane V2. Incluir solo categorías seleccionadas deliberadamente.

  1. En el proyecto GCP correcto crear un topic en Pub/Sub > Topics y una suscripción en Subscriptions. Establecer Acknowledgement deadline en 300 segundos.
  2. En Logging > Log router > Create Sink, crear un sink destinado a ese Cloud Pub/Sub topic. Limitar filtros de inclusión a fuentes necesarias. Los logs de organización y carpeta necesitan un sink agregado adecuado; un sink de proyecto no los cubre automáticamente.
  3. Crear una cuenta de servicio dedicada. En Add Principal de la suscripción Pub/Sub, asignar a su ID el rol Pub/Sub Subscriber.
  4. Crear también un rol personalizado con monitoring.timeSeries.list y asignarlo a la cuenta. Puede reutilizarse una cuenta ya usada por Sophos XDR si también se aprueba este permiso necesario.
  5. Generar una clave JSON y almacenarla de forma segura. En Marketplace Sophos abrir GCP > Configured integrations > Add new, introducir nombre, Project ID y Subscription ID Pub/Sub y cargar el JSON correcto mediante Upload Key File.
  6. Activar realmente las fuentes seleccionadas: los logs Data Access requieren seleccionar expresamente servicios en IAM & Admin > Audit Logs. Los findings SCC utilizan su exportación Pub/Sub. Activar VPC Flow Logs a nivel de subred; el muestreo limita su alcance frente a una captura íntegra de paquetes.
  7. GKE Dataplane V2 debe seleccionarse al crear el clúster. Comprobar después Network Policy Logging y el filtro del sink. No sustituir sin planificación un clúster existente únicamente para un piloto de logging.
  8. Generar un evento adecuado por categoría activada y verificar por separado evidencia de origen, camino Pub/Sub y esquema normalizado.

Para rotar claves, crear primero el nuevo JSON y actualizar la integración Sophos existente. En API Query Log, secrets cache invalidated. Integration was updated. Restarting. indica la actualización. Eliminar la clave GCP antigua solo después de verificar nuevamente la ingesta. Cargar el archivo no basta.

OCI mediante Streaming

OCI proporciona cloudaudit, http, nids y, con SIEM, netflow. Se necesitan un stream OCI, los logs deseados y un service connector. La identidad requiere stream-pull para leer; no hacen falta permisos administrativos generales para la recogida continua.

  1. Preparar un usuario de logging dedicado y la estructura aprobada de grupos/compartments. Conceder solo lectura necesaria sobre el stream previsto.
  2. En OCI Streams > Create Stream, elegir el Stream Pool correspondiente. Anotar Stream Pool OCID; no equivale a cualquier ID de stream o compartment.
  3. Mediante Connector Hub, dirigir al stream los logs autorizados de auditoría, flujos, load balancer, WAF o firewall. Antes de Sophos, verificar que el connector entrega datos al destino Streaming correcto. Otro destino no alimenta automáticamente ese stream.
  4. En Marketplace Sophos abrir OCI > Configured integrations > Add new. Introducir Name, Username dedicado, su Auth token, Stream Pool ID, Tenant Name, Topic Name del stream y Region.
  5. Para compartments anidados, Tenant Name es el nombre de tenancy sin la cadena de compartments. Con usuarios federados del caso documentado OracleIdentityCloudService, usar por ejemplo acme/OracleIdentityCloudService, donde acme representa la propia tenancy. No mezclar ambos casos.
  6. Elegir Done y comprobar un evento apropiado en OCI, en Streaming y en el esquema Sophos esperado. Un evento cloud audit no valida un flujo netflow adicional.

Si falla la ingesta, comprobar primero Stream Pool, nombre del stream, región, token y stream-pull. Si falta solo una categoría, revisar selección de fuentes y routing del connector antes de recrear la integración entera.

Validar calidad y retirada controlada

Documentar por categoría fuente, inicio de ingesta, período, esquema normalizado y ejemplo reproducible. Comparar hora y zona horaria con la evidencia original. Un flujo normal o registro de auditoría no tiene que crear una detection ni case MDR. Una conexión verde o un registro encontrado tampoco prueba años de retención.

Antes de retirar, identificar ruta y recursos compartidos. Detener solo exportación, sink, trigger o connector autorizado; no eliminar indiscriminadamente bucket, topic, Storage Account o stream compartidos. Tras comprobar que no llegan registros nuevos, retirar la configuración Sophos correspondiente y claves o recursos exclusivamente dedicados según decisiones de cambio y retención. Borrar una conexión no demuestra que se hayan eliminado los datos históricos.

Durante un piloto fallido, conservar rutas anteriores necesarias. El rollback revierte el cambio documentado de routing o exportación y comprueba el resultado. No revierte automáticamente datos enviados, costes cloud ni eventos perdidos.