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 había acuñado. Eso sucedería cuando Gartner introdujera el término en 2009. En ese momento, los productos de Palo Alto caían bajo el término anterior “Unified Thread Management”, o UTM. Si bien Palo Alto no inventó la UTM ni el NGFW, desde entonces se han convertido en el producto definitorio en ese espacio, contra el cual se miden todos los competidores. Para los propósitos de este post, solo vamos a usar el apodo NGFW por simplicidad.

Si bien lo que ahora llamamos “la nube” ciertamente existió en 2007, los centros de datos todavía se estaban construyendo en gran medida de la manera tradicional: una capa dura y crujiente de seguridad alrededor de un centro blando y pegajoso de datos y computación. Sólo las organizaciones más audaces estaban trasladando activos a AWS (Amazon Web Services) y otros nuevos servicios en la nube. El data center aún tenía un límite definido y conocido. Las líneas eran claras entre los activos dentro del data center y los del exterior. ‍

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

El NGFW, con su conjunto de potentes características de seguridad, era un ajuste hermoso para este modelo. Los NGFW rápidamente se convirtieron en los gatekeepers de los data centers, controlando cuidadosamente lo que entraba (y en mucho menor medida, lo que salía) de una red determinada. Potentes CPU personalizadas analizaron y movieron 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.

NGFW proveedores tales como Redes de Palo Alto, Check Point y Fortinet ahora se establecieron un nuevo objetivo: dominar dentro del data center, monitorear y controlar el tráfico entre aplicaciones, ya que segmentación de red se puso de moda como la “cosa nueva y caliente”.

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

Como si el costo impresionante de 10G de rendimiento no fuera un elemento disuasorio suficiente 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 eran excesivas y que a menudo no eran relevantes para la tarea en cuestión.

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

Administración de la complejidad de NGFW en la nube

La nube pública puso de cabeza al 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 ubicua como es, es una mala elección para las cantidades épicas de trabajo de bajo nivel que se realiza dentro de un NGFW. Palo Alto eligió los Procesadores de Red Cavium para realizar toda esa inspección y manipulación de paquetes de bajo nivel. Fortinet diseñó sus propios procesadores de clientes internos para hacer el trabajo.

El NGFW de hoy, según los estándares de hace apenas una década, es una supercomputadora clase agencia gubernamental, lo que sin duda 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 dio lugar a cambios importantes en la forma en que se manejaba la seguridad en la frontera de las redes en la nube. A menudo, docenas de firewalls virtuales tenían una carga equilibrada. 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 reduce los requerimientos de performance por firewall. Y los proveedores de firewall comenzaron a vender sus implementaciones de VM (Virtual Machine) en paquetes de seis y diez paquetes, porque uno o dos firewalls ya no podían hacer el trabajo.

Si eso suena complejo de construir y administrar, lástima la compañía más típica que movió solo una parte de sus activos a la nube. Como ambos IaaS (Infraestructura como servicio) y PaaS (plataforma como servicio) proliferaron, los límites de la red comenzaron a volverse cada vez más indistintos. Si bien la definición de “nube” relacionada con las TI se había derivado de la idea de un gran número de computadoras (análogas al vapor de agua) vistas juntas como una a distancia, comenzó a ser más apropiado usar una definición diferente: “Algo que oscurece o immanja”.

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 hizo increíblemente difícil protegerlas y hacer cumplir las políticas 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: funciones 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 más a menudo se denomina Segmentación de Confianza Cero (ZTS).

El concepto de microsegmentación es simple: aplicación de políticas (es decir, firewalls) en cada servidor, controlando el tráfico entrante y 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 a lo último (un firewall por servidor). La microsegmentación proporcionó 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 ha ocupado de puertos y protocolos sin sumergirse en el territorio de Inspección Profunda necesario para las características de NGFW.

Dentro de la Oficina del CTO, mi trabajo es jugar “¿y si?” y tratar de mirar hacia adelante a posibles problemas futuros y sus posibles soluciones. De esta manera, la investigación actual en Illumio incluye analizar las posibilidades de implementar características NGFW en un entorno de microsegmentación.

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