Fortinet: El fin de la seguridad incremental

Durante años, Fortinet encarnó una promesa que el mercado aceptó sin demasiadas preguntas: alto rendimiento, integración total y una seguridad que podía evolucionar de manera incremental. Frente a cada vulnerabilidad, un parche. Frente a cada incidente, una actualización. El sistema podía fallar, pero siempre había un camino de regreso a la estabilidad. Ese supuesto no solo guió decisiones técnicas, también estructuró contratos, arquitecturas corporativas completas y una confianza operativa que hoy ya no existe.

Entre 2023 y 2026, ese modelo colapsó.

No por un evento extraordinario ni por una brecha histórica aislada, sino por la acumulación sostenida de vulnerabilidades críticas que afectaron directamente a FortiOS, muchas de ellas explotables de forma remota, sin autenticación previa y con impacto total sobre el dispositivo. La recurrencia fue tal que el parche dejó de cumplir su función esencial: restaurar la confianza.

Este artículo no discute si Fortinet tuvo más o menos CVEs que otros fabricantes. Eso es anecdótico. Lo que aquí se analiza es por qué el modelo de corrección incremental deja de funcionar específicamente en Fortinet, y por qué ese fracaso no puede resolverse con mejores procesos de parcheo, mayor transparencia o nuevas promesas comerciales.

Cuando la vulnerabilidad deja de ser un evento y se convierte en estado

El rasgo distintivo del período analizado no es la existencia de vulnerabilidades críticas, sino su continuidad. Fortinet operó durante meses —y en algunos tramos, años— bajo una lógica de emergencia permanente. Nuevos fallos críticos aparecían antes de que las organizaciones hubieran completado la evaluación, prueba y despliegue de parches anteriores. El ciclo clásico de gestión de vulnerabilidades simplemente dejó de cerrar.

Este fenómeno tiene implicancias profundas. La seguridad incremental depende del tiempo como amortiguador del riesgo. Tiempo para entender el fallo, tiempo para validar la corrección, tiempo para volver a confiar. En el ecosistema Fortinet, ese tiempo desapareció. El firewall dejó de ser un activo estable y pasó a ser un componente transitoriamente confiable, cuya integridad solo podía asumirse hasta el próximo advisory.

Cuando la vulnerabilidad se vuelve recurrente, deja de percibirse como excepción y se integra en la normalidad operativa. La urgencia se vuelve ruido. La reacción se automatiza. El parche pierde su valor simbólico como restaurador de certeza y se transforma en un acto defensivo mínimo, insuficiente para devolver control. En ese contexto, el riesgo no disminuye; se acumula.

Aquí se produce el primer quiebre del modelo incremental. Un sistema que no puede recuperar un estado de confianza entre fallos deja de ser corregible de manera progresiva. Lo que queda es una negociación constante con la incertidumbre, algo incompatible con el rol estratégico que ocupa un firewall perimetral.

FortiOS y la recurrencia de errores que no deberían persistir

El análisis técnico de las vulnerabilidades más severas que afectaron a FortiOS revela un patrón que no puede explicarse como casualidad. Una proporción significativa de los fallos críticos pertenece a clases clásicas de errores de seguridad de memoria: desbordamientos de búfer basados en heap, escrituras fuera de límites, errores de saneamiento de entradas y vulnerabilidades de cadena de formato. Estos no son defectos marginales ni producto de escenarios extremos. Son errores fundamentales que la industria conoce desde hace décadas.

La persistencia de estas clases de fallos en un sistema operativo de seguridad expuesto a Internet plantea preguntas incómodas sobre la base de código y los procesos que la sostienen. No se trata de un error aislado que escapó a la revisión. Se trata de patrones que reaparecen, incluso después de múltiples ciclos de corrección. Esto indica deuda técnica acumulada y mecanismos de aseguramiento de calidad que no logran interceptar las causas raíz del problema.

El componente más afectado ha sido el SSL VPN, y esto no es accidental. Se trata de una aplicación web compleja que procesa entradas no autenticadas, gestiona sesiones, interactúa con el sistema de archivos y opera con privilegios elevados. En FortiOS, este servicio no está aislado en un dominio de ejecución estrictamente limitado, sino profundamente integrado en el sistema operativo. Esa integración convierte cada error de memoria en un vector de compromiso sistémico.

La elección de C y C++ como lenguajes predominantes explica parte del problema, pero no lo justifica. Estos lenguajes priorizan rendimiento y control del hardware, pero carecen de seguridad de memoria intrínseca. Su uso exige procesos extremadamente rigurosos de análisis estático, fuzzing y revisión de código. La repetición de errores básicos sugiere que esos procesos no están escalando al ritmo de la complejidad funcional que Fortinet decidió asumir.

Aquí se rompe la segunda premisa del modelo incremental: la idea de que corregir instancias individuales elimina el problema. En Fortinet, el parche corrige el síntoma, pero la estructura que permite que el fallo reaparezca permanece intacta.

Arquitectura monolítica y amplificación sistémica del impacto

El elemento que transforma las vulnerabilidades de Fortinet en eventos particularmente destructivos no es solo el código, sino la arquitectura de FortiOS. Fortinet adoptó una estrategia de convergencia extrema: firewall, VPN, SD-WAN, switching, control inalámbrico y múltiples servicios auxiliares conviven en una única imagen de firmware, optimizada para rendimiento mediante aceleración por ASICs propietarios.

Esta convergencia fue una ventaja competitiva durante años. Permitió reducir costos, simplificar despliegues y ofrecer un rendimiento sobresaliente. Pero desde el punto de vista de la resiliencia, eliminó una propiedad esencial: la contención de fallos. En un sistema monolítico, los límites entre componentes son conceptuales, no estructurales. Los procesos comparten recursos, bibliotecas y dominios de confianza. Cuando uno cae, el impacto se propaga.

En FortiOS, la separación entre plano de datos, plano de control y servicios expuestos no es lo suficientemente estricta como para amortiguar una explotación exitosa. El mismo sistema que procesa tráfico productivo expone interfaces web, gestiona autenticación y almacena secretos. Esta falta de aislamiento explica por qué tantas vulnerabilidades derivan en compromisos totales del dispositivo.

Desde una perspectiva de diseño seguro, esto no es un bug corregible con parches incrementales. Es una decisión arquitectónica. Significa que cada vulnerabilidad crítica tiene consecuencias máximas, independientemente de cuán rápido se publique una corrección. La arquitectura no limita el daño; lo amplifica.

Mientras esta convergencia siga siendo el núcleo del diseño de FortiOS, el impacto de futuras vulnerabilidades seguirá siendo sistémico. La seguridad incremental asume que los fallos pueden aislarse y corregirse sin colapsar el sistema. En Fortinet, esa asunción dejó de ser válida.

Persistencia post-explotación y la ruptura definitiva de la confianza

Uno de los puntos más graves del período analizado fue la aparición de mecanismos de persistencia post-explotación específicamente adaptados a FortiOS. En múltiples incidentes, los atacantes no se limitaron a explotar la vulnerabilidad inicial. Implantaron artefactos capaces de sobrevivir a reinicios e incluso a actualizaciones de firmware.

Este hecho rompe un supuesto fundamental de la operación de seguridad: que parchear equivale a limpiar. En Fortinet, esa equivalencia dejó de ser confiable. La posibilidad de mantener persistencia después de aplicar parches oficiales transforma el incidente en algo cualitativamente distinto. Ya no se trata de corregir una falla puntual, sino de reconstruir la confianza en el dispositivo.

Cuando un firewall no puede garantizar su propia integridad tras un incidente, deja de ser una raíz de confianza. El equipo de seguridad ya no puede asumir que el dispositivo es confiable por estar actualizado. En escenarios extremos, la única remediación real es la reinstalación completa o el reemplazo físico, medidas que rara vez están contempladas en planes operativos estándar.

Este punto invalida el ciclo incremental completo. Si el parche no restaura la confianza, el modelo colapsa. Lo que queda es un dispositivo que debe ser tratado como potencialmente hostil incluso después de corregido. Para un firewall perimetral, esa contradicción es insostenible.

El quiebre estratégico: cuando el modelo mental deja de funcionar

Reducir lo ocurrido con Fortinet a un problema de ingeniería sería un error de lectura. El quiebre real es conceptual. Lo que colapsa no es solo una plataforma, sino una forma completa de entender la seguridad perimetral y la relación entre proveedor, operador y riesgo.

Durante años, la seguridad incremental funcionó como un contrato tácito. Los proveedores desplegaban sistemas complejos y prometían corregirlos sobre la marcha. Los clientes aceptaban la imperfección bajo la premisa de que cada corrección devolvía estabilidad. Ese contrato se rompe cuando el parche deja de devolver certeza y pasa a ser solo una medida de contención temporal.

Fortinet es el primer caso masivo donde esta ruptura se vuelve evidente y difícil de ignorar. No porque sea el único proveedor con problemas, sino porque la recurrencia, el impacto y la naturaleza de sus vulnerabilidades hacen imposible seguir sosteniendo la ficción de que “un update más” devuelve el control.

El fin de la seguridad incremental no implica el fin del perímetro, pero sí el fin de la ingenuidad. Implica aceptar que hay arquitecturas que ya no escalan, que hay deudas técnicas que no se pagan con parches y que hay decisiones de diseño que, una vez tomadas, condicionan todo lo que viene después. En ese escenario, la pregunta ya no es qué tan rápido se publica un advisory, sino qué tan recuperable es la confianza cuando el advisory deja de ser suficiente.

Fortinet puso ese dilema sobre la mesa. No por intención, sino por acumulación. Y una vez que se ve, ya no se puede desver.