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 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.

Una implantación segura requiere más que activar un interruptor en WebAdmin. La licencia MDR, el registro en Central, 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 afectado pase por las inspecciones necesarias.

MDR Threat Feeds en ocho pasos

1. Comprobar que el firewall tenga activo el Xstream Protection Bundle y que Sophos Central disponga de Sophos MDR Essentials o Sophos MDR Complete.
2. En System > Sophos Central, confirmar que el firewall correcto esté registrado en la cuenta Central correcta.
3. Documentar en Sophos Central 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 productiva después de una validación correcta, y hacer clic en Apply.
7. Realizar pruebas positivas y negativas mediante Log Viewer, el contexto del endpoint y Sophos Central.
8. Documentar Audit ID, responsables, proceso de excepciones, fecha de revisión y rollback.

Importante: MDR Threat Feeds es solo una parte de la operación MDR. No sustituye el contrato MDR, los sensores de endpoint, la comunicación de incidentes, las reglas de firewall restrictivas ni una vía de recuperación probada. Una excepción amplia o una desactivación sin control puede debilitar una respuesta activa del equipo MDR.

Qué hace MDR Threat Feeds

Los analistas de Sophos MDR pueden enviar directamente al firewall, a través de Sophos Central, inteligencia sobre un incidente activo. Por eso el feed es más específico del cliente que una lista global de reputación. Un IoC enviado puede ser una dirección IPv4, un dominio o una URL.

La acción local del firewall determina qué ocurre cuando hay 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 resultar útil si primero hay que verificar la visibilidad, el registro y posibles efectos secundarios en un entorno existente. El piloto necesita una fecha final fija. Sin una transición planificada, una integración MDR activa podría permanecer indefinidamente sin efecto de bloqueo local.

El Threat response mode de Sophos Central y la acción local del feed son dos niveles distintos. El modo de Central define las facultades de respuesta del equipo MDR. Log only o Log and drop determina cómo trata el firewall un IoC ya enviado. Antes de la implantación, ambos ajustes se contrastan con el contrato MDR y el proceso interno de incidentes.

Verificar correctamente los requisitos

Licencia y Sophos Central

MDR Threat Feeds requiere el Xstream Protection Bundle en el firewall. Además, Sophos Central necesita Sophos MDR Essentials o Sophos MDR Complete. El bundle Xstream por sí solo no incluye un servicio MDR completo.

El firewall debe estar registrado en la cuenta correcta de Sophos Central. En System > Sophos Central se comprueba el registro y el envío de informes y logs. Conectar Sophos Firewall con Sophos Central explica el proceso completo.

Antes de activar la función también deben quedar claras las responsabilidades:

• ¿Quién puede modificar el Threat response mode en Central?
• ¿Quién atiende una llamada o consulta de MDR fuera del horario laboral?
• ¿Quién puede aprobar una excepción?
• ¿Dónde se documentan Audit ID, Incident ID y las pruebas técnicas?
• ¿Qué sistemas se pueden aislar tras confirmar una intrusión?

Activar destinos de log

En System services > Log settings, activar 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 SOC
• Central reporting para Sophos Central

La columna Central reporting solo aparece cuando está activado Send reports and logs to Sophos Central en la página de Sophos Central. Los modelos XGS 87/87w y 107/107w no admiten informes locales, por lo que requieren Central Reporting o Syslog.

Para las notificaciones también se revisa System services > Notification list. Activar un destino de log solo demuestra la ruta de transporte, no la gestión correcta de alertas.

Visibilidad de IP, dominio y URL

Un IoC solo actúa sobre tráfico que el firewall puede procesar de la forma necesaria. El tráfico reenviado hacia una IP de destino requiere una regla de firewall coincidente. Las coincidencias de dominio requieren Application Classification o una política IPS en la regla correspondiente. Para ver una ruta URL HTTPS completa hace falta Web Proxy con descifrado o DPI con una regla SSL/TLS Inspection adecuada.

El tráfico dirigido al sistema hacia servicios de Administration > Device access, como WebAdmin, VPN Portal y VPN, puede comprobarse contra una dirección IPv4 de origen maliciosa. Para tráfico DNAT o WAF entrante y reenviado, también debe activarse Remote source match (inbound traffic) en System services > Log settings > Active threat response para obtener la visibilidad de log esperada.

Configurar y operar de forma segura los Threat Feeds de Sophos Firewall explica la lógica general de tráfico, módulos e inspección. También aclara por qué puede faltar la detección de dominios o URL sin la clasificación o el descifrado adecuados.

Configurar MDR Threat Feeds

1. Iniciar sesión en WebAdmin con una cuenta de administrador personal.
2. Abrir Protect > Active threat response > MDR threat feeds.
3. Activar MDR threat feeds.
4. En Action, elegir Log only para un piloto con plazo definido o Log and drop después de una validación correcta.
5. Guardar con Apply.
6. Recargar la página y comprobar que el interruptor y la acción se hayan guardado.
7. Revisar en Audit Trail la hora, el administrador y el cambio.
8. En Sophos Central, comprobar que el firewall esté en línea y que MDR esté asignado al cliente o tenant correcto.

No modificar a la vez y de forma generalizada el logging, la inspección, las excepciones y la acción. Una implantación por etapas permite identificar qué cambio produjo una coincidencia o un efecto secundario.

Validar el efecto de forma fiable

Sophos no publica un indicador MDR de prueba general e inocuo. Por tanto, llamar 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 varias capas demostrables.

Configuración y transporte

1. Comprobar el interruptor MDR y la acción deseada en el firewall.
2. Verificar el registro en Central y la licencia MDR.
3. Confirmar el logging de Active Threat Response hacia el destino previsto.
4. Comprobar en Central si las tareas MDR o de firewall se procesaron correctamente.
5. En un incidente MDR real, contrastar el IoC esperado y el Audit ID correspondiente con el equipo MDR.

La Sophos Central Firewall Task Queue muestra tareas MDR y API. Success confirma el procesamiento de la tarea en Central, pero no su efecto sobre un flujo 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 una coincidencia en Log Viewer

En Log viewer > Active threat response se guarda al menos esta información:

• marca de tiempo, firewall y, en HA, el nodo que procesó el tráfico
• acción y nombre del feed
• IP de origen y destino, dominio o URL
• puertos y protocolo
• Event ID y otros campos detallados
• la audit_ID para MDR

Con Synchronized Security, el firewall también puede mostrar usuario, host y proceso en endpoints Windows administrados. En Log Viewer son relevantes Process user y Executable, además de host_process_user, endpoint_id y execution_path en la vista detallada. Estos detalles de proceso no aparecen en macOS; allí el endpoint se identifica mediante la IP de origen y los datos de Central.

El resumen local se encuentra en Reports > Network & threats > Active threat response, en la lista Synchronized IoC. La descripción de servicios y archivos de log de Sophos Firewall también explica atr.log. Nunca se evalúa una entrada aislada: se correlacionan los eventos de firewall, DNS, web, IPS, endpoint y Central del mismo intervalo.

Prueba positiva y negativa

Un piloto productivo debe incluir al menos estos dos casos:

1. Positivo: Un IoC o incidente real confirmado por el equipo MDR genera en el firewall esperado una entrada trazable con la acción y Audit ID correctos.
2. Negativo: Un proceso empresarial legítimo comparable sigue accesible y no genera un bloqueo MDR no deseado.

Sin un incidente real no se crea artificialmente un IoC MDR. En su lugar se comprueban configuración, procesamiento de tareas, transporte de logs y vía de comunicación. Para una prueba de tráfico totalmente controlada es más seguro utilizar un feed piloto propio de terceros que un destino malicioso ajeno.

Tratar una coincidencia MDR como incidente

Una coincidencia MDR es una señal fuerte, pero la entrada de log no explica por sí sola toda la ruta del ataque. Un proceso sereno es:

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

El Audit ID identifica la acción del analista MDR. Está visible en la vista detallada Admin de Log Viewer y en My Products > Firewall management > Tasks Queue de Sophos Central. En cualquier consulta a MDR se incluye junto con el número de serie del firewall, la hora, el IoC, Event ID e Incident ID.

Gestionar las excepciones de forma controlada

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

Antes de crear una excepción se documentan el IoC, el proceso empresarial afectado, el caso MDR y la confirmación del falso positivo. La excepción se mantiene lo más restrictiva posible e incluye motivo, responsable, ticket y fecha de revisión o caducidad. Redes de clientes completas o rangos de dominios amplios no son una reparación rápida adecuada.

Las configuraciones de Threat Feeds no se pueden importar o exportar por separado, aunque las Threat Exclusions sí. Los ajustes de MDR tampoco se pueden transferir mediante Import existing configuration a la configuración inicial de un nuevo grupo de firewalls en Central. Después de una migración, restauración o sustitución se vuelven a comprobar expresamente función, acción, logging y asignación en Central.

Cuando no aparece una coincidencia MDR

La comprobación no empieza reiniciando un servicio. Primero se separan las capas:

1. ¿Son correctos la licencia MDR, la cuenta Central, el registro del firewall y el Threat response mode?
2. ¿Está MDR Threat Feeds activo localmente y se guardó la acción?
3. ¿Envió realmente el equipo MDR el IoC correspondiente a este entorno?
4. ¿Muestra Central Task Queue Success, Partial Success, Failed o todavía Pending?
5. ¿Están activados los logs de Active Threat Response localmente, para Syslog o en Central?
6. ¿Pasa el tráfico por el firewall, la regla y la inspección esperados?
7. ¿Está el IoC en una excepción de Active Threat Response, web o SSL/TLS?
8. ¿Coinciden el intervalo y, en HA, el nodo inspeccionado?

Para el estado del motor y del feed, se correlaciona temporalmente atr.log con Log Viewer y Central Task Queue. Los logs solo se leen; los cambios no documentados en datos de feeds, bases de datos o servicios no son un paso estándar. Si la causa sigue abierta, se recopilan CTR, logs relevantes, Task ID, Audit ID, build y hora para Sophos MDR o Sophos Support.

Rollback y control de cambios

Antes de activar, se documentan el estado anterior del interruptor, la acción, los destinos de log y las excepciones existentes. Ante un impacto empresarial inesperado no se crea inmediatamente una excepción amplia.

1. Guardar la coincidencia afectada y el impacto empresarial.
2. Informar al equipo MDR mediante Audit ID e incidente.
3. Si está autorizado, cambiar temporalmente la acción local de Log and drop a Log only.
4. Solo si no basta y MDR lo aprueba, devolver el feed de forma controlada al estado anterior documentado.
5. Volver a probar el mismo proceso empresarial y el efecto en logs tras cada cambio.
6. Resolver la causa y restaurar la protección productiva con una nueva fecha de revisión.

En entornos HA, se comprueban configuración y estado en el Primary actual. Los logs residen en el nodo que procesó el tráfico. Después de un failover controlado se vuelven a validar la conexión Central, el estado del feed, nuevos logs y tráfico real; no se presupone continuidad ininterrumpida de MDR o de logs.

Lista de comprobación

• Xstream Protection Bundle activo
• Sophos MDR Essentials o MDR Complete activo
• firewall registrado en la cuenta Central correcta
• Threat response mode y vía de contacto MDR documentados
• destino de log de Active Threat Response activo
• MDR Threat Feeds activado
• acción elegida conscientemente y piloto con plazo definido
• visibilidad de tráfico para 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 incidentes conocidos
• contexto de endpoint y límites de plataforma comprobados
• excepciones con responsable y fecha de revisión
• rollback y comprobación HA documentados

Preguntas frecuentes