La historia y los desafíos de los firewalls de próxima generación

Hace unos dieciséis años, en 2007, Palo Alto Networks presentó su primer producto, alterando para siempre la seguridad de la red. El término "firewall de próxima generación" o NGFW aún no se acuñó. Eso sucedería cuando Gartner introdujo el término en 2009. En ese momento, los productos de Palo Alto se incluían en el término anterior "Gestión unificada de subprocesos" o UTM. Si bien Palo Alto no inventó el UTM o el NGFW, desde entonces se convirtieron en el producto definitorio en ese espacio, con el que se miden todos los competidores. Para los propósitos de esta publicación, solo usaremos el apodo NGFW para simplificar.

Si bien lo que ahora llamamos "la nube" ciertamente existía en 2007, los centros de datos todavía se construían en gran medida de la manera tradicional: una cáscara de seguridad dura y crujiente alrededor de un centro de datos y computación suave y pegajoso. Solo las organizaciones más audaces estaban moviendo activos a AWS (Amazon Sitio web Services) y otros nuevos servicios en la nube. El centro de datos todavía tenía un límite definido y conocido. Las líneas eran claras entre los activos dentro del centro de datos y los del exterior. ‍

NGFW: Perfecto para proteger el perímetro del centro de datos

El NGFW, con su grupo de poderosas características de seguridad, encajaba perfectamente con este modelo. Los NGFW se convirtieron rápidamente en los guardianes de los centros de datos, controlando cuidadosamente lo que entraba (y en mucha menor medida, lo que salía) de una red determinada. Las poderosas CPU personalizadas analizaban y movían paquetes rápidamente en su camino, y las personas a cargo de la seguridad dormían un poco mejor por la noche, sabiendo que sus activos estaban protegidos por un conjunto de nuevas herramientas.

Los proveedores de NGFW como Palo Alto Networks, Check Point y Fortinet ahora se fijan un nuevo objetivo: el dominio dentro del centro de datos, el monitoreo y el control del tráfico entre aplicaciones, a medida que la segmentación de la red se puso de moda como la "nueva novedad".

Aquí, sin embargo, se enfrentaron a un desafío mucho mayor. Los NGFW fueron una opción obvia para proteger el perímetro del centro de datos. El costo prohibitivo del hardware, las licencias y el soporte se justificó por los claros beneficios, y el precio se mantuvo bajo control por el hecho de que las conexiones a Internet en los centros de datos eran relativamente lentas en comparación con la conectividad en el interior, y el precio aumenta con el ancho de banda. En el interior, sin embargo, no se encontró una relación costo/beneficio tan clara. Un porcentaje significativo de las características de NGFW, tomando como ejemplo la mitigación de DDoS o el modelado del tráfico, no tenían ningún valor en el interior. Pero pagaste por ellos, a pesar de todo.

Como si el costo deslumbrante de 10G de rendimiento no fuera suficiente elemento disuasorio para el uso interno, cada costo se duplicó en aras de la redundancia. Era extremadamente difícil justificar cinco veces el gasto de un firewall tradicional para un conjunto de características que era excesivo y, a menudo, no relevante para la tarea en cuestión.

Dicho esto, las regulaciones de la industria y el gobierno requieren ciertos controles en el interior, al menos para ciertas clases de aplicaciones. HIPPA y PCI me vienen a la mente como ejemplos destacados. Por lo tanto, los clientes se decidieron por soluciones híbridas, con dispositivos NGFW que protegen el límite y algunas aplicaciones críticas y específicas, con los tradicionales con estado, que no son NGFW, asumiendo la holgura de la protección interna. Este matrimonio infeliz de lo viejo y lo nuevo funcionó por un tiempo. Todo el camino hasta la aceptación generalizada de la nube pública.

Gestión de la complejidad de los NGFW en la nube

La nube pública puso patas arriba el mundo de la seguridad. Pero no para todos, y no siempre de manera obvia.

Recuerde que los NGFW realizan una cantidad asombrosa de procesamiento en cada paquete que pasa a través de su chasis. La arquitectura Intel, tan omnipresente como es, es una mala elección para las cantidades épicas de trabajo de bajo nivel que se deben realizar dentro de un NGFW. Palo Alto eligió Cavium Network Processors para realizar toda esa inspección y manipulación de paquetes de bajo nivel. Fortinet diseñó sus propios procesadores internos para hacer el trabajo.

El NGFW de hoy, según los estándares de hace solo una década, es una supercomputadora de clase de agencia gubernamental, lo que ciertamente representa parte del costo. Los proveedores de NGFW respondieron rápidamente al cambio a la nube con versiones virtuales de sus productos, pero el rendimiento fue abismal en todos los ámbitos debido a las limitaciones de la arquitectura Intel.

Esto resultó en cambios importantes en la forma en que se manejaba la seguridad en el borde de las redes en la nube. A menudo, se equilibraba la carga de docenas de firewalls virtuales. Las redes se rediseñaron para tener muchos más puntos de interconexión de Internet que en los días físicos, lo que redujo los requisitos de rendimiento por firewall. Y los proveedores de firewalls comenzaron a vender sus implementaciones de VM (máquina virtual) en paquetes de seis y diez, porque uno o dos firewalls ya no podían hacer el trabajo.

Si eso suena complejo de construir y gestionar, lástima de la compañía más típica que movió solo una parte de sus activos a la nube. A medida que proliferaban tanto IaaS (infraestructura como servicio) como PaaS (plataforma como servicio), los límites de la red comenzaron a volver cada vez más confusos. Mientras que la definición relacionada con TI para "nube" se derivó de la idea de una gran cantidad de computadoras (análogas al vapor de agua) vistas juntas como una sola desde la distancia, comenzó a ser más apropiado usar una definición diferente: "Algo que oscurece o mancha".

A medida que los centros de datos comenzaron a alojar una selección aleatoria de aplicaciones y partes de aplicaciones en la nube, con otras aplicaciones (y partes de aplicaciones) permaneciendo en el sitio, se volvió increíblemente difícil protegerlas y hacer cumplir la política de seguridad. Esto se debe en gran parte a que se hizo casi imposible definir límites, donde normalmente se aplica la seguridad. E incluso en los casos en que los límites eran claros, el gran volumen de hardware, software y configuración de seguridad se volvió abrumador.

Como resultado, la seguridad dio un gran paso atrás.

Mirando hacia el futuro: Características de NGFW en un entorno de microsegmentación

Así comenzó el área de lo que se conocía en los primeros días como microsegmentación, y lo que ahora se llama más a menudo Zero Trust Segmentation (ZTS).

El concepto de microsegmentación es simple: aplicación de políticas (es decir, firewalls) en cada servidor, controlando tanto el tráfico entrante como el saliente a todos los demás servidores. Fundamentalmente, la microsegmentación es simplemente una extensión de la idea de segmentación de red llevada al final (un firewall por servidor). La microsegmentación brindó a los equipos de seguridad una nueva y poderosa herramienta para lidiar con los "límites difusos" alrededor y dentro de nuestros centros de datos al abordar la seguridad servidor por servidor (o al menos aplicación por aplicación).

Históricamente, la microsegmentación se ocupó de puertos y protocolos sin sumergir en el territorio de inspección profunda necesario para las características de NGFW.

Dentro de la Oficina del CTO, mi trabajo es jugar "¿qué pasaría si?" y tratar de mirar hacia adelante a posibles problemas futuros y sus posibles soluciones. Por lo tanto, la investigación actual en Illumio incluye analizar las posibilidades de implementar características de NGFW en un entorno de microsegmentación.

Lea mi blog la próxima semana para obtener más información sobre la investigación de Illumio y estos posibles desarrollos futuros para la microsegmentación.