Controles compensatorios, proteger lo que no se puede arreglar

Un control compensatorio no arregla la vulnerabilidad: sigue ahí, en el equipo. Lo que hace es bajar la probabilidad de que alguien la use o el daño que podría causar. Por eso la vulnerabilidad se mantiene en el registro con su excepción y se sigue mirando, aunque el control esté bien puesto.

Decir «ya está resuelto» porque hay una lista de acceso es un error de lenguaje con consecuencias: el día que alguien cambie la lista, la exposición vuelve y nadie la espera.

Cada hallazgo llega por un camino: la red, un puerto USB, un archivo. Un control compensatorio solo sirve si bloquea ese camino. Cifrar el disco protege el contenido si el equipo se roba, pero no impide que alguien lo alcance por la red y use una vulnerabilidad remota: es un buen control para otro riesgo, no para este.

En controles.csv la columna vector dice por dónde llega el hallazgo y cubre_vector dice si el control lo bloquea.

Un control que nadie vigila se degrada: la regla de red cambia en una migración, el sello del puerto se rompe, la excepción vence sin que se note. Para que un control compensatorio sea creíble necesita un dueño con nombre, evidencia de que existe (una captura de la regla, un acta de la revisión) y una fecha de revisión.

Sin esas tres cosas, es una intención y no un control. Un auditor no lo aceptará y un incidente lo mostrará.

Se aplican las cuatro condiciones del leeme.txt fila por fila: cubre el vector, tiene dueño con nombre, tiene evidencia y su revisión no ha vencido al corte. Un solo fallo basta para que el control no cuente. El resultado es la cifra honesta de equipos realmente protegidos.

Un control puede tener todo en orden y aun así dejar de valer: su fecha de revisión pasó y nadie ha comprobado que sigue funcionando. Hasta que se revisa, el equipo está protegido solo de palabra.