En los últimos días publiqué una reflexión sobre firewalls corporativos basada principalmente en mi experiencia real en entornos de producción.
https://ruymangil.es/firewalls
La verdad es que no esperaba que tuviera el alcance que ha tenido, ni mucho menos que generara tantos comentarios, matices y aportaciones de otros profesionales del sector.
Y precisamente por eso creo que merece la pena ampliar el análisis.
Cuando hablamos de firewalls empresariales, muchas veces el debate se simplifica demasiado. Se habla de fabricantes como si fueran equipos de fútbol: Check Point, Fortinet, Palo Alto Networks, WatchGuard, Sophos, Cisco, Zyxel u otras soluciones.
Pero la realidad técnica es bastante más compleja.
No basta con decir que un fabricante es mejor que otro. Tampoco basta con mirar una posición en Gartner, una ficha técnica, una tabla de rendimiento o una experiencia puntual en una empresa concreta.
La pregunta importante no debería ser únicamente:
¿Cuál es el mejor firewall?
La pregunta realmente útil debería ser:
¿Qué solución encaja mejor en este entorno concreto, con este presupuesto, este equipo técnico, esta arquitectura, estos riesgos y estas necesidades de negocio?
La experiencia real importa, pero no lo explica todo
Mi análisis inicial partía de mi experiencia profesional con soluciones como Check Point y Fortinet, además de otras plataformas de firewall empresarial que he visto en distintos contextos.
También intenté ser claro con un punto importante: no he trabajado todavía con Palo Alto Networks en producción. Por tanto, cualquier valoración que haga sobre esa plataforma no puede estar basada al cien por cien en experiencia directa, sino en información pública, comparativas técnicas, documentación del fabricante y, sobre todo, experiencias de profesionales que sí la han operado en entornos reales.
Creo que es importante decir esto con honestidad.
Una cosa es opinar desde la experiencia directa, y otra muy distinta es valorar una solución desde datos públicos o referencias externas. Ambas cosas pueden ser útiles, pero no son lo mismo.
No se puede comparar solo por marca
Uno de los errores habituales al comparar firewalls es quedarse únicamente con el nombre del fabricante.
Pero no es lo mismo hablar de un fabricante en abstracto que analizar un modelo concreto, una generación concreta, una arquitectura concreta y un escenario concreto.
Hay que mirar muchos factores:
Modelo exacto del firewall.
Arquitectura hardware.
Tipo de tráfico.
Inspección SSL/TLS.
IPS/UTM activado.
SD-WAN.
VPN site-to-site y cliente.
Alta disponibilidad.
Logging.
Políticas heredadas.
Coste de licencias.
Soporte disponible.
Capacidad real del equipo que lo administra.
Porque una cosa es el rendimiento de una ficha técnica y otra muy distinta es el rendimiento real con servicios de seguridad activados.
Un firewall puede prometer mucho throughput sobre el papel, pero la pregunta seria es qué ocurre cuando activas inspección TLS, IPS, antivirus, control de aplicaciones, filtrado web, logging intensivo, VPNs, políticas complejas y alta disponibilidad.
Ahí es donde empiezan las diferencias reales.
El caso de Fortinet y la arquitectura
Uno de los comentarios que más me pareció interesante fue el relacionado con Fortinet y su arquitectura.
No se debería hablar de Fortinet solo como “Fortinet” sin mirar generación, modelo y arquitectura concreta. La diferencia entre líneas, ASICs dedicados, cambios de arquitectura o plataformas basadas en otros enfoques puede afectar mucho al comportamiento real de la solución.
Esto refuerza una idea que considero clave: no se puede valorar un firewall únicamente por el fabricante ni por su posición en un informe.
Hay que analizar cómo se comporta en producción.
Y producción significa tráfico real, usuarios reales, servicios críticos, ventanas de mantenimiento limitadas, presión del negocio, incidencias, auditorías, actualizaciones, reglas heredadas y decisiones que no siempre son cómodas.
Gartner, CyberRatings y datos técnicos
También creo que es importante diferenciar entre tipos de fuentes.
Gartner tiene mucho peso para directores de IT, CISOs, responsables de compras y áreas de decisión. Sus informes ayudan a entender visión de mercado, estrategia del fabricante, capacidad de ejecución, presencia internacional, soporte, ecosistema y madurez empresarial.
Eso tiene valor.
Pero también existen pruebas más técnicas o independientes, como CyberRatings y otros laboratorios especializados, que pueden aportar una visión diferente: eficacia de seguridad, evasiones, rendimiento bajo carga, falsos positivos, comportamiento con inspección activada y coste por rendimiento protegido.
No creo que una fuente sustituya a la otra.
Creo que se complementan.
La visión de mercado ayuda a entender al fabricante.
Las pruebas técnicas ayudan a entender el comportamiento de la solución.
Y la experiencia real ayuda a entender qué ocurre cuando esa solución se tiene que administrar todos los días.
La operación diaria no siempre aparece en los informes
Hay una parte que muchas veces no se ve en los cuadrantes, comparativas o fichas técnicas: la operación diaria.
Administrar un firewall crítico no consiste solo en crear reglas y revisar logs.
También implica tomar decisiones bajo presión.
Actualizar versiones.
Gestionar clústeres en alta disponibilidad.
Diagnosticar caídas de VPN.
Revisar reglas heredadas de años anteriores.
Validar cambios.
Analizar logs en una incidencia crítica.
Coordinarse con soporte.
Preparar planes de rollback.
Justificar costes.
Y, en ocasiones, saber decir que no a una recomendación que no tiene suficiente base técnica para el entorno concreto que estás administrando.
Cuando el soporte no está a la altura del problema
En una ocasión, trabajando con un entorno crítico basado en Check Point, vivimos una situación complicada después de una actualización.
Tras esa actualización, empezamos a detectar comportamientos anómalos. Algunas reglas no parecían interpretarse como esperábamos y el comportamiento del firewall dejó de coincidir con lo que teníamos validado previamente en producción.
En un entorno de seguridad perimetral crítico, eso no es un detalle menor.
Cuando una actualización introduce un comportamiento inesperado, la siguiente decisión no puede ser simplemente “actualizar otra vez” sin un análisis profundo.
En aquel caso, tanto el Director de IT como yo teníamos claro que volver a actualizar sin entender bien el origen del problema podía generar más incidencias en lugar de resolverlas.
Durante las reuniones técnicas con ingenieros senior del proveedor de la solución, canalizado a través de Telefónica, y también con ingenieros del soporte del fabricante Check Point ubicados en India —lo aclaro porque no lo menciono en ningún sentido discriminatorio, sino para contextualizar que era soporte remoto internacional—, la respuesta se reducía una y otra vez a lo mismo:
“Actualicen.”
Y ese era precisamente el problema.
Cuando una infraestructura empieza a fallar después de una actualización, recomendar otra actualización como única respuesta, sin entrar en detalle sobre reglas afectadas, logs, cambios entre versiones, known issues, hotfixes, impacto en VPNs, comportamiento del clúster o plan de rollback, no me parece una respuesta suficiente para un entorno crítico.
En ese momento tuve que decir que no.
Y no una vez.
Las veces que hizo falta.
No por llevar la contraria al fabricante ni al proveedor, sino porque cuando administras una infraestructura crítica, tu responsabilidad no es seguir una recomendación genérica sin más. Tu responsabilidad es proteger el servicio, reducir el riesgo y tomar decisiones técnicas con criterio.
Una recomendación de soporte puede ser válida, pero debe estar justificada.
Debe tener contexto.
Debe tener análisis.
Debe tener plan de contingencia.
Debe tener un motivo técnico claro.
Repetir “actualicen” no es soporte especializado.
Soporte especializado es revisar logs, identificar reglas afectadas, comprobar cambios entre versiones, validar errores conocidos, proponer hotfixes si existen, analizar impacto, preparar rollback, definir ventana de mantenimiento y acompañar al cliente en una decisión de riesgo.
A pesar de todo, Check Point sigue siendo mi referencia
Y dicho todo lo anterior, precisamente por eso quiero ser justo.
A pesar de haber vivido situaciones complejas con Check Point, sigue siendo la solución que más robusta me ha parecido en entornos críticos.
Sé que mucha gente la considera compleja. Y puede serlo.
Pero, en mi experiencia, esa complejidad también viene acompañada de una sensación de control, madurez y profundidad técnica que valoro mucho cuando hablamos de seguridad perimetral seria.
Con Check Point he sentido que podía manejar mejor situaciones delicadas, investigar problemas, entender políticas, revisar comportamiento y mantener control sobre entornos exigentes.
No digo que sea perfecta.
Ninguna solución lo es.
Pero sí puedo decir que, de las soluciones que he trabajado en producción, ha sido la que más confianza me ha transmitido en escenarios críticos.
Fortinet, Palo Alto y otras soluciones
Fortinet me parece una solución muy potente y competitiva, especialmente cuando se busca rendimiento, ecosistema, SD-WAN y una buena relación coste/prestaciones.
Pero también creo que hay que dimensionar muy bien, entender la arquitectura concreta y no quedarse solo con el marketing del rendimiento.
Palo Alto Networks me parece una plataforma muy interesante por visibilidad, App-ID, cloud, automatización y enfoque de seguridad avanzada. Pero, siendo honesto, al no haberla usado todavía en producción, no puedo hacer una comparativa completamente basada en experiencia directa.
En ese caso, mi valoración tiene que apoyarse en datos públicos, comparativas técnicas, documentación y experiencias de otros profesionales.
Y luego están soluciones como WatchGuard, Sophos, Zyxel, Cisco u otras que pueden tener mucho sentido en determinados entornos.
No todo el mundo necesita la solución más grande, más cara o más reconocida.
A veces una empresa necesita una solución estable, administrable, bien soportada y que encaje con el tamaño real del negocio y del equipo técnico que la va a operar.
Conclusión
En seguridad perimetral, la decisión correcta no debería depender solo del fabricante, sino de una evaluación técnica y operativa del entorno: riesgos, arquitectura, continuidad del servicio, soporte disponible, coste total y capacidad real del equipo para administrar la solución.
No existe el mejor firewall universal.
Existe la solución que mejor encaja en un contexto concreto.
Y ese contexto incluye tecnología, presupuesto, arquitectura, equipo humano, soporte, riesgos, madurez operativa y necesidades reales del negocio.
Por eso agradezco tanto los comentarios que se han generado a partir del análisis inicial.
Porque este tipo de debate técnico, con experiencias reales, matices y discrepancias bien argumentadas, es lo que realmente aporta valor.
Y si otros profesionales quieren seguir aportando experiencia real con Check Point, Fortinet, Palo Alto, WatchGuard, Sophos, Zyxel, Cisco u otras soluciones, estaré encantado de leerlo.