Cuatro formas en que la tecnología obsoleta de los WAF antiguos deja tus aplicaciones desprotegidas

El firewall de aplicaciones web (WAF) es una tecnología de toda la vida que, a pesar de su poca efectividad y su escasa popularidad, se ha ido transmitiendo de generación en generación, pasando de los centros de datos a la nube y al entorno informático sin servidores. En el ámbito de la seguridad de las aplicaciones web, seguramente el secreto peor guardado sea este: el WAF antiguo no ha sobrevivido porque sea excelente, sino porque es obligatorio.

El WAF antiguo no ha sobrevivido porque sea excelente, sino porque es obligatorio.

En esta entrada hablaremos de la historia del WAF, descubriremos por qué es omnipresente a pesar de que no siempre funciona como debería y veremos qué puedes hacer al respecto.

El WAF antiguo y su tecnología anticuada

Los WAF tradicionales, basados en el perímetro, utilizan una tecnología anticuada que se creó para ayudar a frenar el aumento de las vulnerabilidades de seguridad de las aplicaciones, cuya frecuencia abrumaba a las organizaciones. Las herramientas de análisis estáticas y dinámicas mostraban cantidades ingentes de errores y los equipos de desarrollo se veían incapaces de solucionar tantísimos problemas de código.

Como medida provisional para resolver este problema, el WAF antiguo permitió filtrar los incontrolables ataques de SQLi, XSS y ejecución de comandos, que amenazaban con consumir todos los recursos disponibles de los equipos de desarrollo y seguridad. La herramienta se usaba con la idea de clasificar inicialmente los errores de la aplicación y los fallos de seguridad para arreglarlos más tarde en el código, en la raíz del problema.

En ese momento, un filtro de seguridad de aplicaciones web improvisado parecía una buena idea. Por supuesto, a veces bloqueaba tráfico legítimo, pero al menos proporcionaba cierta protección en el nivel de la aplicación, un espacio que traía de cabeza a los organismos responsables del cumplimiento. Entonces entró en juegola normativa del sector de las tarjetas de pago (PCI), y el panorama cambió por completo.

El requisito 6.6 de PCI establece que hay que tener un WAF instalado, o bien revisar exhaustivamente el código al hacer cualquier cambio en la aplicación. Como la segunda opción no es nada atractiva, la mayoría de las organizaciones interpreta este requisito como una obligación de tener un WAF. Dicho de otro modo: las partes implicadas en la seguridad no instalaban los WAF porque los creyeran útiles, sino porque querían obtener su certificación de PCI obligatoria. Se puede decir que el PCI hizo que el mercado de los WAF antiguos pasara de ser una idea interesante a adquirir las dimensiones colosales que tiene hoy en día.

Y el WAF antiguo sigue ahí, como una tecnología anticuada respaldada por legalismos más que por su utilidad real, que ofrece una falsa sensación de seguridad sin hacer demasiado por garantizarla. Si eso no te convence de que ya va siendo hora de que te desprendas de tu antiguo WAF, te daré cuatro razones más para buscarle un sustituto.

1. Usar el número mínimo de reglas del WAF ya no sirve

Cuando se implementa un WAF antiguo, es bastante habitual que se acabe bloqueando tráfico legítimo. En el ámbito de la seguridad de las aplicaciones, esto se conoce como «falsos positivos», una denominación que puede parecer inofensiva, pero que se traduce en que los clientes no pueden comprar lo que quieren, cargar las fotos de sus últimas vacaciones o ni siquiera usar las funciones de tus aplicaciones. Una experiencia que puede hacer que cualquiera de tus clientes deje de serlo rápidamente.

Para combatir los falsos positivos de los WAF antiguos, la mayoría de las empresas ejecutan el número mínimo de reglas para salir del paso.

Para combatir los falsos positivos de los WAF antiguos, la mayoría de las empresas ejecutan el número mínimo de reglas para salir del paso. Como resultado, solo se interceptan los ataques más obvios y graves, mientras que todo lo demás consigue atravesar el filtro. Las reglas básicas son fáciles de eludir, de modo que el WAF pierde toda su eficacia.

2. El modo de aprendizaje está reñido con la rapidez

Una de las maneras en que los antiguos WAF intentan reducir los falsos positivos para evitar interrumpir el tráfico válido es a través de un «modo de aprendizaje». En ese modo, el WAF antiguo aprende qué aspecto tiene el tráfico normal en comparación con el tráfico malicioso para poder proteger correctamente. Se podría decir mucho sobre lo difícil que es conseguir que el modo de aprendizaje funcione correctamente, incluso en condiciones perfectas, pero vamos a centrarnos en el verdadero problema de los entornos de producción.

El modo de aprendizaje lleva su tiempo. Los WAF antiguos que necesitan aprender a reconocer el «comportamiento normal» deben revisar una cierta cantidad de tráfico antes de pasar a bloquear activamente todo lo demás. Pueden tardar varias horas en aprender los patrones de tráfico seguro de las aplicaciones.

Cuando se pasa de una metodología en cascada a un modelo de DevOps ágil, la velocidad de despliegue se acelera sin parar. El código de la aplicación cambia semanalmente, a diario o incluso cada hora. Si despliegas el código a un ritmo mínimamente moderno y pones el WAF antiguo en modo de aprendizaje en cada cambio de código, no saldrá de ese modo. Básicamente, porque ningún modo de aprendizaje es capaz de seguir el ritmo de producción cuando se usa con las técnicas modernas de desarrollo de aplicaciones.

3. El modo de supervisión no debe limitarse a cumplir las normas

Que los WAF antiguos han podido sobrevivir por los requisitos legales, y no tanto por su eficacia, no es el único secreto a voces del sector. Tampoco te sorprenderá saber que la mayoría de las empresas nunca ponen su WAF antiguo en modo de bloqueo activo. A fin de cuentas, el modo de bloqueo conlleva un elevado índice de falsos positivos e interrumpe el tráfico legítimo, por lo que solo es recomendable si lo que se busca es interrumpir la aplicación.

Lo ejecutan más bien en modo de supervisión, en el que se observa el tráfico y se registra cualquier evento como un ataque. Cuando hay que hacer una auditoría, se activa el WAF antiguo durante un tiempo y luego vuelve a desactivarse. Claro que, en la práctica, a algunos auditores ni siquiera les importa si lo tienes en modo de bloqueo activo y les basta con que tengas un WAF implementado.

Cuando hay que hacer una auditoría, se activa el WAF antiguo durante un tiempo y luego vuelve a desactivarse.

Ejecutar el WAF en modo de supervisión no es un método de control eficaz, ya que tan solo aporta una falsa sensación de seguridad y da más trabajo al equipo de seguridad, que debe evaluar los eventos registrados. El resultado final es que se gasta dinero donde no es necesario, sin añadir apenas medidas defensivas.

4. Ajustar las reglas de los WAF tradicionales tiene un precio

Si se usa un WAF tradicional, basado en el perímetro, también hay que acostumbrarse a ajustar las reglas para deshacerse de los falsos positivos en cantidades ingentes. La mayoría de los proveedores de WAF tradicionales describen este proceso de mantenimiento necesario de tal forma que resulte aceptable para los clientes que saben que necesitan proteger sus API y aplicaciones en producción. Te venderán un «paquete de servicios» en el que se habla del ajuste como una experiencia exclusiva y precisa. ¿A que suena bien? Pues prepárate a pagar un extra para que otros hagan el trabajo por ti. Y hay otro tipo de proveedores de seguridad que te dirán sin tapujos que tener que realizar ajustes para evitar falsos positivos es algo que se espera de un WAF.

Tanto si se subcontrata como si se gestiona internamente, el ajuste de las reglas de un WAF antiguo puede suponer un coste adicional que las organizaciones suelen pasar por alto al evaluar a los proveedores. Los servicios profesionales pueden ser una ayuda o un lastre, en función de la calidad del personal y la complejidad del ajuste, y la factura puede subir rápidamente si se paga una tarifa por hora. Encargarse del ajuste internamente quizás sea una opción viable al principio, si se cuenta con personal capacitado para hacerlo, pero deja de ser sostenible cuando la base de código de la aplicación se va haciendo más compleja y crece la superficie de ataque. 

No es fácil aprender a usar los WAF que tienen interfaces de usuario de gestión con más de una década de antigüedad. Además, a medida que se despliegan más aplicaciones y API para impulsar el crecimiento y la competitividad de una organización en el mercado, el ajuste del WAF deja de ser una responsabilidad a tiempo parcial de una sola persona para convertirse en una función a jornada completa. Estas nuevas funciones requieren una formación y contratación específicas para gestionar el WAF, lo que supone el uso de personal y un gasto de fondos y recursos del departamento. 

La solución: un WAF de última generación diseñado para proteger la web moderna

No te conformes con limitarte a cumplir las normas. Hay nuevas opciones para proteger el nivel de la aplicación web sin renunciar al cumplimiento: por ejemplo, usando un WAF de última generación (NGWAF) que proteja adecuadamente las aplicaciones. En lugar de limitarte a marcar una casilla para el PCI, puedes defenderte activamente de los 10 principales ataques según OWASP y las apropiaciones de cuentas, estructurar la lógica de negocio y luchar contra los bots, todo ello sin interferir en la actividad legítima de los clientes.