GESTIÓN DE VULNERABILIDADES: LO QUE NO SE PARCHEA, SE MULTIPLICA
Introducción
El 90 % de las incidencias que afectan hoy a las empresas, sin importar su tamaño, no vienen de ciberataques sofisticados, sino de vulnerabilidades conocidas que nunca se parchearon. Sistemas obsoletos, configuraciones por defecto o servicios de prueba olvidados siguen siendo las puertas más usadas para entrar.
La gestión de vulnerabilidades no es un evento trimestral ni un PDF lleno de CVEs: es un proceso continuo y medible
que conecta inventario, evaluación, priorización, remediación y verificación.
Sin ese ciclo, la seguridad no es más que relato.
Qué es (y qué no es) la gestión de vulnerabilidades
- Es identificar debilidades técnicas en sistemas, aplicaciones y configuraciones, priorizarlas por riesgo y remediarlas en plazos definidos.
- No es pasar un escáner una vez al trimestre ni guardar los resultados “por si lo pide auditoría”.
- Su objetivo no es listar vulnerabilidades, sino reducir riesgo medible.
En la ISO/IEC 27002:2022, el control A.8.8 “Gestión de vulnerabilidades técnicas” exige exactamente esto: inventario actualizado, evaluación continua y acciones correctivas documentadas. En resumen: es un proceso vivo.
El ciclo práctico (sencillo y que funciona)
- Descubrir: tener un inventario real (CMDB) y escaneo continuo.
- Evaluar: correlacionar CVE/CVSS con exposición real (internet, privilegios, datos afectados).
- Priorizar: decidir qué va primero según riesgo y criticidad del negocio.
- Remediar: parchear, mitigar temporalmente o endurecer (hardening).
- Verificar: reescanear y evidenciar el cierre antes de dar por hecho que “ya está”.
- Aprender: revisar causas y evitar reincidencias (lecciones post-parcheo).
Errores frecuentes
- Inventario ciego: se escanea “lo que creemos que hay”. Siempre faltan activos.
- Prioridad por CVSS en bruto: un 7.5 en un host aislado no es lo mismo que un 5.0 expuesto a internet.
- “Ya lo parchearemos”: ventanas de mantenimiento eternas que nunca llegan.
- Sin dueño: nadie responsable del sistema = nadie ejecuta el parche.
- Sin verificación: se aplica el parche, pero nadie confirma que cerró el fallo.
Buenas prácticas mínimas (las que mueven la aguja)
- Inventario vivo integrado con CMDB y descubrimiento automático.
- Escaneo continuo (interno y externo) con re-priorización según exposición real.
- SLA de remediación por severidad y exposición (internet vs interno).
- Parches + mitigaciones: si no puedes parchear, compensa (WAF, segmentación, desactivación temporal).
- Automatiza con pipelines WSUS, Intune, Ansible, MDM, etc.
- Reescaneo y evidencia antes de cerrar un ticket.
- KPIs operativos: % de activos cubiertos, edad media de vulnerabilidades abiertas, cumplimiento de SLA.
SLA de remediación (referencia práctica)
| Severidad / Exposición | Objetivo recomendado |
|---|---|
| Crítica + expuesta a Internet | Corregir o mitigar ≤ 7 días |
| Alta (interna) | Corregir o mitigar ≤ 30 días |
| Media | Corregir en ≤ 90 días o justificar aceptación de riesgo |
| Baja | Incluir en ciclo regular de mantenimiento |
Referencia orientativa: ajusta a tu sector, criticidad y capacidad operativa.
Herramientas útiles
- Escaneo: OpenVAS/Greenbone, Nessus, Qualys, Defender Vulnerability Management.
- Gestión de parches: WSUS, Intune, Ansible, SCCM, MDM.
- Code & Container Security: SCA/SAST/DAST (GitHub Advanced Security, OWASP ZAP, Trivy, Clair).
- Integración: CMDB, SIEM o dashboards centralizados para seguimiento y reporting.
Checklist rápida para arrancar hoy
- Conecta el inventario (CMDB) con el escáner: nada fuera del radar.
- Distingue expuesto a Internet vs interno en tus informes.
- Define SLA por severidad y exposición (y publícalos).
- Establece reescaneo automático tras cada parche.
- Guarda evidencias de cierre (ticket + resultado de rescaneo).
Relación con ISO/IEC 27001–27002 y el SGSI
La gestión de vulnerabilidades es el termómetro técnico del SGSI: conecta inventario, control de cambios, parches y mejora continua. En la 27002:2022, este control se refuerza con otros como A.8.9 (gestión de configuración) y A.8.11 (gestión de vulnerabilidades técnicas), integrándose con la gestión de proveedores, accesos y monitorización. NIST y ENISA coinciden en lo mismo: procesos continuos, medibles y trazables.
Errores estratégicos (visión de dirección)
- Tratar la gestión de vulnerabilidades como tarea técnica, no como política de riesgo.
- No establecer ownership por servicio o sistema.
- No asignar presupuesto a herramientas ni recursos humanos dedicados.
- No medir el desempeño (MTTR o % cumplimiento de SLA).
- No comunicar al comité de dirección la evolución del riesgo técnico.
Reflexión final
La gestión de vulnerabilidades no es un informe: es un hábito operativo. Cada parche pendiente es una invitación abierta a un atacante, y cada remediación bien cerrada es una lección aprendida. Las vulnerabilidades no se arreglan, se heredan… hasta que alguien las gestiona.
Conclusión
La seguridad no se demuestra con PDFs, sino con tiempos de remediación. Sin inventario, sin dueños y sin SLA, las vulnerabilidades se convierten en ruido técnico imposible de gobernar. En Gondor ayudamos a las empresas a implantar procesos de gestión de vulnerabilidades medibles, continuos y alineados con su SGSI.