Detecciones de cambios

Una regla que dispara ante cualquier cambio es barata de escribir y cara de atender. Una regla útil combina el cambio con un contexto: que el programa sea de un proveedor, que el comportamiento se salga de la línea base, que el destino sea nuevo y poco conocido. Lo que se mide es cuántas de sus alertas, tras revisarlas, resultaron ser lo que la regla buscaba.

Abre reglas. La columna alertas_30d cuenta lo que disparó cada una en los últimos 30 días y confirmadas, cuántas de esas alertas se confirmaron como el cambio buscado. La precisión es confirmadas entre alertas, en porcentaje. Calcúlala para la regla del proceso firmado que lanza un intérprete de comandos fuera de su línea base.

Una regla con cero alertas puede significar que no hay nada que ver o que no puede ver. Para saber cuál de las dos, se mira si su fuente llega al SIEM. En fuentes hay una que hoy no llega; la regla que se apoya en ella no ha alertado en 30 días no porque todo vaya bien sino porque está ciega.

De las reglas con alertas, una destaca por tener la menor proporción de alertas confirmadas: avisa mucho y casi todo es ruido. No se descarta por eso; se le añade contexto. Calcula la proporción de cada una con alertas y elige la menor.

La regla ruidosa busca algo valioso, un dominio nunca visto, pero lo busca sola. La mejora no es apagarla ni subir el umbral hasta que no dispare: es unirla a otras señales del módulo, como que la consulta venga de un software de proveedor recién actualizado, que su proceso se salga de la línea base y que el dominio sea joven.