Calidad de los datos: ruido, duplicados y caducidad

El campo to_ids de un atributo MISP dice que el emisor lo considera apto para alimentar detección automática: reglas, listas de bloqueo, alertas. No dice «esto es malicioso»: dice «esto se puede usar para detectar». Un atributo puede ser real y no servir como indicador (una nota, el correo de una víctima) y entonces va con to_ids en 0; y uno con to_ids en 1 puede, por error, apuntar a algo legítimo y muy usado.

Por eso la marca del emisor es el punto de partida, no la decisión: quien consume revisa antes de cargar.

Las listas de advertencia de MISP existen para esto: son conjuntos de valores que parecen indicadores pero son infraestructura legítima y muy usada (resolvedores públicos, servicios de uso masivo, rangos conocidos). Si un atributo con to_ids en 1 coincide con una de ellas, no se carga sin una revisión humana, porque bloquear ese valor se lleva por delante algo que la organización necesita.

Abre la consola. En atributos_recibidos están los cinco importados y en listas_de_advertencia, los valores legítimos que la cooperativa ha declarado.

Los atributos envejecen. La política que Valle Sereno usa para este laboratorio —no es una norma— cuenta los días desde el último avistamiento (last_seen), no desde que el dato llegó a la plataforma: un indicador que nadie ha visto en dos meses no merece el mismo peso que uno visto esta semana. Cada tipo tiene su plazo y la fecha de revisión se calcula sumándolo.

El dominio que llegó del foro abierto es el más viejo de los importados. Consulta su último avistamiento y el plazo de politica_de_caducidad para su tipo.

Dos mecanismos distintos acaban un dato. La caducidad es previsible: la ventana de validez termina sola. La revocación es una decisión: el emisor descubre que se equivocó y lo retira (en STIX, revoked en verdadero con una versión nueva del objeto; en MISP, lo borra o lo marca). La retirada no borra las copias que otros ya descargaron: cada receptor tiene que enterarse y quitarlo de lo que cargó.

En la consola, historial_de_cambios muestra lo que el emisor hizo con la dirección importada del evento EV-2207.

Hay un error de cálculo frecuente: contar como corroboración lo que es el mismo dato repetido. Si un valor aparece en dos eventos pero ambos vienen de la misma fuente, no hay dos confirmaciones: hay una, copiada. En una plataforma de compartición esto pasa a menudo, porque un evento importa lo que otro ya tenía.

En atributos_recibidos hay un valor que aparece dos veces, en dos eventos, con la misma fuente y la misma fecha. Esa coincidencia no suma confianza.