Hace un año publicamos nuestra actualización sobre los avances de «Secure by Design 2025», en la que repasábamos nuestros compromisos con respecto a los siete pilares de la iniciativa «Secure by Design» de la CISA. Desde entonces han pasado tantas cosas —tanto en todos nuestros productos como en el panorama de amenazas— que una sola publicación anual que lo abarque todo ya no hace justicia al trabajo realizado. Por eso vamos a dividir nuestras actualizaciones por producto, empezando por donde más está en juego: el firewall.
Los dispositivos perimetrales de red siguen siendo el tipo de objetivo más atractivo en el ámbito de la seguridad empresarial. Se ubican en los límites de confianza, presentan una instrumentación insuficiente crónica en todo el sector y, como documentamos en nuestro estudio sobre la cuenca del Pacífico, los atacantes con recursos suficientes se pasarán años estudiándolos, incluso atacando a los propios fabricantes que los producen. Nada de lo ocurrido en los últimos doce meses ha modificado esa valoración. Si acaso, las herramientas de ataque asistidas por IA han acortado el tiempo que transcurre entre la aparición de una oportunidad y su explotación, un cambio que analizamos en La avalancha de vulnerabilidades ya está aquí.
Esta actualización repasa lo que hemos lanzado para Sophos Firewall durante el último año, lo que aprendimos de la campaña FortiBleed, cómo se ajusta nuestro trabajo a la guía forense del NCSC para fabricantes de dispositivos de red y cuáles son nuestros próximos compromisos.
FortiBleed: una prueba para las configuraciones predeterminadas
En junio de 2026, salió a la luz un gran conjunto de credenciales expuestas de dispositivos Fortinet —apodado FortiBleed— como parte de una campaña más amplia contra dispositivos periféricos que provocó una alerta de refuerzo de seguridad de la CISA. La actividad relacionada también nos afectó: ataques de fuerza bruta y stuffing contra cuentas de usuario en dispositivos Sophos Firewall conectados a Internet.
Para los clientes de Sophos, se trató de intentos de adivinar contraseñas, no de una explotación. No encontramos ninguna vulnerabilidad implicada ni indicios de un compromiso generalizado. Años de decisiones para reforzar la seguridad de los valores predeterminados dieron sus frutos: sin credenciales predeterminadas, los portales de administración web y de usuario desconectados de la WAN por defecto, CAPTCHA en el portal de usuario, aplicación de la autenticación multifactorial (MFA) en todos los portales y el Health Check v22 señalando configuraciones de riesgo según los estándares CIS.
Aun así, aquí tienes dos lecciones de nuestro análisis posterior al incidente:
En primer lugar, la inscripción en la autenticación multifactorial (MFA) era un problema de «trust-on-first-use». Las cuentas existentes nunca habían iniciado sesión (algo especialmente habitual cuando una sincronización de grupos de AD incorpora cuentas inactivas o no humanas) no tenían la MFA activada, y quien se autenticara primero podía activarla. Si se intentaba descifrar la contraseña de esa cuenta mediante fuerza bruta en el portal de usuario, el atacante se convertía en el primer usuario, configurando legítimamente su propia MFA. Hemos rediseñado el proceso de incorporación para evitar eso. Ahora enviamos los códigos QR de registro por correo electrónico en lugar de mostrarlos en el portal, así que el primer uso requiere demostrar que controlas tu buzón de correo, no solo adivinar una contraseña. Los códigos caducan a las 24 horas si no se usan, y la incorporación por correo electrónico es la opción predeterminada para las nuevas implementaciones. Además, estamos desarrollando activamente un bloqueo dinámico contra los ataques de fuerza bruta y la autenticación multifactorial en SSH.
En segundo lugar, confirmar un resultado negativo a escala de toda la flota nos llevó más tiempo del que nos hubiera gustado. Teníamos la capacidad de observación necesaria para determinar que los clientes no se habían visto comprometidos, pero recopilar esas pruebas en cientos de miles de dispositivos fue más lento y requirió más trabajo manual de lo que debería haber sido. Esa lección influye directamente en nuestras inversiones en telemetría y análisis forense que te contaremos a continuación, incluida la telemetría de intentos fallidos de inicio de sesión que se envía a SophosLabs, lo que convierte nuestra base de usuarios en lo que creemos que será uno de los mejores sensores del sector para detectar campañas de ataque a dispositivos periféricos. Cuando llegue la próxima campaña al estilo FortiBleed, queremos analizarla —quién es el objetivo, desde dónde, a qué escala— en cuestión de horas, en lugar de días.
Mejoras de este año
Ya hablamos de las principales novedades arquitectónicas de la v22 cuando la versión entró en Early Access: un plano de control rediseñado y contenedorizado; un kernel 6.6+ reforzado con KASLR, canarios de pila y usercopy reforzado; el sensor XDR para Linux integrado para la supervisión remota de la integridad de la flota; y la función Health Check. La v22 es ahora nuestra versión de firmware más extendida, y es en la que basamos el trabajo de este año.
SLS en SFOS. El Sophos Linux Sensor ahora funciona en toda la serie de dispositivos XGS, hasta el más pequeño, el XGS 88, a partir de la v22 MR1. Detecta comportamientos posteriores a la explotación, como el acceso a shells interactivos y inversos, y detecta la actividad asociada de comando y control (C2). Y lo más importante: ahora podemos actualizar las reglas de detección de forma inalámbrica, independientemente de las versiones de firmware, y estamos creando un proceso de CI/CD para el contenido de detección de forma conjunta entre nuestros equipos de ingeniería de seguridad de red, SophosLabs y los equipos internos de detección y respuesta. Que sepamos, ningún otro proveedor de firewall ofrece una capacidad de detección de comportamiento de este tipo, con entrega continua y para toda la flota, directamente en los propios dispositivos. La prevención es lo ideal, la detección es imprescindible.
Telemetría rastreable. Las implementaciones virtuales y de software ahora requieren registro previo a su uso. Hemos eliminado el modo de aplazamiento del registro que antes permitía instancias anónimas y sin registrar. Esto cierra una vía que los atacantes (y los investigadores de vulnerabilidades con motivos poco claros) utilizaban para sondear nuestro software de forma anónima, y significa que nuestra telemetría puede atribuir cada implementación.
Fortalecimiento de la base. Menos llamativo, pero igual de importante: hemos modernizado la cadena de herramientas de compilación de SFOS (GCC y glibc actuales, con las mitigaciones contra exploits que traen consigo), hemos seguido reduciendo las rutas de ejecución con privilegios (incluida la eliminación del uso de «sudo» en varios componentes) y hemos ampliado el análisis estático con CodeQL y Semgrep en todos los repositorios del firewall, con los resultados alimentando un proceso de CI/CD controlado.
Visibilidad de las correcciones urgentes. Sophos Firewall lleva mucho tiempo siendo único en el envío de correcciones urgentes inalámbricas sin intervención: más del 99 % de los firewalls de los clientes las reciben automáticamente. La carencia era la verificabilidad: los clientes (y los auditores) tenían que confiar en que se había aplicado una corrección. Ahora el estado de las correcciones urgentes se ve directamente en la interfaz de usuario del firewall, el visor de registros, las notificaciones por correo electrónico y los informes de Sophos Central Firewall. Si nuestro aviso dice «ya tienes el parche instalado», ahora puedes comprobarlo tú mismo.
Actualizaciones de firmware programadas. En nuestros compromisos para 2024 nos comprometimos a programar automáticamente las actualizaciones de firmware. Sophos Central las lanzará en agosto de 2026: actualizaciones de mantenimiento recurrentes, con anulación en cada firewall para que los administradores mantengan el control total. La gestión de la flota lo confirma. La base instalada se ha actualizado al firmware actual más rápido que en cualquier ciclo anterior, y la v22 se ha convertido en la versión más extendida unos seis meses después de su lanzamiento. La aplicación automática de parches, consistente y predecible, es una de las funciones de seguridad más eficaces que podemos ofrecer, y la curva de adopción sugiere que los clientes están de acuerdo.
Dando rienda suelta a la IA en nuestro propio firewall
Ya hemos hablado de cómo los modelos de IA de vanguardia están redefiniendo la investigación de vulnerabilidades desde fuera. Pero la historia desde dentro es aún más importante. Los investigadores externos trabajan con binarios y comportamientos de «caja negra»; nosotros tenemos el código fuente, el sistema de compilación y montones de dispositivos reales. Esa es una ventaja asimétrica para los defensores… si la aprovechamos.
Este año hemos creado una plataforma interna de búsqueda de vulnerabilidades basada en agentes y la hemos aplicado primero a SFOS. No es una simple envoltura de chatbot: controla dispositivos de firewall reales (incluidos pares de alta disponibilidad) en un laboratorio aislado y reproducible, trabaja a partir del código fuente y genera hallazgos clasificados y respaldados por pruebas, con cada acción del agente registrada y atribuible. Los ingenieros de producto la manejan junto con nuestro equipo rojo, buscando vulnerabilidades con modelos de vanguardia como el GPT-5.6 Sol de OpenAI y el Claude Mythos Preview de Anthropic.
Los primeros resultados han superado nuestras expectativas, a una fracción del coste de una prueba de penetración tradicional, y con algunos hallazgos que validan el trabajo de refuerzo previo en lugar de revelar nuevas brechas (nuestros ingenieros ya habían eliminado el hallazgo más grave hasta la fecha en las versiones actuales gracias al trabajo de arquitectura que completaron de forma proactiva; en consonancia con nuestro compromiso con el CVE, publicaremos un CVE al respecto). Aquí hay detalles suficientes para un artículo completo —metodología, resultados y lo que esto implica para cómo se deben probar los productos— y lo publicaremos por separado.
Alineación con las directrices forenses del NCSC
En 2024, el NCSC y sus partners internacionales publicaron unas directrices sobre análisis forense digital y supervisión protectora para los fabricantes de dispositivos y equipos de red. En nuestra opinión, esta es la articulación más concreta hasta la fecha de lo que deberían significar las «pruebas de intrusiones» (que también es uno de los pilares de «Secure by Design» de la CISA) para los dispositivos periféricos. Hemos evaluado SFOS sección por sección en función de estas directrices, hemos compartido nuestro análisis detallado con el NCSC y les hemos mantenido al día sobre los avances. Esta es nuestra situación actual:
En qué aspectos cumplimos ya con las directrices. Registro seguro y registro remoto: la versión v22 introdujo un manejo de registros protegido y de solo adición, transporte seguro de registros a repositorios centrales e identificadores únicos por dispositivo en el registro. La cobertura de registro de eventos de autenticación, procesos, sistema de archivos y red se ha ampliado considerablemente gracias a SLS y al trabajo relacionado con la v22.
En qué aspectos estamos a medio camino. Algunas categorías de eventos aún no se capturan con la exhaustividad que especifican las directrices, y la recopilación de datos volátiles se aborda hoy en día de forma parcial a través de nuestro flujo de telemetría en tiempo real y la supervisión de la integridad de los archivos. Nuestro equipo de IDR ha analizado con éxito la memoria volátil de los dispositivos, pero todavía se necesita un mecanismo de captura integrado en el producto.
En qué aún no lo cumplimos. La recopilación de datos no volátiles —capturar imágenes de almacenamiento persistente de los dispositivos, de forma remota y a gran escala— es la mayor laguna que nos queda, tanto para nosotros como (diríamos) para el sector.
Para los lectores que siguen nuestro compromiso «Secure by Design» de la CISA: el trabajo de este año en el firewall se centra directamente en varios pilares. Las actualizaciones programadas de firmware cierran nuestro compromiso con los parches de seguridad; la incorporación reforzada de la autenticación multifactorial (MFA) amplía el pilar de la MFA al propio dispositivo; el SLS, la visibilidad de las correcciones urgentes y el trabajo de telemetría contribuyen al pilar de las pruebas de intrusiones; y la contenedorización del plano de control de la v22 continúa nuestro compromiso de reducir clases enteras de vulnerabilidades.
Esto nos lleva a los compromisos.
Compromiso 1: captura forense de la flota. Nos comprometemos a ofrecer una función de captura forense para Sophos Firewall, que permita recopilar artefactos volátiles y no volátiles de los dispositivos desplegados, y a subsanar las lagunas restantes con respecto a las directrices forenses del NCSC. El diseño está en marcha con las partes interesadas; informaremos del progreso en la próxima actualización de «Secure by Design» del firewall.
Compromiso 2: telemetría de ataques. Nos comprometemos a ampliar la telemetría de ataques de toda la flota de firewalls —incluida la telemetría de autenticaciones fallidas que se envía a SophosLabs— y a proteger aún más la integridad de los propios servicios de telemetría contra la manipulación, para que la detección de campañas a escala de flota no dependa de la honestidad de un dispositivo comprometido.
Publicamos este nivel de detalle porque creemos que los compradores deberían exigirlo, tanto a nosotros como a todos los proveedores de este mercado. Como ha argumentado Ollie Whitehouse, del NCSC, la seguridad de los productos es, en última instancia, un problema de incentivos de mercado: mejora cuando se premia la transparencia, en lugar de castigarla. Si este artículo te ayuda a hacer preguntas más difíciles a tus otros proveedores de infraestructura, habrá cumplido su función.
Y si eres investigador de seguridad: nuestro programa de recompensas por errores paga hasta 50 000 dólares por hallazgos relacionados con la plataforma de firewall. Cuanto más hagas trabajar a nuestros ingenieros, mejor será esta actualización el año que viene.

