Mitigaciones del fabricante, reducir la exposición mientras llega el parche

Una mitigación reduce la posibilidad de que una vulnerabilidad se aproveche, pero no la elimina: el defecto sigue en el código. Suele ser un cambio de configuración, el cierre de un puerto o la desactivación de un módulo. Por eso es temporal y tiene fecha de revisión, y por eso tiene un costo: casi siempre apaga alguna función que alguien usa.

En un informe de vulnerabilidades, una mitigación aplicada no cierra el hallazgo. Lo cambia de estado: «mitigado, pendiente de corrección», con quién la aplicó, cuándo y hasta cuándo vale. Cerrar el hallazgo exige la corrección instalada y comprobada.

Un boletín de seguridad es un documento corto con partes fijas: producto, identificador, gravedad, corrección y, si existe, mitigación con sus pasos y sus efectos secundarios. Para comprobar una mitigación hay que sacar de ahí el nombre exacto de lo que se cambia, porque la comprobación se hace contra la configuración del servidor, no contra la memoria de quien la aplicó.

Lee aviso-NS-2026-021.txt y localiza el parámetro de configuración que el fabricante manda deshabilitar.

La mitigación de un boletín suele tener más de un paso, y cada uno se comprueba en un lugar distinto: la configuración del servidor para el primero, el cortafuegos para el segundo. Aplicar solo uno es mitigar a medias, y se nota porque el sistema «parece protegido» en una de las dos revisiones y no en la otra.

Abre reglas-cortafuegos.csv. El aviso pide cerrar la entrada desde internet a un puerto. Una de las reglas lo sigue permitiendo.

«Ya la apliqué» no es evidencia. La evidencia de una mitigación es una lectura posterior al cambio: la configuración muestra el parámetro en el valor nuevo y el cortafuegos ya no tiene la regla que permitía la entrada. Quien verifica no es quien la aplicó, o por lo menos deja ambas lecturas en el ticket con la fecha y la hora.

Esa lectura también sirve para detectar la mitigación que alguien deshizo sin avisar, por ejemplo al restaurar una copia de seguridad antigua.

Una mitigación sin fecha de revisión se convierte en permanente por olvido. El registro de cambios fija el plazo de revisión desde la aprobación, y el acumulativo que corrige el defecto marca el límite natural: cuando se instala, la mitigación se retira y se comprueba que lo que se apagó vuelve a funcionar.

Lee registro-cambios.txt y calcula la fecha de la primera revisión de la mitigación.