Reglas de detección — escribir la tuya y medirla

Una regla de detección tiene tres partes: qué evento observa, qué condición lo hace saltar, y qué severidad le asigna. «En los registros de autenticación, si una misma cuenta acumula diez fallos en un minuto, alerta con severidad media» es una regla completa: fuente, condición y peso. El SIEM la aplica a cada evento que entra y dispara cuando la condición se cumple. Escribir una regla es traducir un patrón que reconociste a mano a una condición que la máquina puede evaluar sola.

La buena regla describe el patrón, no el caso concreto que la inspiró. Si la escribes para atrapar exactamente el ataque de ayer —esta cuenta, este origen— no atrapará el de mañana, que vendrá de otra cuenta y otro origen con la misma forma.

Un canal de mando (T1071) es cómo el malware ya instalado habla con quien lo controla, y suele disfrazarse de tráfico web para pasar desapercibido. Su huella no es el contenido —va cifrado— sino la regularidad: un equipo que se conecta a un mismo destino externo a intervalos casi idénticos, muchas veces, con envíos pequeños y parecidos. Ese latido regular no lo produce una persona navegando; lo produce un programa que «llama a casa» cada tanto. Una regla útil describe justamente eso: conexiones periódicas al mismo destino con envíos de tamaño constante.

Lo que distingue el canal de mando del tráfico web real es la máquina detrás. Una persona navega a saltos, irregular, a destinos variados; el latido de un canal de mando es metronómico. La regla se apoya en la regularidad, no en la dirección concreta, que cambia en cada campaña.

El error de la regla nueva es abarcar de más. «Alerta con cualquier conexión a una dirección externa» detecta el canal de mando… y también cada visita web legítima de cada empleado: miles de alertas al día, todas ruido, y el turno deja de mirar la cola porque no da abasto. Una regla que genera tantos falsos positivos que nadie la atiende es peor que no tener regla, porque da una falsa sensación de cobertura mientras esconde lo real bajo el ruido.

Afinar es acotar la condición hasta que solo salte con la forma que importa: no «cualquier conexión externa», sino «conexiones periódicas de tamaño constante al mismo destino, sostenidas en el tiempo». Cada acotación quita ruido sin perder el patrón.

Una regla se mide por dos errores opuestos. Se le escapa un incidente que debía ver: eso es un falso negativo, lo peor, porque el ataque pasa inadvertido. Y salta con actividad legítima: eso es un falso positivo, que cuesta tiempo del turno. Afinar una regla es mover el umbral entre esos dos: bajarlo detecta más pero suma falsos positivos; subirlo limpia la cola pero arriesga dejar pasar algo. La regla buena vive donde captura el patrón real sin ahogar al analista.

No hay un punto perfecto fijo: depende de qué protege la regla. Para un servidor crítico se tolera más ruido con tal de no perderse nada; para un evento menor se prioriza la cola limpia. Medir con datos reales —cuántas veces saltó, cuántas eran de verdad— es lo que convierte «me parece que funciona» en «detecta esto y cuesta esto».

No todos los sensores de red hacen lo mismo con lo que encuentran. Unos observan el tráfico y, cuando ven un patrón sospechoso, levantan una alerta y dejan que el paquete siga su camino: avisan, pero no intervienen. Otros, colocados en línea, además de avisar pueden frenar ese tráfico en el acto. La diferencia no es de calidad sino de papel, y conviene saber cuál tienes delante: una alerta de un sensor que solo observa no significa que el ataque se haya detenido.

Al escribir y desplegar reglas, esta distinción decide qué esperas que ocurra cuando disparan. Confundir «me avisó» con «lo bloqueó» deja pasar como contenido un incidente que seguía su curso.

En la telemetría de red, un equipo manda envíos del mismo tamaño a un mismo destino externo cada 60 segundos, sostenido: el latido que tu regla debe cazar. Abre la consola y lee a qué dirección late.