Gestión de parches y SLA

La priorización le indica qué debe corregir; la gestión de parches es el proceso disciplinado que lleva esas correcciones hasta su finalización, a tiempo y en todo el entorno.

Los SLA (acuerdos de nivel de servicio) definen con qué rapidez deben corregirse las distintas gravedades. Sin ellos, las correcciones urgentes se retrasan y la responsabilidad se diluye.

Un ciclo repetible mantiene los sistemas actualizados:

• Identificar los parches disponibles (avisos de proveedores, resultados de análisis).
• Evaluar la relevancia y el riesgo de aplicarlos.
• Probar en un entorno que no sea de producción.
• Desplegar en fases controladas.
• Verificar que el parche se aplicó y que el sistema funciona correctamente.

Cada paso tiene responsables y evidencias, en consonancia con el ciclo de vida más amplio de la gestión de vulnerabilidades.

Un SLA convierte la intención en un plazo. Establece el tiempo máximo permitido desde el descubrimiento hasta la corrección, según la gravedad. Ejemplos de objetivos:

• Crítica / KEV: 7-15 días (o menos si está expuesta a Internet).
• Alta: 30 días.
• Media: 90 días.
• Baja: según las posibilidades / siguiente ciclo.

Los SLA permiten medir la antigüedad de los hallazgos y generan presión para cerrarlos, no solo para reconocerlos.

Vincule el plazo con el riesgo real, no solo con CVSS. Un elemento incluido en KEV o una vulnerabilidad crítica expuesta a Internet debería tener un SLA más estricto que una vulnerabilidad media interna.

Los marcos de referencia son útiles: CISA exige a las agencias federales corregir las vulnerabilidades de KEV dentro de plazos establecidos, y muchas empresas adoptan plazos acelerados similares para las vulnerabilidades explotadas activamente, independientemente de su CVSS.

Los parches pueden causar problemas. Las pruebas en un entorno de staging detectan regresiones antes de que lleguen a producción:

• Aplíquelo primero a un grupo de prueba representativo.
• Valide la funcionalidad y el rendimiento críticos.
• Confirme que no haya conflictos con el software existente.

Equilibre rapidez y seguridad: si una vulnerabilidad de KEV se está explotando activamente, acepte más riesgo y aplique el parche más rápido que en el caso de una actualización rutinaria.

Despliegue en fases (despliegue por anillos): primero un grupo piloto, después anillos más amplios y, por último, todo el entorno. Supervise el estado en cada anillo antes de avanzar.

Disponga siempre de un plan de reversión: instantáneas, degradación del paquete o restauración de la configuración. Si un parche provoca una interrupción, debe poder revertirlo rápidamente mientras investiga.

La aplicación manual de parches no es escalable. Utilice herramientas centralizadas:

• WSUS / SCCM / Intune para Windows.
• Gestión de la configuración (Ansible, Puppet, Chef) para flotas Linux.
• Imágenes base o doradas reconstruidas con parches para la nube y los contenedores.

La automatización impone la coherencia y reduce el intervalo entre la publicación y el despliegue de un parche.

A veces no puede aplicar un parche de inmediato: por un retraso del proveedor, un sistema heredado frágil o un requisito de disponibilidad continua. Aplique controles compensatorios para reducir el riesgo mientras tanto:

• Segmentación de red / reglas de firewall.
• Aplicación virtual de parches mediante firmas de WAF o IPS.
• Desactivación de la función o el servicio vulnerable.

Estas medidas le dan tiempo, pero no sustituyen permanentemente a la corrección real.

Es posible que los sistemas al final de su vida útil no tengan ningún parche disponible. Opciones:

• Aíslelos en un segmento de red restringido.
• Protéjalos con controles de acceso estrictos y supervisión.
• Planifique la migración o retirada con una fecha límite.
• Acepte formalmente el riesgo residual con una fecha de caducidad.

Documente todo; un sistema no actualizable que no esté documentado supone un riesgo para las auditorías y de sufrir una brecha.

Realice un seguimiento para comprobar si el programa cumple realmente sus compromisos:

• MTTR por gravedad frente al objetivo del SLA.
• Porcentaje de cumplimiento de los SLA (porcentaje cerrado dentro del plazo).
• Hallazgos vencidos / antiguos por equipo y activo.
• Cobertura de parches (porcentaje de la flota actualizado).

Informe por equipo responsable para que la rendición de cuentas sea visible y las áreas con retrasos reciban atención.

Después del despliegue, verifique: vuelva a analizar para confirmar que el CVE ha desaparecido y que el sistema funciona correctamente; después, cierre el hallazgo con evidencias. Incorpore los problemas recurrentes (una biblioteca que vuelve a aparecer, un equipo que se retrasa constantemente) a la mejora del proceso.

Una gestión de parches bien realizada convierte el riesgo priorizado en una reducción del riesgo medible y puntual.

Confirme la función de los SLA de corrección.

La gestión de parches lleva los hallazgos priorizados hasta su finalización mediante la identificación, evaluación, prueba, despliegue gradual y verificación, con el respaldo de planes de reversión y automatización. Los SLA establecen plazos según la gravedad y el nivel de riesgo (más estrictos para KEV o activos expuestos a Internet) para que las correcciones se completen a tiempo.

Cuando no sea posible aplicar parches, utilice controles compensatorios y una aceptación del riesgo documentada y limitada en el tiempo. Mida el MTTR, el cumplimiento de los SLA y la cobertura, e incorpore las lecciones al ciclo de vida.