Activar y verificar MDR Threat Feeds en Sophos Firewall

MDR Threat Feeds conecta el servicio Sophos MDR con Sophos Firewall. Los analistas de MDR pueden enviar al firewall, a través de Sophos Fusion (antes Sophos Central), direcciones IPv4, dominios y URL relacionados con un incidente activo en el propio entorno. El firewall registra o bloquea después el tráfico coincidente sin tener que mantener manualmente un archivo de feed propio.

Una implantación segura requiere más que activar un interruptor en WebAdmin. La licencia MDR, el registro en Sophos Fusion, la acción local, la visibilidad de tráfico necesaria, los destinos de log y la vía de contacto con el equipo MDR deben estar coordinados. Un estado local Log and drop todavía no demuestra que haya llegado un IoC concreto ni que el flujo de datos afectado pase por las inspecciones necesarias.

Nombres en la interfaz: Las rutas de Sophos Fusion utilizadas aquí siguen la ayuda de SFOS 22. La ayuda de SFOS 23 sigue utilizando Sophos Central para la misma conexión con la nube. Si la compilación instalada muestra ese nombre, se debe abrir la página correspondiente de Sophos Central; el nombre por sí solo no indica nada sobre el registro, la habilitación de MDR o la entrega de feeds. Send reports and logs to Sophos Central sigue siendo el nombre documentado de la opción de registro de logs.

MDR Threat Feeds en ocho pasos

1. Comprobar que el firewall tenga el Xstream Protection Bundle y que Sophos Fusion disponga de una habilitación de MDR activa.
2. En System > Sophos Fusion, confirmar que el firewall correcto esté registrado en la cuenta Sophos Fusion correcta.
3. Documentar en Sophos Fusion el Threat response mode previsto y la vía operativa de contacto con MDR.
4. En System services > Log settings, activar al menos un destino de log utilizable para Active threat response.
5. Abrir Protect > Active threat response > MDR threat feeds y activar la función.
6. Elegir Log only para un piloto breve y controlado o Log and drop para la protección en producción después de una validación satisfactoria, y hacer clic en Apply.
7. Realizar las comprobaciones positiva y negativa mediante Log Viewer, el contexto del endpoint y Sophos Fusion.
8. Documentar Audit ID, responsables, proceso de excepciones, fecha de revisión y procedimiento de reversión.

Importante: MDR Threat Feeds es solo una parte de la operación de MDR. No sustituye al contrato MDR, a los sensores de endpoint, a la comunicación de incidentes, a las reglas de firewall restrictivas ni a un procedimiento de recuperación probado. Una excepción amplia o una desactivación sin control puede debilitar una respuesta en curso del equipo MDR.

Qué ofrece MDR Threat Feeds

Los analistas de Sophos MDR pueden enviar al firewall inteligencia sobre un incidente activo directamente a través de Sophos Fusion. Por ello, el feed está más adaptado al cliente que una lista general de reputación global. Un IoC enviado puede ser una dirección IPv4, un dominio o una URL.

La acción local del firewall determina qué ocurre cuando se detecta una coincidencia:

• Log only registra la coincidencia, pero permite el tráfico.
• Log and drop registra y descarta el tráfico coincidente.

Sophos recomienda bloquear los IoC conocidos. Aun así, un piloto breve con Log only puede ser útil si primero es necesario comprobar la visibilidad, el registro de logs y los posibles efectos secundarios en un entorno existente. Este piloto necesita una fecha de finalización definida. Sin una transición planificada, una integración MDR activa puede permanecer indefinidamente sin bloqueo local.

El Threat response mode de Sophos Fusion y la acción local del feed son dos niveles distintos. El modo de Sophos Fusion establece qué facultades de respuesta tiene el equipo MDR. Log only o Log and drop determina cómo trata el firewall un IoC que ya se ha enviado. Antes de la implantación, ambas configuraciones se contrastan con el contrato MDR y con el proceso interno de gestión de incidentes. La documentación actual de Sophos sobre Threat response mode distingue entre Collaborate, Authorize y Notify Only.

Distinguir la telemetría del firewall de la respuesta de los analistas

Los datos también fluyen en sentido contrario: el firewall proporciona eventos de seguridad para la investigación de MDR. Para ello, debe estar registrado en Sophos Central firewall management; en el firewall deben estar activados Sophos Central services y seleccionada la opción Send reports and logs to Sophos Central. MDR analiza continuamente los logs de seguridad de Advanced Threat Protection (ATP), Intrusion Detection and Prevention (IDP/IPS), Antivirus, Antispam, Sandstorm Sandbox, Web Protection y Application Control. Junto con los datos de endpoints, servidores y otras fuentes integradas, estos eventos ayudan a identificar actividad maliciosa, IoC e intentos de movimiento lateral. Sin embargo, la telemetría entrante del firewall no es el feed de IoC específico del cliente que los analistas de MDR envían de vuelta al firewall.

Ante un incidente crítico, el equipo MDR puede, por ejemplo, finalizar las sesiones VPN de usuarios comprometidos. Se trata de una medida de respuesta a incidentes de los analistas dentro de las facultades concedidas, no de una consecuencia automática de una coincidencia del feed ni de un procedimiento local de clics o comandos CLI. Con Authorize, el equipo puede responder a amenazas activas sin consultar previamente a los contactos designados; con Collaborate, la respuesta se coordina con esos contactos. Esto no implica facultades de respuesta ilimitadas para todos los dispositivos o integraciones. No se finalizan sesiones VPN de producción como prueba funcional.

Para intervenir mediante Live Response, Live Response debe estar permitido en el dispositivo afectado. Aislar Sophos Endpoint e investigar con Live Response explica los requisitos y el procedimiento seguro. Las acciones de Microsoft 365, como bloquear o permitir inicios de sesión, revocar sesiones activas y desactivar Inbox Rules, requieren que la integración de respuesta esté configurada; se aplica el procedimiento independiente de Integraciones de MDR y XDR. El registro de logs del firewall o la entrega de un IoC de MDR no habilitan automáticamente estas intervenciones.

En cambio, los cybora.io Threat Feeds que Avanet utiliza para Sophos Firewall son Third-Party Threat Feeds, no Sophos MDR Threat Feeds ni feeds de MDR creados por Avanet. Su configuración sigue el procedimiento para feeds de terceros; no concede al equipo Sophos MDR facultades de respuesta adicionales.

Comprender el orden y el ciclo de vida

SFOS 22 procesa Active Threat Response en el orden MDR, NDR Essentials, Sophos X-Ops y Third-Party Threat Feeds. Si un IoC coincide en MDR con Log and drop, el firewall descarta el tráfico, lo registra bajo MDR y ya no comprueba los feeds posteriores. Con Log only o Monitor, pueden generarse eventos independientes para MDR, X-Ops y Third-Party Feeds. Una coincidencia de MDR con Log and drop detiene la comprobación de los feeds posteriores. Con Log only o acciones mixtas entre módulos, no se debe deducir una autorización general; deben revisarse las otras acciones configuradas y las evidencias de tráfico y logs.

Los IoC individuales de MDR no se crean ni se editan en WebAdmin. Los analistas de MDR los añaden y los eliminan a través de Sophos Fusion. Ambas operaciones se registran con la acción y la identidad del analista mediante audit_ID. Estos eventos administrativos se buscan en la vista de detalles Admin de Log Viewer o en Sophos Fusion Firewall Task Queue; no deben confundirse con las coincidencias de tráfico de Active threat response. Localmente solo se controla si el feed MDR está activo y si las coincidencias se registran o, además, se descartan. En cambio, las Threat Exclusions son globales y se aplican a todos los módulos de Active Threat Response.

La documentación de SFOS 22 no indica ningún periodo de validez de los IoC de MDR que pueda configurar el administrador del firewall. Por tanto, no se debe deducir una fecha de caducidad a partir de la interfaz local. Si una entrada resulta dudosa o puede estar obsoleta, se guardan audit_ID, el IoC y la fecha y hora, y se aclara su estado con el equipo MDR. Esto también es importante para la reversión: cambiar de Log and drop a Log only afecta a todos los IoC de MDR suministrados en ese momento; una Threat Exclusion puede debilitar además NDR, X-Ops y Third-Party Feeds.

Comprobar los requisitos de forma rigurosa

Licencia y Sophos Fusion

MDR Threat Feeds requiere el Xstream Protection Bundle en el firewall. La tabla de licencias de SFOS 22 indica, además, Sophos MDR Essentials o Sophos MDR Complete en Sophos Fusion; la documentación actual de Sophos Fusion denomina las modalidades del servicio MDR y MDR Plus. Por ello, se comprueba la habilitación de MDR activa en la propia cuenta de Sophos Fusion, en lugar de deducirla únicamente a partir de un nombre de producto antiguo. El paquete Xstream por sí solo no incluye ningún servicio MDR.

El firewall debe estar registrado en la cuenta Sophos Fusion correcta. En System > Sophos Fusion se comprueban el registro y el envío de informes y logs. El procedimiento completo de conexión se explica en Conectar Sophos Firewall con Sophos Fusion.

Además, el servicio Sophos MDR debe estar configurado. El registro del firewall y la comprobación de la licencia por sí solos no sustituyen esta configuración. Antes de activar la función localmente, se confirma con el responsable de MDR que el servicio esté configurado para el cliente correcto y que Threat response mode se haya establecido de forma deliberada. Sophos exige al menos un contacto autorizado antes de poder configurar otros ajustes de MDR o utilizar el servicio. Para el contexto adicional del endpoint mediante Synchronized Security, la tabla de licencias de SFOS 22 también indica una licencia Intercept X en Sophos Fusion; el paquete Xstream por sí solo no garantiza este contexto.

Sophos MDR: configurar contactos y Threat Response describe el procedimiento central completo, con roles de contacto, alternativa de Collaborate, acceso a dispositivos y comprobación segura de los valores guardados. No sustituye la posterior configuración local del feed.

Antes de la activación, también deben aclararse las responsabilidades:

• ¿Quién puede cambiar Threat response mode en Sophos Fusion?
• ¿Quién atiende una llamada o una consulta de MDR fuera del horario de oficina?
• ¿Quién puede aprobar una excepción?
• ¿Dónde se documentan Audit ID, Incident ID y las evidencias técnicas?
• ¿Qué sistemas pueden aislarse si se confirma que están comprometidos?

Activar los destinos de log

En System services > Log settings, se activa al menos uno de estos destinos en la fila Active threat response:

• Local reporting para Log Viewer e informes locales
• un Syslog server configurado para el SIEM o el SOC
• Central reporting para Sophos Fusion

La columna Central reporting solo aparece cuando se ha activado Send reports and logs to Sophos Central en la página de Sophos Fusion. XGS 87/87w y 107/107w no admiten informes locales; en esos modelos se necesita Central Reporting o Syslog.

Después de seleccionar los destinos de log en System services > Log settings, hacer clic en Apply. A continuación, volver a cargar la página y comprobar que los destinos previstos sigan seleccionados en la fila Active threat response. Esto confirma que la configuración se ha guardado; el transporte real de los logs y la entrega de las notificaciones de incidentes se comprueban por separado.

Para las notificaciones, también se revisa System services > Notification list. Activar un destino de log define la vía de transporte, pero no demuestra ni la entrega real ni la correcta gestión de las alertas.

Visibilidad de IP, dominio y URL

Un IoC solo tiene efecto sobre el tráfico que el firewall puede procesar de la forma adecuada. Para el tráfico reenviado con coincidencia de IP de destino, se necesita una regla de firewall adecuada. Las coincidencias de dominio requieren Application Classification o una política IPS en la regla correspondiente. Para una ruta URL HTTPS completa, se necesita Web Proxy con descifrado o DPI con una regla SSL/TLS Inspection adecuada.

El tráfico dirigido al propio sistema para los servicios de Administration > Device access, como WebAdmin, VPN Portal y VPN, puede inspeccionarse a partir de una dirección IPv4 de origen maliciosa. Para que el tráfico entrante reenviado mediante DNAT o WAF tenga la visibilidad esperada en los logs, también debe activarse Remote source match (inbound traffic) en System services > Log settings > Active threat response.

Limitación pendiente de aclaración en ATR/X-Ops: La descripción oficial y la matriz de tráfico se contradicen respecto a las coincidencias de dirección de destino y de dirección de origen local para Sophos X-Ops. En estos casos, no se ha aclarado de forma fiable ni su compatibilidad ni su exclusión; la información enlazada sobre tráfico y módulos no constituye una base de configuración validada para ellos. No se deduce de ello ninguna dirección de tráfico de MDR ni se presupone protección para los casos de X-Ops afectados. Antes de realizar un cambio basado en esos supuestos, se necesita una aclaración vinculante de Sophos o una prueba del producto expresamente autorizada; los enlaces siguientes no resuelven esta contradicción.

La lógica general de tráfico, módulos e inspección se describe en Configurar y operar de forma segura Threat Feeds en Sophos Firewall. Allí también se explica por qué puede no producirse una detección de dominio o URL si falta la clasificación o el descifrado adecuado.

Configurar MDR Threat Feeds

1. Iniciar sesión en WebAdmin con una cuenta personal de administrador.
2. Abrir Protect > Active threat response > MDR threat feeds.
3. Activar MDR threat feeds.
4. En Action, seleccionar Log only para un piloto con fecha de finalización definida o Log and drop después de una validación satisfactoria.
5. Guardar con Apply.
6. Volver a cargar la página y comprobar que el estado del interruptor y Action se hayan guardado.
7. Revisar la marca de tiempo, el administrador y el cambio en Audit Trail.
8. Comprobar en Sophos Fusion que el firewall esté en línea y que MDR esté asignado al cliente o tenant correcto.

No realizar cambios amplios de registro de logs, inspección, excepciones y Action al mismo tiempo. Una implantación por etapas permite identificar qué cambio ha causado una coincidencia o un efecto secundario.

Validar la eficacia con evidencias fiables

La ayuda de MDR revisada aquí no indica ningún indicador general e inocuo para probar MDR. Por tanto, acceder a un dominio de malware real o a una IP maliciosa conocida no es una validación adecuada. La comprobación técnica se divide en varios niveles que pueden demostrarse por separado. Una prueba propia de Third-Party solo acredita la ruta de tráfico e inspección comprobada, no la entrega de un IoC de MDR por parte del equipo de analistas.

Configuración y transporte

1. Comprobar el interruptor de MDR y la Action deseada en el firewall.
2. Revisar el registro en Sophos Fusion y la licencia MDR.
3. Confirmar el registro de logs de Active Threat Response para el destino previsto.
4. Comprobar en Sophos Fusion si las tareas de MDR o del firewall se han procesado correctamente.
5. En un incidente MDR real, contrastar con el equipo MDR el IoC esperado y su Audit ID correspondiente.

Sophos Fusion Firewall Task Queue muestra las tareas de MDR y de API. Success confirma el procesamiento de la tarea de Sophos Fusion, pero todavía no su efecto sobre un flujo de datos concreto. Con Partial Success o Failed, se guardan el firewall afectado, Entity, Action y Credential ID, y se comparan con la configuración local.

Investigar las coincidencias en Log Viewer

En Log viewer > Active threat response, se guarda como mínimo esta información:

• Marca de tiempo, firewall y, en HA, el nodo que procesó el tráfico
• Action y nombre del feed
• IP de origen y de destino, dominio o URL
• Puertos y protocolo
• Event ID y otros campos de detalle
• Para MDR, también el audit_ID correspondiente del evento administrativo o de Task Queue

La evidencia de tráfico y la acción del analista son pruebas independientes. La ausencia de un campo audit_ID en la entrada de tráfico no constituye por sí sola un error de entrega. La vinculación se establece a partir del IoC, el firewall y el intervalo de tiempo, y se confirma con MDR si hay dudas.

Con Synchronized Security, el firewall también puede mostrar el usuario, el host y el proceso de los endpoints Windows gestionados. En Log Viewer, son relevantes Process user y Executable, así como host_process_user, endpoint_id y execution_path en la vista de detalles. En macOS no aparecen estos detalles de proceso; el endpoint se identifica mediante la IP de origen y los datos de Sophos Fusion.

Cuando se produce una detección, el firewall solicita estos detalles a los endpoints gestionados a través de Sophos Fusion. La ayuda describe su visualización para Windows 7 y versiones posteriores; esto no es una recomendación de Windows 7 ni una garantía de compatibilidad actual del endpoint con todos los sistemas Windows antiguos. En macOS puede aparecer en su lugar un mensaje genérico como Active threat C2/Generic-C deleted. Este mensaje no sustituye ni la identificación del host mediante la IP de origen ni la evidencia de qué acción del firewall se aplicó al tráfico.

El resumen local se encuentra en Reports > Network & threats > Active threat response, en la lista Synchronized IoC. La Descripción general de los servicios y archivos de log de Sophos Firewall también explica la función de atr.log. Una entrada de log nunca se evalúa de forma aislada: los eventos de firewall, DNS, web, IPS, endpoint y Sophos Fusion del mismo intervalo de tiempo deben analizarse conjuntamente.

Comprobaciones positiva y negativa

Un piloto en producción debe incluir como mínimo estos dos casos:

1. Positivo: Ante un IoC o incidente real confirmado por el equipo MDR, se guardan por separado una entrada de tráfico trazable con la Action correcta y la acción del analista correspondiente con Audit ID, y se contrastan entre sí. Para ello no se genera tráfico adicional hacia infraestructura maliciosa.
2. Negativo: Un proceso de negocio legítimo comparable sigue siendo accesible y no genera un bloqueo MDR involuntario.

Sin un incidente real, no se crea artificialmente un IoC de MDR. En su lugar, se comprueban la configuración, el procesamiento de tareas, el transporte de logs y la vía de comunicación. Para una prueba de tráfico totalmente controlable, resulta más adecuado un feed piloto propio de Third-Party que un destino malicioso ajeno.

Tratar una coincidencia de MDR como un incidente

Una coincidencia de MDR es una señal importante, pero la entrada de log por sí sola no explica toda la ruta del ataque. Un procedimiento ordenado es el siguiente:

1. Guardar la fecha y hora, Action, IoC, nombre del feed, Event ID y audit_ID.
2. Identificar el host y el usuario afectados mediante la IP de origen, DHCP, Synchronized Security y los datos del endpoint.
3. Abrir en Sophos Fusion el caso MDR correspondiente, la detección y otros eventos del dispositivo.
4. Correlacionar los logs de firewall, DNS, web, IPS y endpoint del mismo intervalo de tiempo.
5. Aclarar con el equipo MDR por qué se añadió el IoC y qué respuesta está prevista.
6. Si se confirma que el sistema está comprometido, activar el procedimiento interno de respuesta a incidentes.
7. Solo después, decidir sobre la limpieza, reglas adicionales o una excepción limitada.

Audit ID identifica la acción del analista de MDR. En Log Viewer, hacer clic primero en el botón de la vista de detalles y, a continuación, seleccionar Admin en el menú desplegable. Allí se guardan la acción y el audit_ID de la adición o eliminación. Como alternativa, la acción del analista se encuentra en My Products > Firewall management > Tasks Queue en Sophos Fusion. Al consultar a MDR, se debe incluir en el caso Audit ID junto con el número de serie del firewall, la fecha y hora, el IoC, Event ID e Incident ID. Una eliminación registrada acredita una acción administrativa, no la limpieza del endpoint afectado.

Gestionar las excepciones de forma controlada

En Protect > Active threat response > Add threat exclusions se pueden crear excepciones de host/red y de amenazas. Estas excepciones se aplican a todos los módulos. Por tanto, una excepción para una coincidencia de MDR también puede debilitar X-Ops, NDR o Third-Party Threat Feeds.

Antes de crear una excepción, se documentan el IoC, el proceso de negocio afectado, el caso MDR y la confirmación del falso positivo. La excepción se mantiene lo más limitada posible y se le asignan un motivo, un responsable, un ticket y una fecha de revisión o caducidad. Excluir redes de clientes completas o rangos amplios de dominios no es una solución rápida adecuada.

Las configuraciones de Threat Feeds no se pueden importar ni exportar por separado; las Threat Exclusions, en cambio, sí. Los ajustes del feed MDR tampoco pueden incorporarse mediante Import existing configuration a la configuración inicial de un nuevo grupo de firewalls de Sophos Fusion. Por ello, después de una migración, restauración o sustitución, se vuelven a comprobar explícitamente la función, Action, el registro de logs y la asignación en Sophos Fusion.

Si no aparece ninguna coincidencia de MDR

La comprobación no empieza reiniciando un servicio. Primero se analizan los niveles por separado:

1. ¿Son correctos la licencia MDR, la cuenta Sophos Fusion, el registro del firewall y Threat response mode?
2. ¿Está MDR Threat Feeds activo localmente y se ha guardado Action?
3. ¿Ha enviado realmente el equipo MDR el IoC en cuestión para este entorno?
4. ¿Muestra Sophos Fusion Firewall Task Queue Success, Partial Success, Failed o todavía Pending?
5. ¿Están activados los logs de Active Threat Response localmente, hacia Syslog o en Sophos Fusion?
6. ¿Pasa el tráfico por el firewall, la regla y la inspección previstos?
7. ¿Está el IoC incluido en excepciones de Active Threat Response, web o SSL/TLS?
8. ¿Son correctos el intervalo de tiempo y, en HA, el nodo examinado?

Para comprobar el estado del motor y del feed, se puede correlacionar temporalmente atr.log con Log Viewer y Sophos Fusion Firewall Task Queue. Los logs solo se leen; los cambios no documentados en datos de feeds, bases de datos o servicios no forman parte del procedimiento estándar. Si la causa sigue sin aclararse, se guardan CTR, los logs relevantes, Task ID, Audit ID, la compilación y la fecha y hora para Sophos MDR o Sophos Support.

Reversión y control de cambios

Antes de la activación, se documentan el estado anterior del interruptor, Action, los destinos de log y las excepciones existentes. Si se produce una afectación inesperada del negocio, no se crea inmediatamente una excepción amplia.

1. Guardar la coincidencia afectada y el impacto en el negocio.
2. Informar al equipo MDR mediante Audit ID y el incidente.
3. Si se cuenta con la autorización correspondiente, cambiar temporalmente la Action local de Log and drop a Log only.
4. Solo si eso tampoco basta y MDR está de acuerdo, devolver el feed de forma controlada al estado anterior documentado.
5. Después de cada cambio, volver a comprobar el mismo proceso de negocio y el efecto en los logs.
6. Resolver la causa y restablecer la protección en producción con una nueva fecha de revisión.

En entornos HA, se comprueban la configuración y el estado en el Primary actual. Los logs se encuentran en el nodo que procesó el tráfico. Después de una conmutación por error controlada, se vuelven a validar la conexión con Sophos Fusion, el estado del feed, las nuevas entradas de log y el tráfico real; no se presupone una continuidad sin interrupciones de MDR ni de los logs.

Lista de comprobación

• Xstream Protection Bundle activo
• Habilitación de MDR activa disponible en Sophos Fusion
• Firewall registrado en la cuenta Sophos Fusion correcta
• Threat response mode y vía de contacto con MDR documentados
• Destino de log de Active Threat Response activado
• MDR Threat Feeds activado
• Action elegida de forma deliberada y piloto con fecha de finalización definida
• Visibilidad del tráfico de IPv4, dominio y URL comprobada
• Remote source match activado para DNAT/WAF cuando sea necesario
• Task Queue y estado local comparados
• Audit ID y proceso de gestión de incidentes conocidos
• Contexto del endpoint y limitaciones de las plataformas comprobados
• Excepciones con responsable y fecha de revisión
• Procedimiento de reversión y comprobación de HA documentados

Preguntas frecuentes