Pruebas de la regla con datos ficticios

Una prueba de regla tiene dos mitades. Los casos positivos son eventos que la regla debe detectar. Los casos negativos son eventos parecidos que la regla debe dejar pasar. Con solo positivos, una regla que alerta por todo pasa la prueba; con solo negativos, una regla que nunca dispara también la pasa. Hacen falta ambos.

Los datos de prueba son ficticios y se escriben a mano, con los campos exactos que la regla lee. No son registros de producción, porque en producción casi nunca ocurre a propósito lo que queremos probar.

Abre casos-de-prueba.csv. Cada fila trae lo que se esperaba y lo que se obtuvo. Un positivo que termina en silencio es un falso negativo: lo peor que le puede pasar a una regla, porque la acción que debía verse ocurrió y nadie lo supo.

La tabla dice qué falló; el registro dice por qué. Abre registros-de-prueba.jsonl y regla-usuario-a-administradores.yml. En Sigma, un valor sin comodín es una coincidencia exacta del valor completo: un grupo con un nombre parecido pero no igual no coincide. Compara el valor de requestParameters.groupName del caso que falló con el que pide la regla.

El otro error posible es el contrario: un negativo que alerta es un falso positivo. Cada uno cuesta tiempo del turno y, si se repite, acaba con el hábito de cerrar alertas sin leerlas. La regla excluye a una cuenta de automatización por su nombre exacto, y el equipo tiene más de una.

La medida más simple de una prueba es la proporción de positivos que la regla detectó. Se calcula dividiendo los positivos que terminaron en alerta entre el total de positivos. No dice todo: una regla con el cien por ciento sobre cinco casos escritos por su autor todavía puede fallar con datos que el autor no imaginó. Pero una cifra baja es un aviso claro.