Condiciones, filtros y falsos positivos

La condition combina los bloques de la detección con and, or, not, paréntesis y cuantificadores como 1 of o all of, que aceptan un comodín sobre el nombre de los bloques. La costumbre es llamar selection_* a lo que se busca y filter_* a lo que se excluye.

Una condición como selection_padre and selection_hijo and not 1 of filter_* se lee así: el evento tiene que cumplir las dos selecciones y no puede cumplir ninguno de los filtros. Si cumple uno solo de ellos, la regla calla.

Abre la consola. alertas_prueba_14_dias agrupa las alertas de la prueba por padre, hijo y línea de comandos, con la revisión que hizo el turno. La sección falsepositives de la regla de la Red ya avisaba de plantillas internas con macros, y en la casa hay más de una.

Antes de proponer un filtro hay que saber qué produce la mayor parte del ruido: es por ahí por donde se empieza.

filtros_propuestos trae tres filtros. Los de la célula de inteligencia y de cartera excluyen una línea de comandos concreta cada uno. Si se aplican esos dos, ¿cuántas de las alertas de la prueba seguirían saliendo?

Haz la cuenta grupo por grupo: un grupo de alertas desaparece si su línea de comandos cumple alguno de los dos filtros.

Un buen filtro es estrecho: describe una excepción concreta (esta línea de comandos, esta plantilla, esta cuenta) y deja intacto lo demás. Un filtro amplio puede «arreglar» el ruido apagando la propia conducta que la regla buscaba.

Lee los tres bloques propuestos contra las selecciones de la regla. Uno de ellos excluye exactamente lo mismo que una de las selecciones exige, de modo que ninguna alerta volvería a salir nunca.

Con los dos filtros estrechos quedan dos grupos de alertas: la macro de cierre contable, legítima pero sin filtro propuesto, y el grupo que el turno no supo explicar y escaló a respuesta. Alguien sugiere filtrar también este último «porque fue una sola alerta».