Azure WAF: Detection no es proteccion real

El error que cometen muchos equipos tech: confundir monitoreo con proteccion

Si tu startup ya tiene un Web Application Firewall (WAF) desplegado en Azure, probablemente sientas que tu aplicacion esta protegida. Pero hay una trampa silenciosa que afecta a muchos equipos de desarrollo: activar el WAF en modo Detection y asumir que eso es suficiente. Spoiler: no lo es. Detectar un ataque no es lo mismo que bloquearlo, y esa diferencia puede costarle caro a tu negocio.

En este articulo exploramos que hace exactamente el modo Detection de Azure WAF, por que puede generar una falsa sensacion de seguridad, como leer correctamente los logs y cual es el camino mas seguro hacia la proteccion real en produccion.

Que hace (y que NO hace) el modo Detection

El modo Detection de Azure WAF analiza el trafico entrante a tu aplicacion y registra cualquier solicitud que coincida con reglas de amenaza —como inyecciones SQL, ataques XSS o anomalias en headers— pero deja pasar todo el trafico sin bloquearlo. Absolutamente todo.

Es, en esencia, una camara de seguridad sin guardia: ve lo que ocurre, lo anota en el log, pero no impide que el intruso entre.

Lo que si hace: genera registros detallados de reglas activadas, puntuaciones de anomalia, IPs de origen y URIs afectadas.
Lo que NO hace: bloquear solicitudes maliciosas, proteger datos de usuarios ni cumplir activamente con politicas de seguridad como PCI DSS.

Segun la documentacion oficial de Microsoft, el modo Detection esta disenado exclusivamente para la fase de ajuste inicial (tuning), no para produccion a largo plazo.

Modo Detection vs. Modo Prevention: las diferencias clave

Entender la diferencia entre ambos modos es fundamental para cualquier founder o tech lead que gestione infraestructura en la nube:

Modo Detection

Monitorea trafico y registra coincidencias con reglas (SQLi, XSS, etc.).
Calcula puntuaciones de anomalia acumulativas por solicitud.
Permite el paso de todo el trafico, incluso el potencialmente malicioso.
Ideal para: pruebas iniciales, identificacion de falsos positivos y ajuste de reglas.

Modo Prevention

Bloquea activamente las solicitudes que superan el umbral de anomalia o coinciden con reglas criticas.
Devuelve un error 403 Forbidden al atacante.
Registra tanto los eventos bloqueados como los detectados.
Requerido en entornos de produccion y obligatorio para cumplir con PCI DSS Requisito 6.6.

En el sistema de puntuacion de anomalias (anomaly scoring mode), cada regla activada suma puntos al score de la solicitud: una regla critica aporta 5 puntos, una de nivel error 4 puntos, warning 3 puntos y notice 2 puntos. En modo Detection, aunque la solicitud alcance o supere el umbral, no se bloquea. En modo Prevention, si se bloquea.

El riesgo real: la falsa sensacion de seguridad

El problema no es usar el modo Detection en si mismo, sino quedarse en el indefinidamente. Es un patron comun en equipos que lanzan rapido: configuran el WAF, ven logs activos y asumen que el sistema esta protegiendo la aplicacion. Pero esos logs solo son un diario de amenazas que ya llegaron.

Imagina que tienes una startup de fintech con datos sensibles de usuarios. Si tu WAF esta en modo Detection y un atacante lanza una campana de inyeccion SQL, Azure WAF la registrara en detalle… mientras el ataque se ejecuta en tu base de datos. Los logs son hermosos. Tu aplicacion, comprometida.

Ademas, permanecer en modo Detection puede generar problemas serios de cumplimiento normativo. Para entornos que procesan datos de tarjetas de pago, PCI DSS exige que el WAF este en modo activo de prevencion, no solo de monitoreo.

Como interpretar correctamente los logs de Azure WAF

Antes de migrar a modo Prevention, es imprescindible analizar los logs con criterio. Una migracion apresurada puede generar falsos positivos que bloqueen trafico legitimo y degraden la experiencia de tus usuarios.

Campos clave a revisar en los logs

RuleId: identifica la regla activada (ej. 942xxx = inyeccion SQL, 941xxx = XSS).
Action: muestra si la accion fue Detected (modo Detection) o Blocked (modo Prevention).
AnomalyScore: puntuacion total acumulada por la solicitud.
ClientIP y RequestUri: origen y destino del trafico sospechoso.
Message: descripcion de la regla que se activo.

Herramientas recomendadas para el analisis

Azure Monitor Logs / Log Analytics Workspace: permite filtrar por action, IP, regla y periodo de tiempo.
Azure Workbooks: dashboards visuales preconfigurados para WAF.
KQL (Kusto Query Language): consultas avanzadas para detectar patrones de ataque o falsos positivos sistematicos.

El objetivo del analisis es distinguir entre trafico malicioso real y trafico legitimo que activa reglas por error (falsos positivos). Una vez identificados los falsos positivos, se crean exclusiones especificas antes de activar el modo Prevention.

Plan de accion: como migrar de Detection a Prevention de forma segura

La migracion no debe hacerse de un dia para otro. Aqui tienes un plan estructurado que recomiendan tanto Microsoft como expertos del ecosistema cloud:

Paso 1: Analisis inicial (1-2 semanas)

Ejecuta el WAF en modo Detection y recopila logs reales de produccion. Identifica patrones: que reglas se activan con mas frecuencia, desde que IPs y con que URIs. Clasifica cada evento como amenaza real o falso positivo.

Paso 2: Ajuste de reglas y exclusiones

Para cada falso positivo identificado, crea una exclusion especifica en el WAF. Evita desactivar reglas completas; mejor excluir campos o rutas concretas. Microsoft recomienda usar las reglas OWASP CRS 3.2 o superior con nivel de paranoia PL1 o PL2 como punto de partida para minimizar falsos positivos.

Paso 3: Pruebas en entorno staging

Antes de activar Prevention en produccion, replica la configuracion en un entorno de staging y ejecuta pruebas de carga y de seguridad. Verifica que el trafico legitimo fluye sin interrupciones.

Paso 4: Activacion en Prevention con monitoreo intensivo

Activa el modo Prevention en produccion durante horas de bajo trafico. Mantén monitoreo intensivo las primeras 24-48 horas. Define un plan de rollback claro (retorno a Detection) si detectas bloqueos inesperados.

Paso 5: Infraestructura como codigo

Documenta todas las exclusiones y configuraciones en ARM Templates, Bicep o Terraform. Esto evita perder el ajuste manual en futuras actualizaciones del WAF o del Application Gateway.

Azure WAF y cumplimiento con PCI DSS

Para startups que operan en sectores regulados —fintech, healthtech, e-commerce— el cumplimiento normativo no es opcional. El Requisito 6.6 de PCI DSS establece que las organizaciones deben proteger las aplicaciones web que procesan datos de tarjetas de pago mediante un WAF configurado para inspeccionar y bloquear trafico malicioso.

Esto significa que un WAF en modo Detection no cumple con PCI DSS, ya que no bloquea activamente los ataques. Si tu startup esta en proceso de certificacion o ya esta certificada, asegurate de que todos los Application Gateways que exponen aplicaciones con datos de tarjetas tengan el WAF en modo Prevention.

Herramientas como Prisma Cloud de Palo Alto Networks pueden escanear automaticamente tu entorno Azure y alertarte si algun Application Gateway no tiene el WAF configurado en el modo correcto, simplificando las auditorias de cumplimiento.

Buenas practicas adicionales para 2026

Mas alla del modo de operacion, hay otras configuraciones que potencian la seguridad de tu Azure WAF:

Actualiza regularmente los rulesets: usa siempre la version mas reciente de OWASP CRS disponible en Azure. Las reglas antiguas no cubren vectores de ataque modernos.
Integra con Microsoft Defender for Cloud: recibe recomendaciones proactivas y alertas de seguridad correlacionadas con el WAF.
Habilita proteccion DDoS: el WAF protege contra ataques de capa 7 (aplicacion), pero para volumetria y capa 3/4 necesitas Azure DDoS Protection complementario.
Revisa reglas personalizadas: las custom rules con accion Log no bloquean en prevention mode si no estan bien configuradas. Verifica el comportamiento esperado tras cada cambio.
Establece alertas en Azure Monitor: configura alertas cuando el numero de eventos bloqueados supere umbrales definidos para detectar campanas de ataque en tiempo real.

Conclusion

El modo Detection de Azure WAF es una herramienta valiosa durante la fase de ajuste, pero dejarlo activo en produccion es como instalar una alarma de incendios sin rociadores: sabes que hay fuego, pero no lo apagas. La proteccion real llega con el modo Prevention, bien configurado y respaldado por un analisis riguroso de logs y exclusiones.

Para los founders y tech leads que gestionan infraestructura cloud, el mensaje es claro: no basta con desplegar el WAF; hay que configurarlo correctamente, mantenerlo actualizado y asegurarse de que esta activamente bloqueando amenazas. Tu aplicacion, tus usuarios y tus obligaciones de cumplimiento lo exigen.

Si tu startup maneja datos sensibles o esta en camino de certificacion PCI DSS, este no es un tema que puedas postergar. El costo de un incidente de seguridad —en reputacion, multas y tiempo de recuperacion— siempre supera al de una buena configuracion preventiva.

Descubre como otros founders implementan estas soluciones de seguridad cloud y comparte tus aprendizajes con nuestra comunidad.

Aprender con founders