Migrar frente a parchear, decidir con criterios escritos

Parchear es siempre la primera respuesta ante una vulnerabilidad, hasta que no hay parche. Un producto sin soporte no recibe correcciones nuevas, así que cualquier hallazgo descubierto después de esa fecha queda abierto sin una salida oficial. La segunda condición para descartar el parche es práctica: el parche existe pero exige una actualización de plataforma que ya no se puede aplicar sobre ese sistema.

En ambos casos la decisión se desplaza hacia otras tres: aislar el servidor y mitigar, reemplazarlo por uno nuevo o llevar el servicio a un proveedor que lo mantenga.

Una matriz de decisión pone en filas las opciones y en columnas los criterios. Cada criterio tiene un peso que suma cien entre todos, y cada opción recibe un puntaje de uno a cinco por criterio, donde cinco es lo mejor. El total de una opción es la suma de peso por puntaje en cada criterio. Lo valioso no es el número: es que los pesos quedan escritos antes de puntuar, y cualquiera puede repetir la cuenta.

Lee leeme.txt, criterios.csv y puntajes.csv. Calcula el total de la tercera opción, el servidor nuevo en el centro de datos.

Las matrices tienen un defecto conocido: un total alto puede esconder una debilidad que no debería tolerarse. Por eso se añade una regla de veto escrita antes de puntuar: una opción que tiene la nota más baja en el criterio de seguridad queda descartada, sin importar lo que sume en los demás. Es la manera de evitar que lo barato y rápido gane a lo que deja el problema donde estaba.

Aplica la regla del archivo leeme.txt sobre los totales de las tres opciones.

Antes de mover un servicio hay que saber quién lo usa y de qué manera. Algunas aplicaciones hablan con el correo central con mecanismos nuevos, y moverlas es cambiar una dirección; otras dependen de un método que el servicio nuevo no acepta, y moverlas exige tocar la aplicación. Esa diferencia fija el orden de la migración y a veces el plazo.

Abre dependencias.csv y busca la aplicación que no soporta el método de autenticación moderna del servicio nuevo.

Migrar no termina la gestión de vulnerabilidades: la mueve. Un servicio en la nube tiene su propia configuración, sus propios accesos y su propio modelo de responsabilidad compartida, y el analista pasa de leer versiones de servidor a leer postura de configuración. El inventario cambia de «servidor» a «servicio» y el servidor viejo, aunque ya no se use, sigue existiendo hasta que alguien lo apaga y lo registra.