Listas de referencia y su mantenimiento

Una regla de coincidencia no sabe de dónde salieron los valores que lee. Si una lista pierde a quien la cargó, nadie decide cuándo se revisa, qué entra y qué sale; la lista sigue disparando alertas con valores que nadie puede explicar. El dueño no tiene que ser quien escribió la regla, pero tiene que existir y estar escrito.

Ejecuta SELECT * FROM listas y revisa las columnas duenio, alimentada_por y ultima_revision.

Una lista de inteligencia sana lleva el vencimiento en cada entrada, no en la lista entera: cada indicador envejece desde su propio último avistamiento. Pero el vencimiento escrito no basta; alguien o algo tiene que sacar lo que vence. Ejecuta SELECT * FROM entradas_lr01 y SELECT * FROM trabajos.

Hoy es 20 de octubre. Cuenta las entradas de la lista de dominios cuya fecha vence ya pasó y que siguen ahí.

Las listas de inteligencia y las de permitidos viven en el mismo SIEM y nadie las cruza. Cuando un mismo valor aparece en las dos, una regla dice «alerta» y otra dice «no alertes», y el resultado depende del orden en que el SIEM las evalúe. Peor: si el valor es de un socio legítimo, cada alerta que llega es una falsa alarma sobre alguien con quien la empresa trabaja todos los días.

Ejecuta SELECT * FROM entradas_lr05 y compara sus valores con los de entradas_lr01.

La lista de remitentes tiene 312 entradas, se carga a mano, no lleva vencimiento por entrada y no se revisa desde marzo. Ninguna de esas cuatro cosas rompe nada hoy, y por eso nadie la toca. Pero una lista que solo crece termina alertando sobre buzones que el adversario abandonó hace meses y que pueden haber sido reasignados a otra persona.

La tabla trabajos explica por qué hay entradas vencidas: el trabajo que las retira dejó de funcionar en agosto y nadie recibió aviso. Es el fallo típico del mantenimiento automático: se confía en él porque existe, no porque se vea funcionar. La defensa es una comprobación sencilla que el equipo de inteligencia mire cada semana.