Hace muchos años, cuando la World Wide Web era joven y mi vena nerd era fuerte, recuerdo haber armado una PC y configurarla como servidor web. En aquellos emocionantes días pioneros, era todo un logro tener mi propia dirección IP en internet y servir mis propias páginas web desde mi servidor Apache directamente al mundo. Muy divertido.

También recuerdo mirar los registros del servidor con horror mientras me desplazaba por páginas y páginas de intentos fallidos de inicio de sesión y, presumiblemente, de intentos de pirateo. Había cerrado todo bastante bien desde el punto de vista de la seguridad, pero aún así, solo hubiera bastado una vulnerabilidad en un software sin parchear para que ocurriera una brecha, y a partir de ahí, todo sería posible.

Incluso hoy, muchos proveedores de servicios de internet te permiten aprovisionar tu propio servidor, si te sientes lo suficientemente valiente. Por supuesto, los riesgos no eran altos para mí en casa, pero sabiendo lo que sabemos ahora sobre el crecimiento de los ataques de ransomware y cómo la IA los facilita, ninguna organización se atrevería a hacer algo así en 2024.

En aquel entonces, había creado una superficie de ataque obvia y abierta. Las herramientas estaban (y aún están) disponibles para escanear rangos de direcciones IP en cualquier red e identificar puertos abiertos. En mi caso, los puertos 22, 80 y 443 estaban abiertos para servir páginas web y permitirme administrar mi servidor de forma remota. Cada puerto abierto es un conducto potencial hacia el corazón del dispositivo anfitrión, por lo que deberían eliminarse siempre que sea posible.

Puertos abiertos, VPN y negocios

Desde que el trabajo remoto en línea se convirtió en una posibilidad real a principios de la década de 2000, las organizaciones han intentado protegerse a sí mismas y a sus empleados mediante la adopción de tecnología VPN para cifrar el tráfico entre un dispositivo remoto y un concentrador VPN en la oficina central, permitiendo a los empleados acceder a servicios como correo electrónico, archivos y servidores de impresión. Incluso cuando estos servicios se convirtieron en soluciones basadas en la nube como Gmail y Dropbox, muchas organizaciones dirigían ese tráfico a través de una VPN para aplicar políticas de acceso de TI. Esto no solo solía conducir a una ruta ineficiente desde el trabajador remoto a sus aplicaciones, sino que también presentaba un grave riesgo de seguridad.

A medida que el rendimiento y la fiabilidad de internet crecieron, también vimos la llegada de las VPN de sitio a sitio, que resultaron ser una alternativa atractiva a las conexiones basadas en circuitos mucho más caras que habían sido tan frecuentes, como MPLS. Una gran cantidad de organizaciones continúan dependiendo de una red de área extensa (WAN) virtual construida sobre VPN. Desafortunadamente, como dice el viejo refrán, no existe el almuerzo gratis.

Cada cliente VPN o sitio que utiliza internet como su columna vertebral necesita una dirección IP a la que conectarse, un puerto abierto a través del cual conectarse y, bueno, ya se ve por dónde va esto. No todas las soluciones VPN tienen una falla activa, así como, afortunadamente, mi servidor Apache no la tenía en ese momento. Dicho esto, el software es falible, y la historia ha demostrado este hecho en numerosas ocasiones en las que se descubren y explotan vulnerabilidades en productos VPN. Solo el mes pasado, se descubrió una falla fatal en los servicios VPN de Ivanti, dejando a miles de usuarios y organizaciones abiertos a ataques. Los hackers buscan día y noche vulnerabilidades como estas para explotarlas, y la IA solo les facilita la vida.

Zscaler es diferente

Zscaler Zero Trust Exchange™ funciona de una manera fundamentalmente diferente: no se requiere VPN para conectarse de forma segura. En su lugar, las conexiones a través de internet (o incluso desde una red administrada) se controlan en múltiples niveles. Un agente en tu dispositivo crea un túnel TLS hacia la nube de Zscaler, que acepta conexiones solo de inquilinos conocidos (o clientes de Zscaler). Este túnel está autenticado mutuamente y cifrado entre el agente y la nube de Zscaler. El individuo y su(s) dispositivo(s) también deben ser identificados como parte del proceso. En resumen, no es posible simplemente hacer una conexión TLS a Zscaler.

Una vez que un usuario aprobado de un cliente conocido con un dispositivo reconocido se conecta a Zscaler, aún se le impide moverse lateralmente por la red, como ocurre con las VPN. Con Zscaler, no hay un rango de IP al que el usuario tenga acceso. En su lugar, cada intento de conexión debe ser autorizado, siguiendo los principios de cero confianza. Un usuario tiene acceso solo a las aplicaciones para las que ha sido autorizado. Con este marco, incluso si una organización fuera atacada con éxito, el radio de explosión sería limitado. No se puede decir lo mismo de la seguridad basada en redes.

Aquí está la conclusión: las VPN y los cortafuegos que las respaldan nos sirvieron bien durante mucho tiempo, pero los desafíos que conlleva mantener una postura de seguridad construida sobre estas tecnologías heredadas son tan grandes que ahora es un riesgo material para el negocio utilizarlas. Basta con encender las noticias durante unos minutos para recordarlo. Las redes se construyeron fundamentalmente para habilitar la conectividad, y añadir seguridad a estas redes es una batalla cuesta arriba para poner los obstáculos adecuados en el camino de esa conectividad. Esta es la razón por la que cada vez más organismos públicos y organizaciones privadas están dando la vuelta a esta idea y adoptando una arquitectura de cero confianza que proporciona acceso solo a una entidad aprobada, en un dispositivo aprobado, a las aplicaciones a las que tiene derecho.

Más información en Zscaler.com/security