Explorando el uso de la funcionalidad NGFW en un entorno de microsegmentación

Durante casi dos decenios, firewalls de próxima generación (NGFW) han sido una herramienta de seguridad esencial. Pero a medida que las redes actuales se vuelven cada vez más complejas, la protección perimetral que ofrecen los NGFW resuelve un problema que cada vez es menos relevante.

Illumio está investigando las posibilidades de implementar características NGFW en un microsegmentación entorno, combinando las dos tecnologías para ofrecer el tipo de seguridad que requieren las redes complejas.

En primera parte, revisé la historia, el valor y los desafíos de los firewalls de próxima generación (NGFW).

En este segundo artículo, voy a hablar del “¿y si?” escenario de incrustación de un subconjunto de la funcionalidad NGFW en una solución de microsegmentación. Hablaré sobre diferentes casos de uso y qué características de NGFW podrían ser adecuadas para cada uno.

Los NGFW trabajan para el tráfico norte-sur, pero luchan con este-oeste

El NGFW fue diseñado en torno a la idea de proteger el perímetro de una red, y en gran medida en torno a la protección contra amenazas en el tráfico entrante. En el mundo de las redes, a este tipo de tráfico se le suele denominar “norte-sur”. Esta terminología se deriva de la práctica generalizada de dibujar una red con la “burbuja” de Internet en la parte superior, con tráfico fluyendo hacia el centro de datos viajando de arriba a abajo, o de norte a sur. El tráfico dentro del centro de datos generalmente se dibuja como que se mueve lateralmente, de izquierda a derecha o de derecha a izquierda, y por lo tanto, a menudo se denomina “este-oeste”.

Usando esta terminología, se puede decir que existe un caso de uso poderoso para los NGFW utilizados en un rol norte-sur, como hablé en la primera parte. Pero el caso de uso para este-oeste es un poco menos seguro. Esta segunda declaración probablemente levantó algunos pelos en la parte posterior de tu cuello, así que déjame ser un poco más específico sobre esa afirmación.

Los firewalls cuestan tres tipos de dinero: hardware, mantenimiento/soporte y configuración/monitoreo. A pesar del alto costo en las tres categorías, el ROI para los NGFW es bastante claro para el caso de uso norte-sur. Cuando se trata de este-oeste, resulta que solo un subconjunto de capacidades completas de NGFW son relevantes, pero los proveedores no le dan un descuento por no usar el conjunto completo de características. A menudo es difícil justificar la compra completa de un equipo NGFW y usar solo la mitad de la funcionalidad, más aún en los casos en que el conjunto de características NGFW no es exigido por ley o regulación.

NGFW para el tráfico sur-norte

Eso es dos de los buenos casos de uso para un NGFW, pero en realidad hay un tercero que la gente rara vez considera, excepto de pasada: el caso de uso sur-norte, o en inglés, que controla el tráfico saliente desde dentro de la red. Los vendedores de NGFW hablan de ello, pero solo un poco. Y la mayoría de las organizaciones, aunque son conscientes de la amenaza de las conexiones salientes sin restricciones, hacen muy poco para abordarla realmente. Al trabajar con muchos clientes a lo largo de los años, descubrí que la mayoría de las organizaciones ni siquiera tienen un proceso establecido para que sus propietarios de aplicaciones internas soliciten controles salientes en el borde de la red.

Mi trabajo es básicamente I+D, con un fuerte enfoque en la parte “R”. En ese sentido, hagamos un experimento mental. Por un momento, considera resuelto el problema norte-sur. No está resuelto en el sentido de que no existe una solución 100% impecable, pero sí en el sentido de que la mayoría de las organizaciones ya no consideran que ese camino sea la principal vía de ataque a sus redes. En su lugar, pensemos en cómo las redes podrían hacerse más seguras si pudiera implementar características NGFW seleccionadas en su solución de microsegmentación y mejorar sus controles NGFW este-oeste y sur-norte, sin tener que comprar más equipos o tener que luchar contra sus propios procesos organizativos internos que le impiden aprovechar las características de NGFW salientes.

Los casos de uso sur-norte y este-oeste son diferentes, pero existe una superposición considerable. Además, muchas características norte-sur simplemente no son relevantes para ninguna de ellas. Comencemos con el caso de uso este-oeste.

Como dije anteriormente, ciertamente existe un caso de uso para un subconjunto limitado de controles NGFW este-oeste. El ROI de un equipo completo (o dispositivo virtual) puede ser cuestionable, dado el costo, pero la necesidad es real. Si su red contiene PII, HIPPA o PCI datos, es casi seguro que estará sujeto a las leyes y regulaciones relacionadas con la protección de esos datos. En muchos casos, esto incluye un requisito explícito para implementar los servicios tradicionales de NGFW como DLP (Data Loss Prevention) e IDS/IPS (Intrusion Detection/Prevention Service). Incluso si no hay mandato, sigue siendo una práctica óptima. El ID de la aplicación, en otras palabras, la capacidad de bloquear o permitir el tráfico basado en el tipo real de tráfico, a diferencia del puerto y el protocolo, también es una herramienta poderosa y deseable para prevenir ataques y exfiltración de datos.

Para el caso de uso sur-norte, algunas características adicionales podrían ser útiles. Probablemente aún se necesite DLP, y Application ID es igualmente útil para este caso de uso, pero a eso agregaría el filtrado de URL y la capacidad de controlar el tráfico basado en la reputación de IP de destino y la geografía. Claro, su NGFW fronterizo ya puede hacer esto, pero como señalé anteriormente, a menudo no hay forma de que el propietario de una aplicación aproveche estas características si los dispositivos fronterizos no están bajo su control. Y rara vez se encuentran en un entorno de data center grande.

La mayoría de los otros servicios NGFW tienen un valor limitado para este-oeste o sur-norte. DDoS y QoS tienen poco sentido dentro de una red. Del mismo modo, el software AV moderno que se ejecuta dentro del sistema operativo es probablemente más eficiente que una solución basada en red, por lo que el antivirus basado en la red probablemente no esté en la agenda.

El performance de las funciones de NGFW en dispositivos de punto final

Es hora de hablar sobre las implicaciones de performance de las funciones de NGFW que se ejecutan en puntos finales. Si recuerda, la primera parte mencionó que los dispositivos NGFW son casi sistemas de clase supercomputadora con mucho hardware especializado para obtener un performance respetable. Obviamente, se deduce que se impondría una penalización sustancial de performance en servidores individuales al implementar la misma funcionalidad. Por suerte, este parece que podría ser uno de esos momentos en los que la intuición sale por la ventana. Hablemos del por qué.

IDS/IPS es un excelente lugar para comenzar. De todos los servicios NGFW, IDS/IPS se considera uno de los “más pesados”, lo que significa que consume una cantidad desproporcionada de recursos y es una de las razones de la gran cantidad de silicio personalizado en un dispositivo NGFW. Si estoy protegiendo un centro de datos de tamaño moderado de 1,000 cargas de trabajo con una solución IDS/IPS, probablemente necesite admitir firmas IDS/IPS para al menos una docena de sistemas operativos diferentes (Windows 2008, 2012, 2016, 2019, al menos media docena de variaciones y versiones de CentOS, RedHat y Ubuntu (además posiblemente Solaris o AIX, si estoy en salud o banca). Cada uno de esos 1,000 servidores ejecuta al menos un servicio que voy a querer vigilar, posiblemente hasta tres o cuatro servicios diferentes cada uno, todos los cuales tienen vulnerabilidades potenciales. Y con una docena de sistemas operativos, podría estar ejecutando una docena de versiones diferentes de cada uno de esos tres o cuatro servicios, cada uno de los cuales tiene vulnerabilidades diferentes.

En resumen, estoy pendiente de entre 10 mil y 100 mil firmas de vulnerabilidad para esas mil máquinas. Y estoy buscando señales de aquellos en cada paquete que fluye a través de mi dispositivo de red NGFW, en cada puerto posible que puedan estar operando. Esto claramente no es una carga que queremos imponer en cada servidor del data center.

En la práctica, no necesitamos. No hay razón para buscar vulnerabilidades de Windows en un host Linux. No es necesario buscar vulnerabilidades de apache2 en una máquina que ejecuta NGINX. No es necesario buscar vulnerabilidades de Application X versión 1.0, 1.1, 1.2, 1.3, 2.0, 2.1 en un sistema que ejecuta la aplicación X versión 2.2.

En lugar de buscar entre 10,000 y 100,000 vulnerabilidades en cada paquete, buscamos tal vez cuatro. No 4.000. Cuatro. Y cuatro es un problema solucionable.

¿Cómo? Porque en virtud de tener un agente en cada servidor, tenemos acceso completo para entender el sistema operativo, qué parches se han aplicado y qué no se han aplicado, qué software (y qué versiones de ese software) están instalados y en ejecución, y específicamente en qué puertos se comunican. Se buscan vulnerabilidades específicas para las versiones de SO y software detectadas, específicamente en los puertos a los que están vinculados los procesos relevantes. Reducimos el espacio de búsqueda en algo así como cuatro órdenes de magnitud. Y cuatro órdenes de magnitud es un número espectacularmente grande en informática. Es la diferencia entre difícil y fácil.

Estrategias similares podrían aplicarse a servicios como DLP y filtrado de URL. No es necesario filtrar cada paquete en cada servidor para contenido DLP restringido, ni mantener bases de datos masivas de URL o información IP para direcciones públicas en cada servidor. En el caso de DLP, solo busca contenido específico en un conjunto muy específico de servidores basados en etiquetas de carga de trabajo, de la misma manera que se aplica la política de segmentación. Para el filtrado de URL, la gran base de datos de características IP se puede mantener en el sistema central de administración de políticas, obtener a través de una conexión LAN de baja latencia cuando sea necesario y almacenarse en caché localmente para búsquedas posteriores. La mayoría de los servidores hablan con el mismo conjunto relativamente pequeño de servidores una y otra vez.

Funciones de NGFW para una solución de microsegmentación

Al agregar características NGFW a microsegmentación solución, uno de los beneficios que más obtiene es que al igual que la política de firewall, las funciones NGFW se aplican quirúrgicamente, precisamente donde las necesita, en lugar de a VLAN completas o subredes en grupo. Una política basada en etiquetas permite al propietario de la aplicación aplicar quirúrgicamente servicios muy específicos, precisamente donde sea necesario en lugar de pintar el centro de datos con un pincel amplio. Las funciones específicas de NGFW se pueden activar sólo para los servidores necesarios y realizar únicamente la inspección requerida con precisión. Esto mantiene el overhead al mínimo absoluto requerido para satisfacer sus necesidades específicas de seguridad y le permite equilibrar la seguridad, el performance y los costos.

Recuerde, el objetivo aquí no es reemplazar sus dispositivos NGFW fronterizos. Más bien, es para llenar selectivamente los vacíos donde las soluciones NGFW existentes no tienen sentido arquitectónico o financiero con un poderoso subconjunto de características NGFW que se ejecutan en los propios servidores. Este enfoque permite a los propietarios de aplicaciones “poseer” su seguridad de salida donde de otro modo no sería posible, así como ofrecer estas características en situaciones que de otro modo serían prohibitivas en cuanto a costos utilizando soluciones tradicionales.

Mirando hacia adelante

Para amarrar esto, miremos aún más hacia el futuro.

TLS 1.3 fue ratificado en 2018 y poco a poco se está convirtiendo en el próximo estándar para web encriptada y otros servicios. Su reacción inicial a esto podría ser, “No es mi problema” o tal vez “¿Y qué?” Yo diría que en realidad es extremadamente relevante. Un NGFW no puede proporcionar la mayoría de los servicios disponibles sin la inspección profunda de paquetes (DPI). Y para que DPI sea significativo de alguna manera, los datos deben estar en texto claro, no encriptados.

Cuando los NGFW llegaron por primera vez al mercado, solo una pequeña fracción del tráfico web estaba encriptado. A medida que pasaba el tiempo, cada vez más tráfico se movía a HTTPS, o tráfico cifrado. Hoy en día, casi el 100% de todo el tráfico web está encriptado y, por lo tanto, no se puede analizar en busca de malware, virus, exfiltración de datos o cualquier otro servidor NGFW. La solución que se desarrolló para esto se llama TLS MiTM (man-in-the-middle).

Configurar TLS MiTM es un poco tedioso, aunque sencillo en concepto. Hay una serie de partes móviles en la solución. Primero, la organización crea un certificado TLS interno. La clave pública se empuja a todos los sistemas (laptops, computadoras de escritorio, servidores, etc.) dentro de la organización, y cada sistema operativo está configurado para confiar en ese certificado y usarlo para cifrar todas las comunicaciones salientes, independientemente del destino. Luego, la clave privada se distribuye a sus dispositivos NGFW perimetrales, que se configuran como proxies web transparentes.

Cuando un usuario (o servidor o cualquier otro dispositivo) realiza una conexión saliente a un sitio web externo, digamos gmail.com para este ejemplo, en lugar de usar el certificado TLS de Google, cifra el tráfico con el certificado interno de la organización. Cuando el perímetro NGFW ve ese tráfico saliente, es capaz de descifrarlo y analizar completamente el contenido del tráfico en virtud de tener una copia de la clave privada. El NGFW termina la conexión interna y origina una nueva conexión TLS a gmail.com usando el certificado de Google, y proxia el contenido de las dos conexiones (la conexión interna desde el interior de la organización a la conexión externa a gmail) y así es capaz de ver y analizar todo el tráfico, aunque esté encriptado.

Si bien es engorroso e intensivo en CPU, este método ha funcionado razonablemente bien para la mayoría de los servicios durante aproximadamente una década utilizando SSL, luego TLS 1.0, 1.1 y 1.2.

Hasta ahora, todo bien. Pero TLS 1.3 cambia el juego. Primero, TLS 1.3 exige Perfect Forward Secrecy, en forma de intercambios de claves DH por conexión. Debido a esto, un dispositivo pasivo no tiene forma de descifrar la carga útil, incluso con acceso a la clave privada en uso. Con TLS 1.3, es obligatorio insertar un dispositivo en la transmisión y proxizar el tráfico. En segundo lugar, TLS 1.3 desprecia los cifrados de menor seguridad, eliminando la capacidad de un dispositivo proxy para degradar una conexión proxy a TLS 1.2, que es una estrategia común que a menudo se emplea para ahorrar en recursos de computación en el NGFW (debido a que los cifrados de menor seguridad generalmente requieren menos computación).

Si la historia de la criptografía nos ha enseñado algo, es que los estándares antiguos y confiables tienden a ser encontrados vulnerables con el tiempo con casi el 100% de certeza. La práctica actual de degradar TLS 1.3 a TLS 1.2 para permitir el descifrado pasivo y/o la degradación para ahorrar recursos está en un temporizador, solo esperando que TLS 1.2 quede obsoleto. Cuando llegue ese día, una gran cantidad de dispositivos de inspección pasiva se convertirán en costosos pisapapeles, mientras que muchas soluciones en línea se verán abrumadas rápidamente al verse obligadas a usar criptografía más costosa computacionalmente.

Un pequeño y sucio secreto del mundo NGFW es que, al menos en el momento de escribir este artículo, su tráfico WebSocket probablemente no esté siendo inspeccionado en busca de amenazas de ningún tipo. ¿Por qué? Porque un NGFW típico no puede descifrar el tráfico en tiempo real. El tráfico WebSocket debe ser visto dentro de su navegador (usando Herramientas de desarrollador) o capturado y descifrado después del hecho usando algo como Wireshark (asumiendo que tiene las claves privadas) para inspeccionar la carga útil. Los WebSockets son cada vez más comunes en las aplicaciones web, ya que la tecnología proporciona una gran solución para que las aplicaciones JavaScript muevan datos de un lado a otro entre su navegador y un servidor web. Literalmente, cualquier cosa se puede mover a través de una conexión WebSocket, y es completamente opaco para su NGFW.

Por último, no olvidemos otras nuevas tecnologías omnipresentes como el uso de QUIC para el tráfico web. Si bien QUIC es una nueva y poderosa herramienta para obtener tráfico a su navegador de manera más rápida y eficiente, no utiliza el cifrado TLS estándar. Esto significa que su NGFW en línea debe bloquear todo el tráfico QUIC (forzando una degradación a TLS) o permitir que el tráfico pase sin inspeccionar. La primera solución reduce la calidad de la experiencia del usuario y la segunda expone a la organización al riesgo. Tampoco es ideal.

El manejo de algunas tareas NGFW a nivel de carga de trabajo ayuda a prolongar la vida útil de la inversión en los dispositivos NGFW existentes. Permite la descarga de cierto porcentaje de procesos computacionalmente costosos al manejarlos por carga de trabajo. Esto permite que el cliente descargue parte de la carga útil de inspección de sus dispositivos de red, lo que retrasa una actualización de firewall que de otro modo sería necesaria y, al mismo tiempo, lleva los beneficios de Zero Trust a partes de su red que de otro modo no tendría sentido técnico o financiero.