Si tienes Azure WAF activado y en modo Detection, te traigo una mala noticia: tu aplicación no está protegida. Está monitoreada. Y esa diferencia, que parece un matiz técnico, puede costarle la vida a tu startup si llega el ataque equivocado en el momento equivocado.
Es uno de los errores más silenciosos del ecosistema cloud: un equipo configura el Web Application Firewall en Azure, ve los logs llenos de actividad, siente que el sistema está funcionando, y sigue adelante. Pero el modo Detection no bloquea nada. Registra todo, sí. Bloquea, no.
¿Qué hace realmente el modo Detection?
El modo Detection de Azure WAF analiza el tráfico entrante a tu aplicación y registra cada solicitud que coincida con patrones de amenaza —inyecciones SQL, ataques XSS, anomalías en headers HTTP— pero deja pasar absolutamente todo el tráfico sin intervenir.
La metáfora es exacta: es una cámara de seguridad sin guardia. Ve lo que ocurre, lo anota con lujo de detalles en los logs, pero no impide que el intruso entre, tome lo que quiere, y salga.
Según la documentación oficial de Microsoft, el modo Detection está diseñado exclusivamente para la fase inicial de ajuste (tuning): observar el tráfico, identificar falsos positivos, calibrar las reglas. No está diseñado como solución permanente en producción.
¿Lo que sí hace? Genera registros detallados: reglas activadas, IPs de origen, URIs afectadas, puntuaciones de anomalía. ¿Lo que no hace? Bloquear una sola solicitud maliciosa, proteger los datos de tus usuarios, ni cumplir activamente con PCI DSS.
Detection vs. Prevention: la diferencia que importa
El sistema de puntuación de anomalías de Azure WAF funciona así: cada regla activada suma puntos al score de la solicitud. Una regla crítica aporta 5 puntos, una de nivel error 4 puntos, una warning 3 puntos, una notice 2 puntos. Cuando el score supera el umbral configurado (por defecto, 7 puntos), el sistema debería actuar.
La diferencia entre modos:
- Modo Detection: analiza el tráfico, calcula puntuaciones, registra coincidencias con reglas (SQLi, XSS, etc.) y deja pasar todo. Ideal para pruebas iniciales e identificación de falsos positivos.
- Modo Prevention: bloquea activamente las solicitudes que superan el umbral o coinciden con reglas críticas. Devuelve un error 403 Forbidden al atacante. Registra tanto los eventos bloqueados como los detectados. Requerido en producción.
Imagina una startup fintech con datos sensibles de usuarios. WAF en modo Detection. Un atacante lanza una campaña de inyección SQL. Azure WAF la registra con lujo de detalles: IP de origen, URI afectada, reglas activadas, puntuación perfecta de 15 puntos. Mientras tanto, el ataque se ejecuta en tu base de datos. Los logs son hermosos. Tu aplicación, comprometida.
El problema de cumplimiento: PCI DSS no acepta el modo Detection
Para startups en sectores regulados —fintech, healthtech, e-commerce que procesa pagos— el problema va más allá de la seguridad práctica. 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 tráfico maliciosos.
Un WAF en modo Detection no cumple con PCI DSS. Punto. Si tu startup está en proceso de certificación o ya la tiene, y tienes Application Gateways en modo Detection frente a aplicaciones con datos de tarjetas, tienes un problema de compliance que puede costarte la certificación.
Cómo leer los logs antes de migrar (y evitar romper todo)
La migración de Detection a Prevention no se hace de un día para otro si quieres evitar bloquear tráfico legítimo. Antes de activar Prevention, necesitas analizar los logs con criterio para identificar falsos positivos.
Los campos clave a revisar en los logs de Azure WAF:
- RuleId: identifica la regla activada. Las reglas 942xxx indican inyección SQL; las 941xxx, ataques XSS.
- Action: muestra si fue “Detected” (modo Detection) o “Blocked” (modo Prevention).
- AnomalyScore: puntuación total acumulada por la solicitud.
- ClientIP y RequestUri: origen y destino del tráfico sospechoso.
- Message: descripción de la regla que se activó.
Para el análisis, las herramientas más útiles son Azure Monitor Logs / Log Analytics Workspace (filtra por acción, IP, regla y período de tiempo), Azure Workbooks (dashboards visuales preconfigurados para WAF), y KQL (Kusto Query Language) para consultas avanzadas que detecten patrones de ataque o falsos positivos sistemáticos.
Plan de migración segura: de Detection a Prevention
Microsoft y los expertos del ecosistema cloud recomiendan un proceso estructurado en cinco pasos:
- Paso 1 — Análisis inicial (1-2 semanas): recopila logs reales de producción en modo Detection. Identifica qué reglas se activan con más frecuencia, desde qué IPs y con qué URIs. Clasifica cada evento como amenaza real o falso positivo.
- Paso 2 — Ajuste de reglas y exclusiones: para cada falso positivo, crea una exclusión específica. No desactives reglas completas; mejor excluir campos o rutas concretas. Usa reglas OWASP CRS 3.2 o superior con nivel de paranoia PL1 o PL2 como punto de partida.
- Paso 3 — Pruebas en staging: replica la configuración en un entorno de staging y ejecuta pruebas de carga y seguridad. Verifica que el tráfico legítimo fluye sin interrupciones.
- Paso 4 — Activación en Prevention con monitoreo intensivo: activa el modo Prevention durante horas de bajo tráfico. Mantén monitoreo intensivo las primeras 24-48 horas con un plan de rollback claro (retorno a Detection) si detectas bloqueos inesperados.
- Paso 5 — Infraestructura como código: documenta todas las exclusiones en ARM Templates, Bicep o Terraform. Esto evita perder la configuración en futuras actualizaciones del WAF.
Por qué importa
El modo Detection es una trampa cómoda. Te da la sensación de tener seguridad sin el costo de la fricción que implica gestionar falsos positivos. Pero esa comodidad es exactamente el riesgo.
En 2025, el coste medio de una brecha de datos llegó a los 4,44 millones de dólares según IBM. Para una startup, eso no es un golpe del que se vuelve. Y la ironía es que el WAF estaba ahí, funcionando, con logs perfectos, mientras el atacante hacía su trabajo.
Si gestionas infraestructura en Azure y tu WAF está en modo Detection más allá del período inicial de ajuste, tienes una tarea pendiente este lunes. No es urgente hasta que de repente lo es.
En descubre.ai hemos cubierto otras dimensiones de la seguridad en el ecosistema tech: desde las tendencias de ciberseguridad en LATAM para 2026 hasta ataques de supply chain que comprometen herramientas de desarrollo. La seguridad en la nube cierra el círculo: no basta con revisar el código si la infraestructura que lo ejecuta está mal configurada.
