Convertir los indicadores de amenazas de Cloudflare en reglas WAF en tiempo real

Tan pronto como un indicador de amenaza ingresa al sistema, las reglas comienzan a bloquear el tráfico. Esta acción parece muy interesante. El ritmo es rápido, la retroalimentación es rápida y los informes son hermosos. Pero una vez que esto se pone en producción, la verdadera dificultad ya no es convertir el indicador en una regla, sino hacer que esta regla resista el tráfico, los falsos positivos y las reversiones.

Cuando leí Convertir los indicadores de amenaza de Cloudflare en reglas WAF en tiempo real, lo que me vino a la mente no fueron las elegantes palabras “automatización del acceso a la inteligencia”, sino varias imágenes muy prácticas: una IP se marcó en rojo y fue interceptada diez minutos después; un ASN estaba marcado como de alto riesgo y, como resultado, estaba involucrada una salida compartida completa; una muestra de ataque de corta duración acababa de ingresar a la base de reglas y el tráfico de ataque se había cortado, dejando una regla antigua que continúa vigente. Aquí el tiempo real no se trata solo de velocidad, sino que comprime el ciclo de vida de las reglas, la credibilidad de los datos y las responsabilidades de disposición en la misma ventana.

Las reglas pueden ser rápidas, siempre que se puedan retirar.

Cuando un indicador de amenaza entra en un WAF, el primero en perder la paciencia no suele ser el atacante, sino la persona de turno. Porque una vez que una regla entra en vigor, lo que sigue no es una “mejora de seguridad” abstracta, sino lesiones accidentales específicas, apelaciones, reversiones y auditorías. Los indicadores a nivel de IP son los más fáciles de delegar. Tienen ataques de un solo punto, tiempos de supervivencia cortos y bajos costos de recuperación. Indicadores como ASN, segmento de red, huella digital TLS y combinación de solicitudes son mucho más cautelosos. Cubren un área mayor y tienen efectos secundarios más difíciles al golpear.

La parte realmente valiosa de esto es que las reglas no se escriben una vez y luego se terminan, sino que aparecen con TTL, fuente, rango de acierto y condiciones de deshacer. Sin estos campos, las reglas en tiempo real degenerarán rápidamente en un montón de registros de prohibición vencidos. Si bloquea un ataque hoy, comenzará a bloquear a los usuarios normales mañana. El mal olor más común en la producción es que la base de reglas se vuelve cada vez más espesa, y lo que se retiene no es un juicio efectivo, sino emociones históricas.

Se debe dejar un búfer entre la capa indicadora y la capa de acción.

Por supuesto, traducir los indicadores de amenazas directamente en reglas de bloqueo es el más rápido, pero este paso también es el más fácil para amplificar los errores de inteligencia y convertirlos en accidentes en línea. Un enfoque más estable suele ser dejar una capa de amortiguación entre el indicador y la acción, permitiendo que la misma señal pase primero por la observación, el desafío y el límite de velocidad, y luego decida si realmente bloquearla. Una vez que falta esta capa de amortiguación, cuanto más rápido se actualicen los indicadores, más rápido se dañarán accidentalmente las reglas.

Cuando realmente se implementa, es mejor que la regla no sea un interruptor plano de encendido/apagado, sino un conjunto de estados que puedan expresar la intensidad de la acción: grabar primero, luego desafiar, luego limitar la corriente y finalmente ingresar a la intercepción. El beneficio de esto es sencillo: las reglas pueden escalarse gradualmente a medida que la evidencia se vuelve más sólida, y pueden degradarse rápidamente cuando la evidencia se vuelve más débil. Para el equipo de seguridad, esto puede mantener la credibilidad mejor que completar todas las reglas a la vez; Para el lado empresarial, al menos pueden ver fluctuaciones anormales cuando aparecen por primera vez, en lugar de esperar hasta que se acumulen los tickets de servicio al cliente para descubrir qué sucedió.

{
  "action": "challenge",
  "scope": "path:/login",
  "ttl": "15m",
  "confidence": 0.82
}

Esta estructura parece simple, pero en realidad es muy importante. Cuando confidence es bajo, desafiar primero se parece más a un juicio de ingeniería que a una intercepción directa; ttl caduca automáticamente después del vencimiento para evitar que la información antigua cuelgue en el costado; scope se reduce a una ruta o segmento de tráfico para que el área de daño accidental no se amplíe infinitamente.

Sin revisión, las reglas solo se alargarán y parecerán un montón de basura.

El mayor temor del WAF en tiempo real no es la baja tasa de aciertos, sino que nadie sabe qué pasó después del acierto. Después de que se publiquen las reglas, debe poder mirar tres cosas en retrospectiva: cuántos ataques reales se bloquearon, cuántas solicitudes normales se eliminaron accidentalmente y si hubo nuevos métodos de derivación después de los ataques. Sólo conectando estas tres cosas se puede considerar que la regla es operable y mantenible; sin ninguno de ellos, eventualmente se convertirá en una acción inercial de “bloquearlo primero de todos modos”.

Esta es también la parte más subestimada de la automatización de indicadores de amenazas. Puede haber muchas fuentes de indicadores y las actualizaciones de inteligencia pueden ser frecuentes, pero sin un circuito de retroalimentación estable, las reglas siempre seguirán adelante. Un sistema verdaderamente maduro registrará la tasa de aciertos, la cantidad de reversiones, la cantidad de liberaciones manuales, las alarmas relacionadas y las pérdidas comerciales de cada regla. En este punto, las reglas ya no son simplemente configuraciones de seguridad, sino registros de eliminación con una cadena de evidencia.

Este conjunto de herramientas solo es adecuado para equipos que ya tienen capacidades de eliminación

Convertir los indicadores de amenazas en reglas WAF en tiempo real no es adecuado para todos los escenarios. Para sistemas con poco tráfico, superficie de ataque estrecha y servicio manual lo suficientemente rápido, a menudo es más problemático seguir dependiendo de reglas estáticas y actualizaciones manuales. Quienes realmente necesitan esta capacidad suelen ser equipos con mucho tráfico, alta densidad de ataques, cambios frecuentes de reglas y que ya cuentan con registros, procesos de revisión y tareas.

Una vez que se implementa este tipo de sistema, el valor no es simplemente “detenerse más rápido”. Lo que es más importante es transformar la eliminación de seguridad de un juicio manual único a una cadena de ejecución revocable, revisable y calificable. La ventaja de una plataforma como Cloudflare al hacer esto no es solo que puede recibir más señales de amenaza, sino que tiene la capacidad de enviar las señales a la capa de reglas y luego conectar la capa de reglas nuevamente para monitorear, revertir y auditar. Sin esta cadena, el tiempo real sólo hará que los errores ocurran más rápido; Con esta cadena, las reglas realmente pueden entrar en producción.