Configurar integraciones MDR y XDR en Sophos Fusion

Las integraciones permiten que Sophos Fusion (antes Sophos Central) reúna telemetría de productos de Sophos y de terceros en Sophos Data Lake, o que ofrezca Response Actions específicas. Es esencial elegir el tipo de integración correcto: Data Ingest proporciona datos para consultas, detecciones e investigaciones; Response Action ejecuta una acción en el producto conectado. No todos los productos admiten ambos sentidos.

El punto de entrada depende del estado del producto en el tenant. Para la solución ampliada de XDR/MDR se utiliza Security Operations > Integrations > Marketplace; las configuraciones Classic existentes se encuentran en Threat Analysis Center > Integrations. Las instrucciones de TAC que se conservan a continuación describen esta ruta Classic y no representan una secuencia de clics idéntica para la nueva interfaz. La comprobación de actualización específica del tenant ayuda a identificar la ruta correspondiente. La mera presencia de nombres de Fusion no demuestra que se haya completado la actualización del producto.

En la ruta de incorporación de Endpoint, este artículo completa la fase de integración entre productos que se encuentra entre la configuración de la protección y la aceptación operativa.

El proceso práctico consiste en comprobar la licencia y el sistema de origen, elegir en Marketplace la ficha y la configuración adecuadas del producto, establecer la conexión con los permisos mínimos necesarios, comprobarla en Configured y verificarla mediante un evento de prueba previsto. La integración no debe considerarse productiva antes de completar estos pasos.

Comprobar conexión y flujo real de datos por separado

En la interfaz actual abrir Security Operations > Integrations > Configured Integrations. En Data Ingest, el estado indica configuración y conexión de la integración API, syslog o Sophos. Verde confirma comunicación, no eventos ya normalizados correctamente. Puede aparecer advertencia tras 20 minutos sin comunicación o si algunos recursos no informan; error tras 60 minutos o autenticación fallida. El texto al pasar el cursor precisa el motivo.

Para una integración API abrir su nombre y API Query Logs. Por defecto aparece el último día; se pueden seleccionar hasta siete días. En Details, comparar parámetros con el tenant fuente correcto. Una integración jerárquica puede contener un parent con varios endpoints child; un subtrayecto sano no prueba que todos funcionen.

Comprobar después Security Operations > Integrations > Configured Data Sources. Esta vista separada indica si los logs llegan realmente y a qué esquemas se asignan. Healthy significa actividad en la última hora, Warning entre una y 24 horas y Unhealthy más de 24 horas sin actividad. Son criterios distintos de los umbrales de conexión anteriores. Evaluar una fuente que transmite raramente según la actividad esperada, no declararla sana mediante un evento inventado.

Pulsar la fuente muestra el historial de mensajes por esquema de las últimas 24 horas. Para aceptar, generar un evento autorizado en el sistema fuente y comparar hora, fuente, campos obligatorios y esquema normalizado. Advanced Search en los detalles abre una búsqueda preparada por ID de sensor para las últimas 24 horas. La guía de búsqueda explica cómo acotarla. Si faltan datos, comprobar primero fuente → integración/collector → esquema; no se espera necesariamente una detection de un evento de auditoría ordinario.

Export All as CSV o Export Selected as CSV guarda el inventario de fuentes mediante Data Exports. La papelera solo elimina el registro de la fuente, no la telemetría ya recibida. La eliminación no se puede deshacer; una fuente que sigue enviando reaparece y el proceso puede tardar cinco minutos. Eliminar no confirma por tanto el borrado de telemetría ni constituye una prueba de reparación.

Visibilidad, permisos y allowlist API actual

Según el producto, Marketplace muestra tarjetas Ingest y Actions separadas. EDR sin XDR no muestra tarjetas Ingest ajenas a endpoints; las acciones de respuesta pueden seguir visibles. Admin y Super Admin pueden gestionar integraciones. Help Desk y Read-only solo ven configuración y estado. En Custom Roles conceder Integration: read y únicamente los permisos necesarios create, update, delete y download. Revisar licencia y rol antes de ampliar permisos por una función ausente.

Distinguir la allowlist XDR actual de la instantánea IP Classic conservada abajo y del uplink del collector. Identificar la región geográfica XDR real en Profile icon > Support settings, sin deducirla de un nombre de producto. La lista del fabricante del 25 de septiembre de 2026 indica estas redes para llamadas administrativas/API al tercero:

Autorizar únicamente la red de la integración real, tras aprobar el cambio. La lista no demuestra disponibilidad de todos los productos en todas las regiones ni sustituye comprobar los destinos API necesarios actualmente. El trayecto mTLS saliente del collector utiliza otros destinos.

Dirigir con precisión las notificaciones Health

Las reglas explicadas abajo para 24 horas de fallo continuo, reinicio del contador y repetición cada 30 días también se aplican a la ayuda Fusion actual del 20 de octubre de 2026. El correo no es una alerta inmediata tras los 20 o 60 minutos mencionados.

Abrir una regla de destinatarios propia en General Settings > Platform > Notification Settings > Configure email alerts > Custom rules > + Create new rule. Tras rol, administradores/listas y alcance de dispositivos, seleccionar en Alert Types los filtros Medium alert, producto Sophos Central y categoría Central Integrations Alert. Establecer nombre/descripción y guardar. Planificar antes la distribución de otras alertas: la primera regla propia desactiva el envío predeterminado de todos los correos de alerta a todos los administradores. Mantener los demás destinatarios necesarios mediante reglas adicionales adecuadas; no provocar una avería de prueba en un connector de producción solo para forzar un correo.

Siguientes pasos por fuente

Para fuentes propias, HTTP Ingest, S3 y Azure explican transportes distintos. La operación del collector y el despliegue cloud complementan la migración existente. Cloud Flow Logs, telemetría de red y Windows Event Logs cubren formatos fuente y límites de licencia por esquema. No toda telemetría de un fabricante es automáticamente exclusiva de SIEM.

Después de la actualización: restablecer el funcionamiento de Response Actions

Estado comprobado a 11 de octubre de 2026: la solución ampliada utiliza un modelo de ejecución y permisos diferente para las acciones. Las conexiones de TAC existentes y sus credenciales no se transfieren sin más a este modelo. Antes de realizar un cambio, documente los tenants de Microsoft afectados, las conexiones, las acciones activadas y las personas responsables. La ingesta correcta de datos de un conector independiente de auditoría o Graph no constituye una prueba de respuesta.

Volver a conectar Microsoft 365 o autorizar de nuevo las credenciales

Para estos pasos se necesita el rol Admin o Super Admin en Sophos Fusion y un Microsoft 365 administrator en Microsoft. Compruebe en cada diálogo de consentimiento los permisos realmente solicitados y que el tenant de Microsoft sea el correcto; no adopte sin revisión el conjunto de permisos de una antigua aplicación de TAC.

Si la antigua conexión de TAC aún no está configurada en la nueva interfaz, créela de la siguiente manera:

1. Abra Security Operations > Integrations > Marketplace y la ficha de acciones Microsoft Graph API.
2. Seleccione Add new connection. En la sección Add a Connection, vuelva a seleccionar Add new connection, introduzca Name y, si es necesario, Description y Tags, y continúe con Done.
3. Inicie la autorización guiada de Microsoft con Proceed. Un nombre como M365-Response-Produktiv es solo una etiqueta de libre elección; lo importante es que el tenant de origen sea el correcto y que los permisos estén aprobados.
4. En Pick an account, seleccione la cuenta de administrador prevista. La primera solicitud Permissions requested autoriza la aplicación maestra de Sophos. Tras volver a Sophos, se realiza un segundo paso en Microsoft para la conexión de respuesta propiamente dicha. Después de revisar los permisos, complete ambos diálogos con Accept. Si se cancela cualquiera de ellos, no se crea ninguna conexión.
5. Al volver, revise las acciones ofrecidas y guarde únicamente el alcance autorizado con Save. La nueva conexión debe aparecer en Configured Integrations.
6. En Microsoft Entra, en Manage > All applications, utilice Refresh para comprobar que la aplicación de respuesta recién creada aparece activada.

Si ya existe una conexión en Microsoft Graph API > Configured Integrations, abra el menú de tres puntos junto al nombre de la conexión y seleccione Edit Connection. Seleccione Re-Authorize Credentials y complete la autorización de Microsoft. El botón solo aparece cuando se necesita una nueva autorización y desaparece al finalizar. Repita el proceso para cada conexión afectada; reparar una sola conexión no basta para todos los tenants o configuraciones.

La guía actualizada del 7 de octubre de 2026 distingue expresamente entre la protección, que sigue funcionando, y las acciones de respuesta de Microsoft, que pueden fallar hasta que se autoricen de nuevo. Indica el 1 de octubre de 2027 como fecha de caducidad de las credenciales anteriores. Si necesita las acciones, no espere hasta esa fecha: debe demostrar su funcionamiento ahora.

La aceptación debe incluir la aplicación correcta de Entra, las conexiones previstas y las acciones activadas, además de una prueba autorizada con una cuenta dedicada. Utilice únicamente un cambio reversible documentado para la acción actual. La pareja Classic Block user sign-in / Allow user sign-in descrita más adelante no demuestra que todas las acciones nuevas tengan el mismo nombre o la misma vía de reversión. Las sesiones no pueden restaurarse después de revocarlas. En los detalles de la acción, View Executions > History muestra el historial; compruebe también el estado real en Microsoft. El consentimiento o una entrada de ejecución correcta, por sí solos, no sustituyen esta comprobación.

Añadir Sophos Firewall (Actions) solo si falta la conexión

Después de actualizar el producto, abra primero un Case y compruebe si están disponibles las acciones de Sophos Firewall. Si lo están, no hace falta una conexión nueva. Si faltan:

1. Abra Security Operations > Integrations > Marketplace.
2. Busque y abra Sophos Firewall (Actions).
3. Seleccione Add new connection y guarde con Save.

Esta conexión no requiere credenciales. Después estarán disponibles las acciones de respuesta del firewall desde Cases, por ejemplo, para bloquear direcciones IP, dominios o URL maliciosos. Los analistas de MDR pueden ejecutar estas acciones dentro de la configuración de respuesta autorizada; los usuarios de XDR pueden iniciarlas por su cuenta desde el Case. Compruebe la disponibilidad sin bloquear destinos de producción. Una prueba de efecto constituye un cambio independiente y autorizado, con una vía de reversión específica del producto aclarada de antemano.

Desactivar acciones nuevas de forma selectiva en lugar de eliminar conexiones a ciegas

Para las acciones de la solución ampliada existe un interruptor documentado: en Security Operations > Integrations > Marketplace, Configured > Actions, abra la acción correspondiente y desactívela en la sección Enable/disable integration. No es un interruptor universal para todos los conectores de Data Ingest. La desactivación no revierte los cambios ya ejecutados en el sistema de origen.

Delete Integration elimina las conexiones y condiciones asociadas y devuelve la configuración de la acción a su estado inicial. Eliminar la única conexión también elimina sus condiciones asociadas. Por tanto, guarde o documente previamente las conexiones y condiciones. Para revertir las acciones de prueba sigue siendo aplicable la vía concreta de Microsoft o del firewall, no la eliminación del conector.

Automatizaciones XDR: distinguir Classic REST de GraphQL

El estado de las API corresponde a una adenda del 9 de octubre de 2026, no a una garantía retroactiva sobre el lanzamiento de septiembre. Las nuevas integraciones XDR y los flujos de trabajo XDR con operaciones de escritura en Fusion deben utilizar las nuevas GraphQL APIs. Esto debe distinguirse de una conexión de API de Marketplace: sus llamadas REST pueden seguir dirigiéndose al proveedor externo.

Las anteriores Cases REST API y Detections REST API se denominan ahora Classic XDR APIs y se ha anunciado su retirada. Detections REST API ya es read-only. Cases REST API sigue disponible para las integraciones existentes; también está previsto que pase a ser de solo lectura más adelante. Después, ambas API deberán proporcionar datos históricos hasta su eliminación. Este estado no especifica una fecha concreta de retirada. Por tanto, no elimine indiscriminadamente las integraciones existentes ni cambie sus hosts por el mero hecho de utilizarse el nombre Fusion.

Para cada automatización, anote la API, las operaciones de lectura y escritura, el periodo de datos, el tenant, los permisos y la gestión de errores. En los clientes existentes, compruebe por separado si se esperan datos actuales o históricos y si algún flujo de escritura aún pretende acceder a Classic Detections. Para pasar a GraphQL, debe implementar la correspondencia de campos, la paginación, la autenticación, los permisos y la gestión de errores conforme al nuevo esquema concreto y compararlos en una prueba aislada. Este artículo no proporciona deliberadamente endpoints, nombres de mutaciones ni payloads inventados. El inventario estará completo cuando cada cliente tenga un responsable y una decisión trazable de continuidad operativa o migración; esto todavía no constituye una prueba satisfactoria de migración de API.

¿Qué API GraphQL corresponde al cliente?

El lanzamiento del 18 de septiembre de 2026 incluía cinco API GraphQL con funciones diferentes:

• Detections v2: buscar y editar Detections de endpoints, sensores de red y otras fuentes.
• Cases v2: gestionar Cases, así como Evidence, comentarios, archivos y enlaces.
• Threat Timeline v2: buscar relaciones entre procesos para hasta 100 procesos en una sola llamada.
• Events v1: obtener detalles de eventos a partir de Event-IDs conocidos.
• Live Endpoint Search v1 (LES): ejecutar consultas de estilo osquery en endpoints conectados y obtener resultados y Telemetry.

Live Discover REST no forma parte del anuncio de retirada de las Classic Cases/Detections APIs. Las integraciones existentes de Live Discover REST pueden seguir funcionando; su migración a LES es opcional. La vía en vivo y la XDR Query API histórica cumplen funciones distintas. La distinción entre las API de Live Discover también explica la selección de destinos de LES basada en sesiones. Del mismo modo, ni la Endpoint API en /endpoint/v1 ni su Device Migration se migran a GraphQL a causa de este anuncio de retirada de XDR.

Desde el 12 de octubre de 2026 también está publicada la Search GraphQL API v1 para búsquedas QL históricas. Ofrece createSearch, getOrCreateSearch, search y searchResults; Consultar el Data Lake de Sophos Fusion con la Search GraphQL API describe el contrato de solicitud, el estado de ejecución, las páginas de resultados y la comprobación de migración SQL. Data Lake Search sigue siendo la vía interactiva; XDR Query API sigue disponible. La nueva API no obliga a un cambio inmediato ni constituye un flujo LES de endpoints en vivo. Para Assets y Entity Graph siguen pendientes las comprobaciones separadas de referencias y tenant: su mención en la guía de Cases no autoriza una implementación completa.

Comprobar el contrato concreto de migración

El cambio no consiste en sustituir la URL manteniendo el cliente sin modificaciones. Para Cases, Detections y, opcionalmente, LES, se compara el flujo de trabajo propio de cada uno, no una receta común de REST a GraphQL:

• GraphQL solo devuelve los campos seleccionados. El cliente comprueba tanto el estado HTTP como el array errors y los campos de estado específicos de la operación; HTTP 200 puede contener un error de consulta. Los campos anidados necesarios y los datos temporales con seconds/nanos se seleccionan y procesan deliberadamente.
• En Detections, detectionSearch sustituye el procedimiento REST de inicio de consulta, consulta de estado y obtención de resultados. Los conjuntos pequeños de resultados utilizan offset/limit; los grandes, el search_id devuelto junto con detectionPoll. Coteje todas las partes y el total. Los filtros se comprueban individualmente como predicados QL; una búsqueda de host espera un ID, no simplemente el nombre del dispositivo. No se garantiza un sustituto idéntico para un type de REST o una reputación de Intelix.
• La Severity de Detection de REST y GraphQL evalúa conjuntos de datos independientes mediante modelos independientes. REST utiliza una escala de enteros hasta 10; metadata.severity de GraphQL, una escala de 0 a 1. No convierta los valores mediante una división. Reevalúe los umbrales con criterios técnicos basados en los datos correspondientes. Case.severity, con 2/4/6/8/10, constituye otra escala diferente.
• En Cases, el cliente de API utiliza la UUID id, no la shortId legible con el formato CSE#####. Los antiguos ID de Cases REST no se traducen y los Cases antiguos no pasan a estar disponibles mediante la nueva API. Las evidencias necesarias de casos antiguos se guardan antes de la transición mediante la vía anterior de obtención confirmada; esto no implica un botón universal de exportación ni la transferencia del historial.
• Los tipos de Case, estados y Verdicts se resuelven como datos de referencia dinámicos del tenant, dependientes de la licencia, y se actualizan periódicamente. assigneeId espera una Subject ID o una @mention admitida, no una dirección de correo electrónico. Un assigneeSubject que no pueda resolverse puede ser null; la visualización necesita una alternativa definida expresamente para este caso.
• caseEvidence devuelve ID de vínculos, no payloads completos de Evidence. Las Detections se obtienen después mediante detectionRetrieveById con el argumento escrito exactamente como iDs; los Events, mediante sus Resource Names sin modificar. Las dependencias de Asset y Entity Graph quedan pendientes hasta comprobar la referencia correspondiente y el tenant. Los ID de Detection, Event, Asset y Entity Graph no son intercambiables; un punto de entrada de Entity Graph para un Case utiliza su UUID como INVESTIGATION, no la shortId.
• La paginación de Cases utiliza Offset o Cursor, no ambos en una misma solicitud. Para una lista que cambia, dé preferencia a Cursor y envíelo de nuevo sin modificarlo. keyFindings es un documento tipado y se devuelve al obtener un Case individual, no en la lista de Cases. Los filtros anteriores overviewContains y escalated no tienen un sustituto directo; decida expresamente las funciones necesarias antes de la transición.
• No existe deleteCase como sustituto de DELETE de REST. El cierre, en su caso con el Verdict exigido por el tipo de Case, y el archivado opcional posterior son pasos independientes. En los Cases de MDR administrados por el proveedor, los campos en los que realmente se permite escribir son más limitados y deben comprobarse de antemano.

Un piloto debe responder a la misma pregunta técnica en el tenant correcto, con ID trazables, paginación completa y errores evaluados. Las funciones adicionales de GraphQL, como comentarios, archivos, enlaces, reglas, Templates y Split/Merge, son ampliaciones independientes, no requisitos para todas las transiciones. La falta de correspondencia entre campos o un historial sin aclarar siguen requiriendo una decisión pendiente sobre el cliente; no se pasan por alto suponiendo una equivalencia.

Alcance: XDR, MDR y licencias

Una integración no sustituye una licencia XDR o MDR. XDR proporciona funciones de análisis con las que un equipo de seguridad propio investiga datos en Threat Analysis Center y Data Lake. MDR añade el servicio administrado de Sophos. Las integraciones seleccionables en el tenant dependen del contrato de Sophos, el producto, el tipo de integración y, en su caso, la licencia del producto de terceros.

Para una conservación más prolongada o fuentes de datos propias, Sophos Next-Gen SIEM explica cómo comprobar el complemento opcional y elaborar un inventario de retención por fuente.

La afirmación frecuente de que ciertas integraciones son gratuitas no significa que todo Marketplace lo sea. Para MSP Flex existen Integration License Packs independientes para categorías como Endpoint, Network, Email o Firewall. La regla anterior de MSP Flex indicaba que, con una licencia XDR, Sophos NDR, Sophos Cloud Optix, Microsoft Graph Security y Microsoft 365 audit appliance no necesitaban un Integration License Pack adicional. Esta regla se aplica expresamente solo a clientes MSP Flex. Cloud Optix ya solo figura en ella como referencia histórica: su fin de vida el 30 de septiembre de 2026 impide planificar nuevos usos productivos de este servicio. Por tanto, compruebe qué está habilitado en su tenant y contrato en lugar de presuponer un alcance gratuito general.

El sistema conectado también puede exigir licencias. Las páginas de Sophos se contradicen respecto a Microsoft 365: la página de descripción general indica que los logs de auditoría de Management Activity están disponibles para todos los clientes de Microsoft 365, mientras que la página de configuración específica exige Purview Audit (Standard o Premium), una de las licencias de usuario que enumera y la auditoría activada. Para la configuración se aplican estos requisitos concretos. Las Detections que proporciona Graph Security V2 también dependen del alcance de la licencia de Microsoft y de las funciones de Defender XDR disponibles. Para Microsoft 365 Response Actions en la ruta Classic/TAC, Sophos no indica ningún requisito de licencia de Microsoft; sin embargo, se necesita un administrador de Microsoft 365 y los permisos de Graph indicados más adelante expresamente como Classic. Para las acciones de la solución ampliada se aplican, en cambio, los requisitos descritos anteriormente y los permisos realmente solicitados durante la autorización en dos pasos; la lista Classic no define el nuevo consentimiento.

Cloud Optix después del fin de vida: tratar por separado la telemetría y CSPM

Sophos Cloud Optix alcanzó su fin de vida el 30 de septiembre de 2026. Desde entonces, el servicio no recopila datos nuevos, no genera hallazgos ni reenvía telemetría a MDR o XDR. A fecha de comprobación del 11 de octubre de 2026, la recomendación anterior de exportar antes del fin de vida y realizar una transición en paralelo ya no es un paso futuro ejecutable.

Compruebe ahora qué entornos de AWS, Azure, GCP u OCI estaban conectados exclusivamente mediante Cloud Optix y cuáles de ellos ya cuentan con una conexión directa a la solución ampliada de XDR/MDR. Estas integraciones directas en la nube deben configurarse para cada plataforma; la actualización del producto no lo hace automáticamente. Sin una nueva conexión verificada, no puede afirmarse que haya cobertura de telemetría sin interrupciones para el periodo posterior al 30 de septiembre. Si un tenant aún no ha realizado la transición o falta una ficha de producto, aclare la situación con el equipo de cuentas o de partners de Sophos.

Una integración directa de API en la nube no es lo mismo que un Syslog Data Collector ejecutándose en AWS, Azure o GCP. Seleccione en Marketplace la integración correspondiente al flujo de datos de la nube que necesita, compruebe los permisos concretos del origen y demuestre después la recepción de datos y las Detections previstas. La evidencia debe identificar la cuenta de la nube, la fuente de datos y el intervalo temporal; una conexión en verde no basta por sí sola.

Cloud Security Posture Management (CSPM) no se transfiere: la evaluación del estado de las configuraciones de la nube, los informes de referencia de cumplimiento y los hallazgos de desviación de la configuración no forman parte de las prestaciones prometidas por las nuevas integraciones de telemetría. Documente esta necesidad por separado y aclare con el equipo de cuentas la solución alternativa y los derechos contractuales restantes. Tampoco se migran al nuevo sistema los informes de Cloud Optix, el historial de hallazgos, las evidencias de cumplimiento ni los datos de inventario. Guarde las exportaciones existentes y compruebe que estén completas; aquí no se confirma ninguna posibilidad de exportación posterior o recuperación.

Tipos de integración y credenciales necesarias

REST API

Una integración de API obtiene datos del servicio en la nube del fabricante o envía allí una acción de respuesta. Según el producto, el asistente de configuración solicita datos como el ID del tenant o de la organización, la URL de la API, Client ID, Client Secret, un token o un certificado. Las integraciones de API no necesitan ninguna appliance de Sophos.

Algunas integraciones reciben las credenciales directamente en el asistente. Otras solicitan una Integration Credential reutilizable. La opción de seleccionar una credencial existente o crear otra en el asistente indica si el conector admite esta función. Integration Credential Manager solo está disponible para una parte limitada de las integraciones de API; su existencia no implica que todos los secretos puedan reutilizarse de forma centralizada.

Log collector

La siguiente descripción de la appliance se aplica a la ruta Classic SVA. En la solución XDR ampliada, los XDR Data Collectors recopilan datos Syslog y tienen sus propios requisitos de recursos y red. Los antiguos valores mínimos de SVA no deben aplicarse a la nueva VM. La migración aprovisiona configuraciones, pero no pone en marcha un sustituto listo para funcionar. Transición de Syslog desde SVA y operación de XDR Data Collector explica las variantes de direccionamiento, las configuraciones excluidas y la transición segura. NDR no se migra automáticamente en este proceso.

En una integración de Log Collector, el sistema de origen exporta eventos mediante Syslog a una Sophos appliance. Su Log Collector procesa los datos y los carga en Sophos Data Lake. La appliance se ejecuta en ESXi, Hyper-V, AWS o Nutanix, o en hardware Dell, NUC u OnLogic adecuado. Para ESXi o Hyper-V asigne al menos 4 CPU, 16 GB de RAM y 160 GB de almacenamiento; se admiten ESXi 6.7 Update 3 con hardware de VM versión 11 o posterior y Hyper-V en Windows Server 2016 o posterior. Sophos gestiona las actualizaciones del sistema operativo y de seguridad de la appliance; no instale en ella otro agente de Sophos ni antimalware. Amplíe los recursos para un volumen elevado de datos o varias integraciones y compruebe DNS, proxy y las excepciones necesarias de puertos y dominios antes de aprobarla. Después, configure en el producto de terceros la conexión a esta appliance, no a un servidor Syslog cualquiera.

Varias integraciones pueden utilizar la misma appliance. Aun así, debe configurar el protocolo, el puerto, el formato y el origen de cada producto conforme a sus instrucciones de integración. Una appliance en verde no demuestra por sí sola que esté llegando el tipo de evento correcto.

Productos de Sophos

Productos como Sophos Firewall o Sophos NDR disponen de procedimientos de configuración específicos. Sophos NDR y las integraciones de Log Collector necesitan una Integration Appliance, aunque no necesariamente una VM clásica. Una integración exclusivamente REST API no necesita appliance. Use Marketplace del tenant afectado para comprobar la disponibilidad: cada ficha muestra los métodos ofrecidos y abre el asistente correspondiente.

Delimitar con seguridad la carga NDR y la appliance compartida

La siguiente topología de appliance compartida se aplica a Classic SVA/TAC, no al nuevo XDR Data Collector. Este sustituye la parte de Syslog; NDR sigue siendo una carga de trabajo de appliance operada por separado y no se transfiere al nuevo Collector.

Solo se permite una integración de Sophos NDR por appliance. La misma appliance puede alojar además varias integraciones de terceros basadas en appliance como Log Collectors. Por tanto, antes de cada cambio, despliegue la entrada de la appliance en Configured > Integration Appliances y compruebe todas las integraciones asignadas. Ni el valor Integrations ni un estado verde de la appliance sustituyen esta comprobación.

Un reinicio específico de NDR interrumpe el sensor NDR mientras los Log Collectors siguen funcionando. En cambio, Restart o Shutdown de toda la VM interrumpe NDR y todos los Log Collectors de esa appliance. Planifique estas acciones en una ventana de mantenimiento, documente previamente el estado de todas las cargas de trabajo y compruébelas después una por una. Operar de forma segura la appliance y el sensor de Sophos NDR describe el procedimiento.

Delete en el menú de la appliance no elimina únicamente una integración. No elimine la appliance mientras tenga asignado NDR o algún Log Collector. Además, la opción del menú no indica que se vaya a eliminar la VM desplegada ni que se borren los datos ya ingeridos en Data Lake. Antes de retirarla, aclare las asignaciones, la conservación de datos, el desmontaje de los recursos de la plataforma, la vía de recuperación y la comprobación final. Hasta entonces, mantenga la appliance.

Antes de la configuración

1. Inicie sesión en Sophos Fusion como Admin o Super Admin. Sophos exige uno de estos roles para la configuración general.
2. Compruebe qué licencia, rol de administrador, función de API o salida Syslog requiere el producto de terceros.
3. Decida si necesita Data Ingest, Response Action o ambos. Una integración de respuesta no proporciona automáticamente la telemetría en la que se basa una investigación.
4. Cuando sea posible, cree una aplicación o una cuenta de servicio dedicada para el acceso a la API. Conceda solo los permisos exigidos en las instrucciones del producto y documente el propietario, la fecha de caducidad y el proceso de rotación del secreto.
5. Si el producto de terceros exige una lista de IP de origen permitidas para llamadas administrativas a la API, identifique primero la región de Central en My Environment > Installers: coloque el puntero sobre un enlace de descarga de Endpoint Protection o Server Protection y lea la región en la URL mostrada, por ejemplo eu-central-1. Permita después solo las direcciones de esa región de la tabla siguiente. Son orígenes de las llamadas de la API de Sophos, no destinos salientes de la Integration Appliance.
6. Para una Integration Appliance, compruebe su propia ruta de red saliente, DNS y, si corresponde, proxy conforme a los requisitos de la appliance.
7. Prepare un evento de prueba reproducible e inocuo. Un evento de inicio de sesión o auditoría es preferible a un intento real de introducir malware.

Direcciones IP de origen para listas permitidas de API

Esta tabla muestra el conjunto de IP de Classic comprobado el 14 de septiembre de 2026. Debe distinguirse de la lista permitida actual de XDR indicada arriba y no constituye por sí sola evidencia suficiente para modificar una lista permitida de producción.

Antes de un cambio, comprobar la generación de la integración, la región del tenant y el conjunto completo de IP necesarias con la información actual de Sophos. Si hay discrepancias, no utilizar valores antiguos ni combinar regiones. Hacer que se revisen la asignación de región y el cambio según el proceso de aprobación propio, permitir solo el alcance necesario y después validar la integración afectada con una sincronización de API o un evento de prueba inocuos. Documentar en el cambio el estado inicial, la aprobación, los resultados y la vía de recuperación.

Sophos etiqueta actualmente como sa-east-1 tanto la fila de São Paulo como la de Dubái. Distíngalas por la ubicación del tenant y el conjunto de IP; no combine regiones. Documente la lista aprobada en el cambio.

Añadir una integración desde Marketplace

1. Abra Threat Analysis Center > Integrations > Marketplace.
2. Busque el fabricante o el producto. Si hay entradas similares, abra la página del producto y compruebe la categoría, el nombre del producto, el tipo de integración y la finalidad. Cisco Meraki y Fortinet FortiAnalyzer, por ejemplo, se ofrecen tanto mediante API como mediante Log Collector.
3. Abra la integración deseada.
4. Seleccione el tipo necesario, por ejemplo Data Ingest, y haga clic en Add Configuration.
5. Siga los pasos de Integration setup. En las integraciones de API, introduzca los datos del sistema de origen o conceda un consentimiento OAuth. En las integraciones de Log Collector, cree o seleccione una appliance y dirija después la exportación Syslog del sistema de origen hacia ella.
6. Si Sophos solicita dominios internos y rangos de IP al configurar la primera integración, introduzca únicamente sus rangos internos. Estos datos identifican direcciones propias, agrupan alertas relacionadas y evitan consultas a terceros; no deben confundirse con la lista de direcciones de origen de Sophos permitidas.
7. Guarde la configuración y complete íntegramente cualquier diálogo externo de consentimiento. Anote el nombre de la integración, el tenant de origen, la persona responsable y la fecha de la próxima rotación de credenciales.
8. Abra Threat Analysis Center > Integrations > Configured. La nueva configuración debe aparecer allí. Desde esta sección puede supervisarla o editarla posteriormente; Connection Method también permite identificar si debe investigarse la ruta de API o la de Log Collector.

FortiAnalyzer: los Alerts de API no son todos los eventos Syslog recibidos

Para Fortinet FortiAnalyzer, el conector de API admite Appliance y VM Subscription, no FortiAnalyzer Cloud. Solo lee Alerts generados por FortiAnalyzer desde /eventmgmt/adom/<ADOM>/alerts; <ADOM> identifica el dominio administrativo correspondiente del sistema de origen. Un evento Syslog que FortiAnalyzer únicamente haya recibido no se convierte automáticamente en uno de estos Alerts. Si se necesita ingerir eventos Syslog, se evalúa en su lugar la integración de Log Collector de FortiAnalyzer o la integración de Fortinet Fortigate para la fuente concreta. Esta decisión se toma antes de configurar el conector, no cuando aparece una supuesta laguna de datos.

El conector de API elimina los datos que no se ajustan al formato y descarta después determinados tipos de Alert: mensajes de túneles VPN (vpntunnel), solicitudes web bloqueadas a destinos sin clasificar, mensajes de escaneo de IP/puertos, conexiones excluidas de la inspección SSL por una lista permitida o una dirección, mensajes de Link Monitor sobre interfaces desactivadas o activadas, advertencias de Memory Log lleno, Alerts y Warnings de cuota de disco y conexiones SSL inseguras bloqueadas. Por tanto, la ausencia de uno de estos Alerts no implica automáticamente un error de autenticación o transporte. La asignación de tipos utiliza una comparación de patrones cuando message no está vacío; en caso contrario, utiliza los campos FTNTFGTattack, ad.subtype y cat; si no hay coincidencias, se depura el campo message. El título de un Alert recibido no constituye automáticamente una asignación MITRE completa.

Para la aceptación, elija un evento inocuo y autorizado que genere de forma demostrable un Alert de FortiAnalyzer, por ejemplo, un cambio de configuración previsto para ello en su propio Event Handler. Primero, documente el Alert, el ADOM y la fecha y hora en FortiAnalyzer, y asegúrese de que no se descarten el formato ni el tipo de Alert. Después, demuestre la presencia del mismo Alert en el tenant correcto mediante la vía de búsqueda de Sophos confirmada para este conector. Un inicio de sesión de prueba cualquiera o una línea Syslog enviada sin un Alert de FortiAnalyzer no constituyen una prueba válida de ingesta mediante API. Si falta el Alert esperado, compruebe primero su generación, el ADOM, el formato y los filtros de tipos; después, las credenciales y la conexión. Incluso con una ingesta correcta, no se garantiza una Detection de Sophos ni un Case.

Comprobar y probar el funcionamiento

Guardar una configuración no demuestra que funcione. Compruebe sucesivamente la conexión, el flujo de datos y el contenido:

1. Estado de conexión: abra la entrada en Configured o, en el caso de una appliance, su estado. Para Log Collectors, el color rojo indica que la integración no funciona, el amarillo que funciona con errores y el verde que recibe y procesa eventos sin problemas visibles.
2. Evento de prueba definido: genere en el sistema de origen un evento inofensivo que la API o categoría Syslog correspondiente vaya a registrar con seguridad, como un cambio administrativo o un inicio de sesión de prueba. Anote la hora, el usuario y el origen.
3. Prueba en Data Lake: después del retraso específico del producto, busque en Threat Analysis Center > Live Discover. Utilice la categoría o consulta de Live Discover documentada en la guía específica del producto; si Sophos no documenta ninguna para el conector, este flujo general no debe prometer una prueba universal mediante consultas. El runbook de Live Discover explica la consulta, los límites de Data Lake y la comprobación de resultados. Verifique la marca de tiempo, el tenant, el usuario y el tipo de evento. Un único registro demuestra la conexión; varios registros recientes durante un periodo adecuado confirman que el flujo de datos continúa.
4. Límite de detección: no todos los eventos ingeridos generan una Detection o un Case. Data Ingest hace que los datos puedan analizarse; solo se producen Detections cuando se activa una lógica de detección adecuada. Por tanto, pruebe primero la ingesta en Data Lake y no espere necesariamente un Alert.
5. Response Action: utilice una cuenta de prueba autorizada y documente el estado inicial. En Microsoft 365, Block user sign-in seguido de Allow user sign-in sirve como prueba reversible; Revoke all current sessions no es reversible. Tenga también en cuenta que Entra Connect Sync puede reactivar posteriormente una cuenta híbrida bloqueada, que la configuración de respuesta de MDR limita las acciones de los analistas de Sophos y que los nombres de algunas Inbox Rules distinguen entre mayúsculas y minúsculas en las Response Actions.

Las Health Alerts no son una prueba inmediata. El periodo de 24 horas comienza con el primer mensaje de error y solo genera un Alert de Severity media si el error persiste ininterrumpidamente. Un estado verde o la confirmación del Alert reinician la cuenta atrás. Si el problema persiste, el Alert vuelve a aparecer después una vez cada 30 días.

Microsoft 365: tres integraciones separadas

«Conectar Microsoft 365» no es un único interruptor. La siguiente tabla describe las tareas separadas de Marketplace en Classic/TAC, incluido el límite de Response Actions de esa ruta. Para la solución ampliada se aplica el procedimiento de acciones de Microsoft Graph API descrito anteriormente, con conexiones propias y un nuevo consentimiento; la limitación de Classic a un único entorno no es un límite de este nuevo procedimiento.

Para Response Actions en la ruta Classic/TAC, Sophos indica los permisos de Microsoft Graph User.ManageIdentities.All, User.EnableDisableAccount.All, User.RevokeSessions.All, MailboxSettings.Readwrite y User.Read. En MDR, la opción de respuesta MDR seleccionada sigue determinando si los analistas pueden actuar sin autorización. En un entorno híbrido de Entra ID, Microsoft Entra Connect Sync puede reactivar posteriormente un inicio de sesión bloqueado desde Central.

Ejemplo: conectar Management Activity de forma segura

1. Asegúrese de que la auditoría esté activa en Microsoft 365. Un administrador de Microsoft 365 debe autorizar la conexión.
2. Abra Threat Analysis Center > Integrations > Marketplace y seleccione Microsoft - Office 365 Management Activity API.
3. En Data Ingest (Security Alerts), haga clic en Add Configuration.
4. Revise el aviso sobre auditoría, haga clic en Save and continue y después, en Connect to Microsoft 365, en Proceed.
5. Inicie sesión con la cuenta de administrador de Microsoft prevista, revise los permisos solicitados y confirme mediante Accept. Finalice la confirmación con Close.
6. Compruebe la entrada en Sophos Fusion. En Live Discover > Query debe aparecer la categoría Microsoft 365 audit data. A continuación, genere un evento de auditoría identificable y búsquelo con una consulta proporcionada.

Microsoft no garantiza un plazo fijo para que cada evento aparezca en el log de auditoría. Por ello, una fila que tarde en aparecer no implica automáticamente un error de integración. Tras activar la auditoría por primera vez, los datos pueden tardar hasta 12 horas en mostrarse.

En el caso de Graph Security V2, la primera sincronización se realiza unos cinco minutos después de que los datos estén disponibles en Microsoft Defender Security Center. Si antes debe aprovisionarse el servicio de Alerts and Incidents, este paso de Microsoft puede tardar por sí solo alrededor de una hora.

Desactivar o retirar una integración

No existe un interruptor Disable uniforme para todos los tipos de integración. Las acciones disponibles varían según el producto y el Connection Method. No presuponga que existe un botón universal:

1. Abra Threat Analysis Center > Integrations > Configured, seleccione la configuración y documente el estado, el nombre, el tenant de origen, la appliance y la credencial.
2. En una integración de API, detenga primero la ingesta de datos de forma controlada o utilice la acción Disable o Delete, si la página del producto concreto la ofrece. Después, revoque en el sistema de origen el consentimiento OAuth o desactive la aplicación o el token dedicados. Para Response Actions, este paso impide realizar más acciones desde Central.
3. En una integración de Log Collector, elimine la configuración de destino Syslog en el sistema de origen. No borre una Sophos appliance compartida mientras la utilicen otras integraciones.
4. Elimine la configuración de Central solo después de cumplir los requisitos de conservación, auditoría y control de cambios. Retirar una configuración no garantiza que también se borren los datos ya ingeridos en Data Lake; por tanto, aclare de antemano la conservación y eliminación conforme a las normas de Data Lake y cumplimiento aplicables al tenant.
5. Compruebe que no llegan eventos nuevos y que no pueden ejecutarse Response Actions inesperadas. Después, retire los secretos, certificados, cuentas de servicio y entradas de listas permitidas que ya no sean necesarios.

Para una interrupción breve por mantenimiento de una integración de Log Collector, detenga la exportación Syslog sin eliminar una appliance compartida. En las integraciones de API y Response, solo debe bloquear una credencial como pausa de mantenimiento si se ha probado previamente, de forma demostrable, la reactivación de la misma configuración; de lo contrario, utilice exclusivamente el procedimiento de Disable, Delete o Reconnect disponible para el conector. Una credencial bloqueada o caducada no es una reversión universal y provoca errores de sincronización.

Acotar sistemáticamente los errores habituales

La integración de API no se sincroniza

Abra Configured, compruebe Connection Method y lea el error concreto. Corrija primero en el producto de terceros Invalid credentials, insufficient permission y expired credentials: compruebe ID, secreto, vigencia del token, certificado y permisos de API. Network not reachable e invalid domain exigen además comprobar DNS, proxy, firewall y estado del servicio. Con request throttling, el proveedor ha limitado la API; guardar repetidamente de inmediato puede empeorar el problema. En Microsoft, HTTP 401 indica autenticación no válida; 429 y 509 indican limitación.

Log Collector permanece en rojo o amarillo

El rojo indica una interrupción; el amarillo, funcionamiento con errores. Compruebe los recursos de la VM, la red y DNS, la conectividad saliente y la ruta Syslog entre el sistema de origen y la appliance. El mensaje no events received since last container restart indica que no se han recibido eventos Syslog desde el inicio del contenedor; no received events in last 10 mins puede deberse a una exportación interrumpida o simplemente a un origen que envía datos con poca frecuencia. Si se produce un error de carga, la appliance almacena temporalmente los datos en disco. Si la carga sigue bloqueada y se llena el almacenamiento, podrían descartarse los datos más antiguos.

Microsoft 365 no proporciona datos

Para Management Activity, deben estar activas la auditoría de Microsoft 365 y la propiedad Enabled for users to sign-in? = Yes en Office 365 Management APIs. Tenga en cuenta el plazo de hasta 12 horas después de activar la auditoría. Para Graph Security V2, compruebe el acceso a Defender XDR, el consentimiento, el aprovisionamiento del servicio de Alerts y el alcance disponible de la licencia de Microsoft. La antigua Graph Security API ya no es una alternativa.

No aparece ninguna Health Alert pese a la interrupción

Compruebe primero si se trata de una integración de Data Ingest y si han transcurrido 24 horas ininterrumpidas desde el primer mensaje de error. Un estado verde intermedio o la confirmación del Alert reinician la cuenta atrás. De forma predeterminada, todos los administradores de Central reciben el correo electrónico; las Notification Rules personalizadas pueden cambiar esta distribución.

Reglas de seguridad y operación

• Utilice aplicaciones y secretos dedicados en lugar de accesos personales de administrador.
• Conceda únicamente los permisos de API que exige la integración concreta. Por su naturaleza, las integraciones de respuesta necesitan permisos de escritura y requieren una autorización más estricta que una simple ingesta de datos.
• No guarde secretos en tickets, capturas de pantalla o artículos de la KB. Registre el propietario y la fecha de caducidad en el sistema de gestión de contraseñas o secretos.
• Planifique la rotación de credenciales antes de que caduquen. Sophos informa de las credenciales caducadas como errores de sincronización.
• Autorice direcciones IP de Sophos solo cuando el proveedor exija una lista de orígenes permitidos y utilice la lista de la región de Central real.
• Active las notificaciones de estado para un equipo responsable. Al crear una Custom Notification Rule, tenga en cuenta que se desactiva el envío predeterminado de todos los Alerts por correo electrónico a todos los administradores, por lo que deberá reproducir por separado las reglas necesarias.
• Documente para cada integración el origen de datos, la finalidad, la clasificación de datos, la conservación, los permisos, la prueba, el Owner y la vía de retirada.

Criterios de aceptación

La integración solo está completa cuando aparece en Configured con el método esperado, puede demostrarse un evento de prueba definido en el destino previsto, coinciden la marca de tiempo y el tenant de origen, y un Owner se responsabiliza de la rotación de credenciales y de las Health Alerts. Para Response Actions, la aceptación también requiere una prueba autorizada y documentada; solo las acciones reversibles deben volver al estado inicial, y las acciones irreversibles, como la revocación de sesiones, no pueden utilizarse como prueba de reversión. Registre en el protocolo operativo los retrasos inevitables, como los de la auditoría de Microsoft 365.

Preguntas frecuentes

¿Todas las integraciones envían datos a Sophos Data Lake?

No. Data Ingest envía datos a Data Lake. Response Action permite ejecutar una acción en el producto de terceros. Algunos productos solo ofrecen un tipo; otros proporcionan configuraciones separadas para ambos sentidos.

¿Son gratuitas las integraciones de terceros con XDR?

No de forma general. Para MSP Flex, Sophos indica determinadas integraciones de la categoría Sophos XDR que pueden utilizarse con XDR sin un Integration License Pack adicional. Otras categorías requieren los packs correspondientes en Flex. Además, podrían ser necesarias licencias del proveedor externo.

¿Por qué veo datos, pero ninguna Detection?

La ingesta y la detección son fases diferentes. Un conector de Data Ingest puede escribir eventos correctamente en Data Lake sin que cada uno genere una Sophos Detection o un Case. Compruebe primero el flujo de datos original mediante la consulta de Live Discover prevista.

¿Puedo utilizar la misma appliance para varias integraciones Syslog?

Sí, en la ruta Classic SVA, Sophos permite varias integraciones de terceros y una integración de Sophos NDR en la misma appliance. Aun así, cada origen debe configurarse con los datos correctos de conexión y formato. En cambio, el nuevo XDR Data Collector sustituye Syslog y no asume ni aloja esta carga de trabajo NDR. Para la transición se aplica el procedimiento de migración del Collector enlazado anteriormente; NDR se opera por separado conforme al runbook operativo de NDR.

¿Por qué no basta la integración de respuesta de Microsoft 365?

Proporciona acciones, pero no ingiere automáticamente datos de auditoría ni Alerts de Defender. Añada Microsoft 365 Management Activity y Microsoft Graph Security API V2 para disponer de Detections y contexto de investigación.

¿Al retirar una integración se eliminan los datos históricos de Data Lake?

La retirada no garantiza la eliminación inmediata de los datos ya ingeridos. Trate la retirada como una detención del futuro flujo de datos y aclare por separado la conservación o las obligaciones de eliminación antes de comprometer una fecha concreta.