Ruido, falsos positivos y ajuste

En una regla de inteligencia hay dos maneras de equivocarse. En la primera, la coincidencia es correcta pero el indicador es malo: apunta a algo que también usa gente legítima, o ya no pertenece al adversario. En la segunda, el indicador es bueno pero el evento no es de una persona ni de un equipo de la casa: lo produce una herramienta que toca ese valor por oficio.

La diferencia importa porque el arreglo es distinto. Al indicador malo se le retira y se le avisa a la fuente; al origen que no cuenta se le excluye de la regla, con alcance acotado.

Ejecuta SELECT * FROM alertas_por_indicador y después SELECT * FROM descartes_por_origen. El total de descartes por indicador dice poco; el reparto por origen dice mucho. Cuando la mayoría de los descartes de dos indicadores distintos sale del mismo equipo, el problema no está en los indicadores. Consulta SELECT * FROM equipos para saber qué es ese equipo.

Hay un indicador que no acertó ni una vez y cuyos descartes vienen de decenas de puestos distintos. Eso no es un equipo raro: es un valor que toda la empresa visita por razones legítimas. Ejecuta SELECT * FROM infra_compartida. Un adversario puede haber usado esa infraestructura alguna vez, pero la coincidencia no distingue su uso del de cientos de sitios honestos.

Ejecuta SELECT * FROM ajustes. El comité aprobó dos ajustes acotados y rechazó el que apagaba la regla de IP entera, que se habría llevado por delante las alertas confirmadas de I-12, I-15 e I-16. Para saber si los dos aprobados bastan, recalcula septiembre como si ya hubieran estado activos: quita los descartes que cada uno habría evitado y cuenta lo que queda.

Retirar un indicador del SIEM arregla el ruido de la casa, pero la fuente sigue repartiéndolo a otras organizaciones. Y una exclusión sin fecha de revisión se convierte en un punto ciego permanente: si mañana alguien usa ese equipo de pruebas para algo más, la regla no lo verá.