¿Alguna vez te has preguntado cuál es la eficacia real de tu WAF (Firewall de aplicación web)? ¿Te has preguntado si de verdad detiene los ataques? ¿Cuántos falsos positivos genera? ¿Un cambio reciente mejoró o afectó negativamente las capacidades de detección existentes?
Gran parte de la tecnología WAF es bastante difícil de administrar, con largas listas de expresiones regulares que realmente nadie disfruta manteniendo. Así que, cuando partes de una posición negativa, es normal que este tipo de preguntas te hagan pensar en no usar un WAF en absoluto.
Dedicamos este artículo, pues, a un marco de eficacia del WAF que hemos ideado para hacer frente a dichas preguntas. El marco proporciona una forma estandarizada de medir la eficacia de las capacidades de detección de un WAF a través de la verificación y validación continuas. Ayuda a identificar carencias y crea una vía para comunicar mejoras y tareas de mantenimiento. Además, incorpora evaluaciones de ataques simulados para probar diferentes tipos de ataque y extrae los resultados en forma de puntuaciones generales. Estas puntuaciones se incorporan a un flujo de trabajo de mejora continua que se puede usar para comprobar la eficacia en momentos puntuales o para analizar su evolución a lo largo del tiempo.
Nuestra estrategia
Un WAF inspecciona el tráfico HTTP/S antes de que llegue a un servidor de aplicaciones. Podríamos decir que un WAF es el intermediario entre una aplicación y un cliente que analiza toda la comunicación entre ambos. Supervisa el tráfico sospechoso y anómalo, y protege contra los ataques bloqueando las peticiones según reglas específicas para que el tráfico no deseado nunca llegue a tu aplicación.
Una petición HTTP/S incluye:
Un dominio (como fastly.com)
Un recurso (como /cat.png)
Un método (GET, POST, PUT, etc.)
Encabezados (información adicional enviada al servidor, que los atacantes pueden utilizar para introducir elementos maliciosos)
También hay un cuerpo de petición opcional; por norma general, las peticiones GET no tienen cuerpo, mientras que las peticiones POST —que podrían enviar información legítima o inyectar elementos no deseados— sí suelen incluir cuerpo.
A modo de ejemplo, a continuación podemos ver una petición HTTP 1.1 GET para fastly.com/ES/cat.png:
Y este es un ejemplo de petición POST con un cuerpo JSON:
Ya sea la URL, el cuerpo, las cookies u otros encabezados HTTP, los atacantes siempre buscan lugares en una petición para preparar el terreno para la explotación. Por eso, un principio fundamental del marco es comprobar si se detectan cargas útiles en diferentes puntos de una petición.
Como con toda tecnología de seguridad, cuando se refuerzan los métodos de detección, los atacantes buscan formas de sortear las detecciones para poder continuar logrando sus objetivos. Con los WAF, un método de elusión popular es codificar una carga útil de una manera que evite la detección. Por eso también incluimos pruebas que incorporan una mezcla de técnicas de codificación. Inyectamos cada carga útil predefinida en cada posición de carga útil, y las versiones sin procesar y codificadas de la petición se envían al objetivo, lo que proporciona un medio valioso para probar la cobertura de detección incluso ante métodos de elusión.
Pero, por supuesto, un hada mágica de cargas útiles no deja caer cargas útiles del cielo, y las cargas útiles relevantes pueden cambiar con el tiempo a medida que evolucionan los métodos de ataque. Sugerimos PayloadsAllTheThings, PortSwigger, Nuclei, exploit-db y Twitter como punto de partida para recopilar una lista de cargas útiles, así como para actualizar periódicamente tus listas de cargas útiles.
No necesitas una aplicación vulnerable para probar la eficacia de un WAF. El objetivo es medir la eficacia de las capacidades de detección de un WAF, no comprobar si hay vulnerabilidades en las propias aplicaciones. Al fin y al cabo, el objetivo ideal de un WAF es que las vulnerabilidades de tus aplicaciones ya no provoquen incidentes; validar que tu WAF protege contra tipos de ataque significa que ya no tienes que preocuparte por detalles menores, como vulnerabilidades específicas. Por lo tanto, para este propósito basta con usar un simple servicio de petición y respuesta HTTP como https://httpbin.org.
Con cada tipo de ataque, probamos dos casos diferentes para evaluar la eficacia de WAF: verdaderos positivos y falsos positivos. Una prueba positiva verdadera determina si las cargas útiles de ataque se identifican correctamente. Una prueba de falsos positivos determina si las cargas útiles aceptables se identifican incorrectamente.
Para determinar si el WAF identifica de forma correcta una petición, examinamos el código de estado de respuesta. La mayoría de las soluciones de WAF deberían admitir la creación de un código de estado de respuesta personalizado para peticiones bloqueadas (para ver un ejemplo, lee nuestra documentación al respecto). Si tu solución de WAF no es capaz de establecer códigos de respuesta personalizados, vale la pena reconsiderar esa inversión.
En el contexto de nuestro marco de eficacia del WAF, buscamos específicamente la recepción de un código de respuesta 406 Not Acceptable cuando se bloquea una petición. En un caso de prueba de verdadero positivo, recibir un código de respuesta distinto de 406 se considera un falso negativo. En cambio, en un caso de prueba de falso positivo, recibir un código de respuesta distinto de 406 se considera un verdadero negativo. Estos resultados se utilizan para calcular una puntuación de eficacia por tipo de ataque; estas puntuaciones se agregan después en una puntuación general de la eficacia del WAF en todos los tipos de ataque.
Evaluación de resultados
Una vez que generas puntuaciones de eficacia individuales y totales, ¿cómo aplicas esas métricas para diseñar un plan de acción? A la hora de evaluar estos resultados, es importante tener presentes las prioridades de tu organización. ¿Prefiere tu organización maximizar el tráfico a su aplicación, aunque algunos ataques pasen desapercibidos; o prefiere bloquear todos los ataques posibles, aunque eso signifique una reducción del tráfico? Por lo que hemos visto entre nuestros clientes, la preferencia suele ser maximizar el tráfico: una reducción en el tráfico puede afectar a los ingresos, el peor impacto desde el punto de vista comercial.
En la práctica, es imposible contar con una protección infalible contra los ataques web, a menos que bloquees todas y cada una de las peticiones, lo cual anula el propósito fundamental de ejecutar una aplicación en Internet. Por eso, encontrar el equilibrio adecuado entre los falsos positivos y los falsos negativos es un factor clave para determinar la eficacia de una solución de WAF. Toda herramienta de seguridad tiene falsos positivos y falsos negativos. Si fuera posible estar 100 % seguros en todos los casos, la seguridad ya estaría resuelta.
Cuanto mayor sea la tasa de falsos positivos, más probable es que detectes un ataque, pero el tráfico legítimo se identificará incorrectamente como un ataque, un problema que no hará más que agravarse en el modo de bloqueo. Por si esto fuera poco, un falso positivo es como una falsa alarma. Por naturaleza, las personas empezarán a dejar de prestar atención a las alertas tras suficientes falsos positivos, lo que no solo aumenta la probabilidad de que el tráfico de ataques reales quede sin atender, sino que también erosiona el retorno de la inversión de tu WAF. También hay un precio cognitivo que pagar: lidiar con falsas alarmas provoca agotamiento, lo que dificulta que las personas rindan bien y puede causar una mayor rotación en los equipos.
Por otro lado, una mayor tasa de falsos negativos implica una menor probabilidad de falsos positivos, lo que da lugar a alertas de alta fiabilidad, pero también significa que hay una mayor probabilidad de que no se detecte tráfico de ataque real.
Para tener en cuenta la disparidad entre estas clases de resultados negativos y positivos, nuestro marco de eficacia del WAF incorpora una métrica llamada «precisión equilibrada». La precisión equilibrada tiene en cuenta el desequilibrio entre clases y es una buena medida cuando te resulta indiferente predecir correctamente los casos negativos y positivos. Tu trabajo consiste en utilizar estas métricas con sensatez según se aplique a tu negocio y a los sistemas que proteges. Repasaremos cómo se calcula la precisión equilibrada en una sección más adelante.
Automatizar el trabajo pesado
Las pruebas manuales distan mucho de ser fáciles y pueden convertirse rápidamente en una tarea inviable cuando se intenta tener en cuenta todas las formas de probar y medir los resultados. Esto es especialmente cierto cuando se trabaja con grandes conjuntos de datos de cargas útiles de ataque. Las pruebas deben ser reproducibles y flexibles, lo que te permite centrarte en los resultados para adaptar tu estrategia de seguridad de aplicaciones web en función de pruebas tangibles.
Con ese fin, elegimos un proyecto de código abierto llamado Nuclei como base del marco. Nuclei se encarga de muchas de las tareas repetitivas, manuales y pesadas de las pruebas mediante el uso de sencillas plantillas basadas en YAML. Las plantillas de Nuclei definen cómo se enviarán y procesarán las peticiones. También son totalmente configurables, por lo que puedes configurar y definir cada aspecto de las peticiones que se enviarán.
Dado que obtener nuevos conocimientos es vital para impulsar los ciclos de retroalimentación, todas las peticiones se registran y almacenan en formato JSON. Los registros incluyen pares de petición/respuesta y metadatos adicionales. Puedes usar estos Logs para crear paneles, comparaciones históricas y otros conocimientos que te ayuden a mejorar tu estrategia de WAF. Como ejemplo, cargamos los resultados en un bucket de Google Cloud Storage (GCS), que sirvió como conjunto de datos para crear una tabla en BigQuery; a partir de ahí, conectamos los datos a Data Studio para generar informes informativos con puntuaciones.
Dado que la automatización permite la escalabilidad y la repetibilidad, y te ahorra a ti y a tu equipo tareas tediosas, recomendamos unir estos pasos para crear un proceso de CI/CD para realizar pruebas de eficacia del WAF. Puedes definir un flujo de trabajo con los siguientes pasos:
Crea tu objetivo de prueba
Ejecuta pruebas de eficacia
Guardar los resultados en el backend que elijas
Generar informes
Perfeccionar y repetir al ritmo que prefieras
Primeros pasos
Para compartir esta funcionalidad con la comunidad de seguridad en general, el equipo de investigación de seguridad de Fastly creó un proyecto de código abierto llamado wafefficacy, que incluye el código inicial y las plantillas que necesitas para empezar. El proyecto proporciona ejemplos estándar de ejecución de comandos (cmdexe), inyección SQL (sqli), recorrido (traversal) y secuencias de comandos entre sitios (xss) — lo que garantiza que puedas iniciar de inmediato pruebas de eficacia para los principales tipos de ataques.
Hay dos requisitos que comprobar antes de realizar una prueba de eficacia:
El WAF que vas a probar debe estar configurado para bloquear ataques
Se debe establecer un código de estado de respuesta para cuando se bloquee una petición. Por defecto, wafefficacy comprueba la recepción de 406 Not Acceptable.
Una vez que hayas completado la configuración inicial, puedes ejecutar el binario ejecutable desde el directorio del proyecto proporcionando una URL o un host de destino:./wafefficacy run -u https://example.com
Cuando se complete la evaluación, el script mostrará los resultados de la puntuación en la siguiente salida estándar:
Puntuación de eficacia
Analicemos cómo calculamos las puntuaciones de eficacia utilizando la precisión equilibrada como métrica.
Empezamos con una matriz de confusión:
En lo anterior, «positive» o «negative» en TP/FP/TN/FN se refiere a la predicción realizada, no a la clase real. (Por tanto, un «falso positivo» es un caso en el que predijimos erróneamente un positivo.)
La precisión equilibrada se basa en dos métricas de uso común:
Sensibilidad (también conocida como la proporción de verdaderos positivos) responde a la pregunta: «¿Cuántos de los casos positivos he detectado?»
La especificidad (también conocida como proporción de verdaderos negativos o 1 - proporción de falsos positivos) responde a la misma pregunta: «¿Cuántos de los casos negativos he detectado?»
Usemos un ejemplo para ilustrar cómo la precisión equilibrada puede ser un mejor indicador de las detecciones en un contexto de clases desequilibradas. Supongamos que simulamos ataques por inyección de código SQL contra un WAF y obtenemos los resultados que se muestran en la siguiente matriz de confusión:
Esta matriz de confusión ilustra que, de 750 casos de verdaderos positivos de prueba, 700 de ellos se señalaron como verdaderos positivos, mientras que 50 se señalaron como falsos negativos. Además, de 105 casos de falsos positivos de prueba, 5 de ellos se señalaron como falsos positivos y 100, como verdaderos negativos.
Usando esta información, a continuación tenemos el cálculo de precisión equilibrada:
Según el cálculo de la precisión equilibrada, el WAF tiene aproximadamente un 94,3 % de efectividad a la hora de proteger contra ataques por inyección de SQL.
A modo de comparación, supongamos que probamos otro WAF y que los resultados de falsos positivos se invirtieron. Por ejemplo, de 105 casos de prueba de falsos positivos, 100 se señalaron como falsos positivos, mientras que 5 se señalaron como verdaderos negativos.
Así, el porcentaje de especificidad cambiaría de la siguiente manera:
Lo que también cambiaría el porcentaje de precisión equilibrada de la siguiente manera:
De acuerdo con la precisión equilibrada, podemos afirmar con rotundidad que el primer WAF funciona mejor (94,3 %) que el segundo (49,1 %) a la hora de proteger ante ataques por inyección de SQL.
Resumen
Es mejor que pongas a prueba tu seguridad antes de que alguien más lo haga. Nuestro marco de eficacia del WAF sigue la idea de verificación y validación continuas. Mediante el uso de simulaciones automatizadas de ataques, valida los controles de seguridad técnica, identifica brechas y ofrece una manera de informar y medir la eficacia de la herramienta. De hecho, se puede aplicar la misma metodología con cualquier herramienta de seguridad importante para tu empresa o tus sistemas.
Realizar pruebas de eficacia de esta manera es una forma de introducir pruebas controladas y seguras que te permiten observar hasta qué punto tus controles responderán bien en condiciones reales. Puede ser una herramienta extremadamente valiosa para introducir un bucle de retroalimentación que ayude a entender si un control se implementó de forma correcta y eficaz.
Te animamos a que aproveches nuestro proceso y herramientas para comprender mejor y, a poder ser, aumentar la efectividad de tu WAF.
Si quieres obtener más información sobre cómo podemos ayudarte con tus necesidades de seguridad para aplicaciones web, consulta nuestra descripción general de productos de seguridad. Y si estás interesado en trabajar con nosotros, echa un vistazo a nuestras ofertas de trabajo.
El manual de seguridad de aplicaciones nativas en la nube
Comprende las técnicas cada vez más sofisticadas que utilizan los atacantes para dirigirse a las aplicaciones web Enterprise y cómo prevenirlas. Este documento guía a los equipos de ingeniería, operaciones y seguridad con el «cómo» y el «por qué» de la seguridad de aplicaciones nativa de la nube. Descargar el libro electrónico