Cobertura de detección por técnica

Para cada técnica, la cobertura se descompone en tres preguntas. ¿Hay una regla de detección? ¿Llega a la plataforma la fuente de registros que esa regla necesita? ¿Se probó la regla hace poco y funcionó? Si falla una, la técnica no está cubierta en la práctica, aunque la regla exista y aparezca como «activa».

Esa es la trampa de los mapas de calor: pintar de verde por la existencia de una regla. Una regla que espera datos que nunca llegan no alerta nunca, y nadie lo nota hasta el día del incidente.

Abre /cobertura/cobertura.csv. La columna fuente_recibida dice si la fuente que la regla necesita está llegando al SIEM, y estado_regla si la regla está activa, en pruebas o no existe. Busca la fila en que la regla figura como activa y la fuente no llega: ahí el tablero engaña.

Hay también técnicas que ni siquiera tienen regla escrita, y esas son la brecha más simple de decir en voz alta. La columna estado_regla lo marca con un valor propio. Una técnica de este caso depende de un registro que sí llega al SIEM, así que no es un problema de visibilidad: simplemente nadie escribió la regla.

El archivo lee-primero.txt fija el criterio del equipo: una técnica está cubierta si su regla está activa, su fuente se recibe y la regla se probó con fecha igual o posterior a 2026-09-11. Una prueba más vieja deja la regla sin garantía. Aplica el criterio fila por fila; no cuentes las reglas «en pruebas», las que no reciben su fuente ni las que se probaron hace más de noventa días.

Una tabla de cobertura honesta se parece a esto: cuántas técnicas del caso quedaron cubiertas, cuáles tienen una brecha (por regla, por fuente o por prueba vencida) y qué se propone para cada una. Lo que no se hace es esconder la brecha detrás de un porcentaje redondo ni decir «tenemos cobertura» sin enseñar la tabla. La cobertura también depende de qué técnicas se midieron: medir solo seis de las muchas de la matriz no dice nada de las demás.