Ciclos típicos: parches de seguridad crítica (0-30 días), parches de seguridad alta (30-60 días), parches mensuales sin urgencia (60-90 días), actualizaciones mayores (planificadas, puede ser meses).
Qué es la gestión de parches
La gestión de parches es el proceso de identificar, descargar, probar e implementar actualizaciones de software que cierren vulnerabilidades conocidas o corrijan bugs. Un parche puede ser una corrección de seguridad crítica, mejora de performance o corrección funcional. Hacer un parche requiere planificación: identificar qué sistemas necesitan, testear impacto, coordinar ventanas de implementación, validar que nada rompe.
Por qué importa
Vulnerabilidades conocidas son la vía de entrada más común en incidentes de seguridad. Un 40-50% de brechas explotaban vulnerabilidades para las que el parche estaba disponible desde meses atrás. Una vulnerabilidad sin parche requiere otras defensas (segmentación, monitoring intenso). Una vulnerabilidad con parche disponible pero no aplicado es negligencia. El desafío es que parches a veces rompen aplicaciones heredadas, requieren reboots en sistemas críticos o no son compatibles con versiones antiguas de software. Gestión de parches es balancear la urgencia de cerrar brechas con la realidad operativa de que no puedes parar toda tu infraestructura por un parche. Para requisitos DORA y NIS2, tener política clara de parcheado es mandatorio.
Puntos clave
Arquitectura de parcheado: parcheadores automatizados (WSUS para Windows, Landscape para Linux) reducen carga manual. Pero requieren testing en entorno equivalente antes de automatizar a producción.
Priorización: una vulnerabilidad con exploit público en la wild requiere parcheado urgente. Una vulnerabilidad teórica sin tooling conocido puede esperar. CVSS score es guía, no ley.
El reto de sistemas heredados: aplicación crítica que depende de Windows Server 2008 que ya no recibe parches requiere o bien migración o bien controles compensatorios extremos (segmentación radical, monitoring 24/7).
Ejemplo: gestión de parches en empresa heterogénea
Empresa con 500 PCs, 50 servidores, 30 aplicaciones críticas. CVE-2024-XXXXX afecta navegadores, score 9.8, exploit público disponible. Se activa política de emergencia: navegadores parcheados en 3 días en todos los PCs via WSUS. Una de las 30 aplicaciones requiere versión específica de Java que solo se parcheaba en testing, requería reboot de sistema crítico. Se evalúa: riesgo de no parchear vs impacto de reboot. Se decide implementar control compensatorio (bloquear acceso externo a esa aplicación por firewall) mientras se planifica reboot en ventana de mantenimiento mensual. Sin política clara habría sido caos; con ella, fue decisión informada en 4 horas.
Errores habituales
- Parchear sin testear primero. Un parche que arregla 1 vulnerabilidad pero rompe 3 aplicaciones críticas es desastre. Testear en ambiente similiar a producción es no negociable.
- Asumir que 'actualizar todo' regularmente es suficiente. Diferencia entre actualización de features y parche de seguridad. Una actualización major puede no incluir parche de seguridad crítico que necesitas hoy.
- No tener inventario actualizado de sistemas y software. Si no sabes qué versiones ejecutas, no puedes saber cuáles vulnerabilidades te afectan. Inventario es prerrequisito para gestión de parches.
- Dejar software end-of-life (sin soporte) sin parches por años. A veces es inevitable (aplicación heredada), pero debe ser excepción documentada con controles compensatorios, no regla.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿Cada cuánto hay que parchear?
Parches críticos: 0-30 días. Parches de seguridad alta: 30-60 días. Parches mensuales rutinarios: 60-90 días. Lo importante es no dejar vulnerabilidades conocidas sin remediar indefinidamente. Policy clara que todos entienden es mejor que improvisación.
¿Qué hacer con software sin parches disponibles?
Opciones: (1) migrar a software que sí recibe parches, (2) aplicar controles compensatorios extremos (segmentación radical, aislamiento de red), (3) aceptar riesgo documentado si no hay opción. Nunca ignorar indefinidamente.
¿Puede un parche introducir vulnerabilidades nuevas?
Sí, raramente pero pasa. Por eso se testea. Si descubres que un parche rompe algo, la decisión es: rollback rápido y esperar parche revisado, o mantenerlo con conocimiento del riesgo. Debe ser decisión consciente.