De la técnica en la nube a la detección

Convertir una técnica en una detección tiene tres pasos, y saltarse uno deja una regla que no sirve. Primero, qué deja escrito la técnica: una racha de fallos, un consentimiento nuevo, una regla de buzón. Segundo, en qué fuente queda: el registro de inicios, la auditoría del directorio, la actividad del buzón; y si esa fuente está activada y cuánto tiempo se guarda. Tercero, la lógica: qué condición separa lo raro de lo normal en esta empresa.

Una regla impecable sobre una fuente apagada no dispara nunca, y nadie se entera, porque el silencio de una regla se parece mucho a que no esté pasando nada.

Abre la consola y ejecuta SELECT * FROM fuentes y SELECT * FROM reglas. Cada regla dice qué fuente lee. Una de ellas depende de un registro que en Neusa no está activado donde haría falta.

Ejecuta SELECT * FROM tecnicas. La tabla de reglas describe la condición sin nombrar la técnica; la de técnicas describe lo que cada una deja escrito. Unirlas es el trabajo de inteligencia: decir qué parte de la lista de técnicas tiene detección y qué parte no.

Ejecuta SELECT * FROM prueba_historico. Antes de activar una regla se pasa por los registros del último mes y se revisa cada alerta: cuántas eran de verdad. Una regla con muchas alertas falsas no se apaga sin más: se mira por qué falla y se ajusta.

La tabla de la prueba trae la causa de las alertas falsas de DN-3, y la tabla de dominios del grupo dice qué destinos de reenvío son de la propia casa. El turno propone apagarla porque «hace mucho ruido».