Exploración del uso de la funcionalidad NGFW en un entorno de microsegmentación

Durante casi dos décadas, los firewalls de próxima generación (NGFW) fueron 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 se está volviendo cada vez menos relevante.

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

En la 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, hablaré sobre el escenario "¿qué pasaría si?" de incrustar un subconjunto de 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 funcionan para el tráfico norte-sur, pero tienen problemas con el 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, este tipo de tráfico a menudo se denomina "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 el tráfico que fluye 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 mover 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 poderoso caso de uso para los NGFW empleados en un rol norte-sur, como mencioné en la primera parte. Pero el caso de uso para este-oeste es un poco menos seguro. Esta segunda declaración probablemente te puso los cabellos de punta, así que déjame ser un poco más específico sobre esa declaració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 de 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 funciones. A menudo es difícil justificar la compra de un dispositivo NGFW completo y usar solo la mitad de la funcionalidad, más aún en los casos en que el conjunto de características de NGFW no es obligatorio por ley o regulación.

NGFW para tráfico sur-norte

Esos son 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, controlar el tráfico saliente desde el interior de la red. Los proveedores 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. 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 para que los propietarios de sus aplicaciones internas aplicar controles salientes en el borde de la red.

Mi trabajo es básicamente investigación y desarrollo, con un fuerte enfoque en la parte "R". En ese sentido, hagamos un experimento mental. Por un momento, considere resuelto el problema norte-sur. No se resuelve 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 cambio, pensemos en cómo las redes podrían hacer 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 organizacionales internos que le impiden aprovechar las características NGFW salientes.

Los casos de uso sur-norte y este-oeste son diferentes, pero hay una superposición considerable. Además, muchas características norte-sur simplemente no son relevantes para ninguno de estos. 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 dispositivo completo (o dispositivo virtual) puede ser cuestionable, dado el costo, pero la necesidad es real. Si su red contiene datos PII, HIPPA o PCI , 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 servicios NGFW tradicionales como DLP (Data Loss Prevention) e IDS/IPS (Intrusion Detection/Prevention Service). Incluso si no hay mandato, sigue siendo una buena práctica. El ID de aplicación, en otras palabras, la capacidad de bloquear o permitir el tráfico en función del tipo real de tráfico, en lugar del puerto y el protocolo, también es una herramienta poderosa y deseable para evitar ataques y exfiltración de datos.

Para el caso de uso sur-norte, algunas características adicionales pueden ser útiles. DLP probablemente todavía sea necesario, y el ID de la aplicación 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 en función de la reputación y la geografía de la IP de destino. 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 gran centro de datos.

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 antivirus moderno que se ejecuta dentro del sistema operativo es probablemente más eficiente que una solución basada en la red, por lo que el antivirus basado en la red probablemente no esté en la agenda.

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

Es hora de hablar sobre las participaciones de rendimiento de las características 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 rendimiento respetable. Obviamente, se deduce que se impondría una penalización sustancial del rendimiento a los servidores individuales al implementar la misma funcionalidad. Afortunadamente, esto parece ser uno de esos momentos en los que la intuición se va por la ventana. Hablemos de por qué.

IDS/IPS es un excelente lugar para comenzar. De todos los servicios de 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 de posiblemente Solaris o AIX, si estoy en el cuidado de la salud o la banca). Cada uno de esos 1,000 servidores ejecuta al menos un servicio que querré 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 diferentes vulnerabilidades.

En resumen, estoy observando entre 10,000 y 100,000 firmas de vulnerabilidad para esas mil máquinas. Y estoy buscando señales de ellos en cada paquete que fluye a través de mi dispositivo de red NGFW, en todos los puertos posibles que puedan estar operando. Claramente, esta no es una carga que queramos imponer a todos los servidores del centro de datos.

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

En lugar de buscar de 10,000 a 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 comprender el sistema operativo, qué parches se aplicaron y cuáles no, qué software (y qué versiones de ese software) están instalados y en ejecución, y específicamente en qué puertos se comunican. Buscamos vulnerabilidades específicas del sistema operativo y las versiones de 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.

Se podrían aplicar estrategias similares 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 en función de las etiquetas de carga de trabajo, de la misma manera que se aplica la directiva 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, se puede obtener a través de una conexión LAN de baja latencia cuando sea necesario y almacenar en caché localmente para búsquedas posteriores. La mayoría de los servidores se comunican con el mismo conjunto relativamente pequeño de servidores una y otra vez.

Características de NGFW para una solución de microsegmentación

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

Recuerde, el objetivo aquí no es reemplazar sus dispositivos NGFW de borde. 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 saliente donde de otro modo no sería posible, así como ofrecer estas características en situaciones que de otro modo serían prohibitivas con soluciones tradicionales.

Mirando hacia el futuro

Para atar 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 el sitio web encriptado 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 de alguna manera significativo, los datos deben estar en texto sin cifrar, no encriptados.

Cuando los NGFW llegaron al mercado por primera vez, solo una pequeña fracción del tráfico sitio web estaba encriptado. A medida que pasaba el tiempo, más y 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 sitio 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 un serial de partes móviles en la solución. En primer lugar, la organización crea un certificado TLS interno. La clave pública se envía a todos los sistemas (portátiles, equipos 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 están configurados como proxies sitio 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 NGFW perimetral ve ese tráfico saliente, puede descifrarlo y analizar completamente el contenido del tráfico en virtud de tener una copia de la clave privada. El NGFW finaliza la conexión interna y origina una nueva conexión TLS a gmail.com mediante el certificado de Google, y representa el contenido de las dos conexiones (la conexión interna desde dentro de la organización a la conexión externa a gmail) y, por lo tanto, puede ver y analizar todo el tráfico, aunque esté encriptado.

Si bien es engorroso y requiere mucha CPU, este método funcionó razonablemente bien para la mayoría de los servicios durante aproximadamente una década usando SSL, luego TLS 1.0, 1.1 y 1.2.

Hasta ahora, bien. Pero TLS 1.3 cambia el juego. En primer lugar, 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 secuencia y representar el tráfico. En segundo lugar, TLS 1.3 deja de usar 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 se emplea a menudo para ahorrar recursos informáticos en el NGFW (porque los cifrados de menor seguridad generalmente requieren menos cálculo).

Si la historia de la criptografía nos mostró algo, es que los estándares antiguos y confiables tienden a ser vulnerables con el tiempo con casi un 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, esperando a que TLS 1.2 quede obsoleto. Cuando llegue ese día, muchos dispositivos de inspección pasiva se convertirán en costosos pisapapeles, mientras que muchas soluciones en línea se verán rápidamente abrumadas en virtud de ver obligadas a emplear una criptografía más costosa desde el punto de vista computacional.

Un pequeño secreto sucio del mundo NGFW es que, al menos en el momento de escribir este artículo, es probable que su tráfico de WebSocket 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 de WebSocket debe ver dentro de su navegador (usando herramientas de desarrollo) o capturar y descifrar luego del hecho usando algo como Wireshark (suponiendo que tenga las claves privadas) para inspeccionar la carga útil. Los WebSockets son cada vez más comunes en las aplicaciones sitio 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 sitio web. Literalmente, cualquier cosa se puede mover a través de una conexión WebSocket, y es completamente opaca para su NGFW.

Por último, no olvidemos otras nuevas tecnologías omnipresentes, como el uso de QUIC para el tráfico sitio 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 emplea 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 a riesgos. Ninguno de los dos es ideal.

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